Advertisement
If you have a new account but are having problems posting or verifying your account, please email us on hello@boards.ie for help. Thanks :)
Hello all! Please ensure that you are posting a new thread or question in the appropriate forum. The Feedback forum is overwhelmed with questions that are having to be moved elsewhere. If you need help to verify your account contact hello@boards.ie
Advice-Programming Internships
Options
-
16-05-2012 1:09am#1Well guys I'm 25, finished college yesterday was in the Springboard course Level 7 diploma I think. Basically its a back to education thing with the social welfare.I have a degree in marketing too but I hate that whole thing couldn't do it. My IT skills prior to the course were very good,better than most people I know.I am looking for advice as regards to my next move. I only had 35 credits(modules 5-7 credits) to play with so I chose:
1,2:Computer Programming I&II
Very good understanding of C.
3:Introduction to Java
Covered in 3 months what we covered in C in one month, very slow
4: Java Technologies
Tough enough only got a D but learned a good bit
5: Data Structures and Algorithms(I now know how to do this
)
Loved this learned alot about java,A or B overall
6:Cloud Computing
Way too advanced for me!Loved the concept and that's why I took it. Wouldn't be surprised if I failed. Im raging I took it as I would have got more out of something else.
We had to have 5 credits for a CV type thing which was a waste of time as i learned most of that in marketing. I should also mention that the majority of all these subjects were online modules.I enjoy programming most as I learn best by trial and error. I have been looking for jobs for the last month and I know myself I haven't got enough there to apply for much so, I'm thinking my best option is an internship. I live in Carlow now but I'm focusing on Dublin. Do you think I have enough with this subjects to get something or should I do more?Should I randomly email IT/drop CV's companies?Any advice would be great thanks!0
Comments
-
-
-
-
-
-
Advertisement
-
-
-
-
-
You will find it hard to get a job with a Level 7 qualification.
That isn't exactly true. I know a lot of people who never went on to the level 8 because they found it so easy to find a job after getting the level 7! Most job adverts say something along the lines of "IT/Computer Science Degree" or "BSc required" ... they don't specify 7 or 8 and sure as hell won't turn someone away who knows their stuff but doesn't have the level 8.
It is not *always* better to go and do the Level 8 either. Someone who spent an extra year in college getting the level 8 will have a years less experience than the person who has been out there and working since their level 7
And yes, I do think everyone should go ahead and get the Level 8, great for the CV and its an achievement you won't always be in a position to go back and get. I went out working after the level 7, have never had any problems getting a job, but probably couldn't afford to take the year out for the level 8 now even if I wanted to.
Of the one's I went to college with, pretty much everyone was hired after the level 7.. the few that remained and have a level 8 today were the one's who weren't good enough (or weren't offered) jobs after getting the 7.0 -
Advertisement
-
-
-
-
-
-
-
-
-
-
-
Advertisement
-
-
-
-
irishdude11 wrote: »How realistic is it to be able to start contributing to something like Firefox\Linux\etc...? I would imagine there is an extremely high bar to be met to contribute to these huge open source projects that have millions of lines of code and have been worked on for years/decades by some of the top guys in the business. I cant see how it is possible to be able to make a worthwhile contribution until you have been programming for 20 years yourself and specialise in some particular area. That's the only way I'd see you having a chance to improve on the code that already exists in these projects.
Believe me, the code is not written only by the top guys in the business.
Contributing is easier than you think A real life example - how to contribute to linux kernel:
1. Find out what you want to contribute, i.e. there is a device that you have, but it's not fully supported or you think that there is something that can work better.
2. Find what module is handling the device.
3. Read the code of the module, try to understand (you don't have to understand everything, just to have a rough idea how it works or even the idea how a single function that you'll be working on works)
4. Now the tricky part: try to fix it or improve it. That depends purely on your skills and the more you know the more you can modify. But the starting point could be a very low hanging fruit - try to find a typo in comments in the code!
5. Prepare a patch (you _have_ to use git for it for linux kernel, but it's very easy)
6. check if the patch matches coding standard of the kernel using script that is located in scripts/checkpatch.pl (I think that's the name)
7. Check where you should send the patch, again using script (scripts/getmaintaner.pl)
8. Send the patch - preferred method using git, and again it's quite easy.
9. Wait for a reply with comments or just simple "Thanks, applied!" if the patch have been accepted.
Info about kernel coding style: http://kernel.org/doc/Documentation/CodingStyle
Feel free to ask me for the details is something is not clear.
The above is probably one of the most formal ways in the open source world. On different projects you'll get different workflows, but I'm quite sure they will be more relaxed than the one for the kernel.
IMHO the most important is to find something that is interesting for you.0 -
It should probably be pointed out that this step, though it's described rather concisely, is both the most important and the most difficult to go through if you're learning.9. Wait for a reply with comments or just simple "Thanks, applied!" if the patch have been accepted.
It is overwhelmingly likely that you will not get a "Thanks, applied!" message on submission, and you don't want one either. You want people who've been coding for longer than you to review your code and tear it down and show you what's wrong with it. You'll learn more this way, you'll learn it faster and you'll learn it better than almost any other method I know of....
...but it will also be a very solid kick in the fork() for your ego.
And yeah, there's no easy way to deal with that. You're going to have to accept it in the beginning. When you get to the point where you see a review of your code that slates it for something and you think "but that doesn't apply because X", where X is a technical reason, congratulations, you can see the other side. But in the beginning, you will at some point wind up thinking "that doesn't apply because your mother"
But stick with it. The end results are worth it. You don't even get that level of training in college (because no college can afford to hire fifty lecturers to review the code of every student on one course).0 -
Believe me, the code is not written only by the top guys in the business.
Contributing is easier than you think A real life example - how to contribute to linux kernel:
1. Find out what you want to contribute, i.e. there is a device that you have, but it's not fully supported or you think that there is something that can work better.
2. Find what module is handling the device.
3. Read the code of the module, try to understand (you don't have to understand everything, just to have a rough idea how it works or even the idea how a single function that you'll be working on works)
4. Now the tricky part: try to fix it or improve it. That depends purely on your skills and the more you know the more you can modify. But the starting point could be a very low hanging fruit - try to find a typo in comments in the code!
5. Prepare a patch (you _have_ to use git for it for linux kernel, but it's very easy)
6. check if the patch matches coding standard of the kernel using script that is located in scripts/checkpatch.pl (I think that's the name)
7. Check where you should send the patch, again using script (scripts/getmaintaner.pl)
8. Send the patch - preferred method using git, and again it's quite easy.
9. Wait for a reply with comments or just simple "Thanks, applied!" if the patch have been accepted.
Info about kernel coding style: http://kernel.org/doc/Documentation/CodingStyle
Feel free to ask me for the details is something is not clear.
The above is probably one of the most formal ways in the open source world. On different projects you'll get different workflows, but I'm quite sure they will be more relaxed than the one for the kernel.
IMHO the most important is to find something that is interesting for you.
One thing I've always wondered is how do you analyse/debug code in something like the linux kernel/firefox? Is it a massive job to be able to view any changes you make to do the code?
With a 'normal' web/desktop application I would just set breakpoints in the code and then click debug and start stepping through to gain an understanding and then make any changes, recompile and the go through the stepping through process again. But I imagine it is a huge job to compile some of these major open source projects so surely that approach is not feasible for them? Is it even possible to open the linux kernel/firefox in a debugger?0 -
irishdude11 wrote: »One thing I've always wondered is how do you analyse/debug code in something like the linux kernel/firefox? Is it a massive job to be able to view any changes you make to do the code?
With a 'normal' web/desktop application I would just set breakpoints in the code and then click debug and start stepping through to gain an understanding and then make any changes, recompile and the go through the stepping through process again. But I imagine it is a huge job to compile some of these major open source projects so surely that approach is not feasible for them? Is it even possible to open the linux kernel/firefox in a debugger?
My method (linux kernel module):
1. make a change in the code
2. compile module. There is a special Makefile made for the module I'm working on, so all I have to do is "make btmodule && sudo rmmod hid-wacom ; sudo make btinstall" and I have the module with newly made changes loaded and ready for use. The Makefile can be easily adapted to any module.
3. test the change and go back to point 1.
Point 2 takes about 60-90 seconds on a very slow laptop.
My basic and most useful debugging tool is "printk" - instead of setting breakpoints I just print what's going on - it's easy enough to spot when things go wrong (provided that you know what you're looking at )
If something goes really wrong you'll end up with kernel oops or kernel panic - there is very useful info what caused the crash.
There are also plenty of debugging options in kernel config. [2]
There is also kgdb [3], but I've never used it.
For firefox and other userland software I'd use gdb [1]. It's also handy for debugging xorg - one PC is the guinea pig and a second PC is running gdb. Connection between PCs over network (I use ssh).
[1] https://en.wikipedia.org/wiki/GNU_Debugger
[2] http://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/ch09s07.html
[3] http://kernel.org/doc/htmldocs/kgdb.html0
Advertisement