Archive for the 'tech' Category
why do open source projects have so many bugs?
By Justin Silverton
In a recent article:
“In his first “meet the press” session as ICT Minister, Professor Sitthichai Pokai-udom put forth his radical vision for 3G in Thailand, condemned open source for turning out buggy, useless software and promised to make the civil servants in the ICT Ministry proud of their organisation once again.
Speaking at the IT Press Club, Minister Sitthichai said that he was looking for an investment of around 20 billion baht for Thai Mobile and between 10 and 18 billion for CAT in order to complete the roll-out of next generation communication networks for the two former state enterprises.
Sitthichai said on detailed questioning that Thai Mobile would upgrade its network and operate a WCDMA 3G network while CAT Telecom would roll out a CDMA2000 EV-DO network.
He said that rather than using public money to compete with the private sector, he expected today’s private mobile operators to gladly become partners to CAT and TOT and effectively lease their networks and focus on the marketing aspect. He reasoned that none of the incumbents would want to invest in a 3G network as 4G would come along in five years and render today’s investments obsolete.”
While I don’t completely agree with the stance that all open source applications are bug-ridden and useless, he does make a good point. I have used many open source applications over the years and many were either bug-ridden, barely functional, or they lacked basic functionali.
Open source sounds like a great concept. The idea is that since the code is open, there is a possibility for more programmers to see the code and create new functionality or fix bugs. This does happen to some degree, but because of the overwhelming number of contributers, many of the projects are subjected to in-fighting, politics, and eventual destruction.
While this is a part of any project, there needs to be more organization for a project to be successful. This involves assigning leaders and only accepting code into the main codebase that meets a certain standard. Many of the larger and more popular projects are using this method and have less bugs as a result (and are around much longer).
If more open source projects followed better project management practices, We would see much better projects an it would benefit both the users and the programming comunity.
Tech Resume Tips that may get you your next job
By Justin Silverton
Here are some tips that may help you when you apply for your next tech job:
Top Ten Technical Resume Writing Tips
- List your technical knowledge first, in an organized way. Your technical strengths must stand out clearly at the beginning of your resume. Ultimately, your resume is going to be read by a thoughtful human being, but before it gets to that point it often has to be categorized by an administrative clerk, and make its way past various sorts of key word searches. Therefore, you should list as many directly relevant buzz words as you can which reflect your knowledge and experience. List all operating systems and UNIX flavors you know. List all programming languages and platforms with which you’re experienced. List all software you are skilled with. Make it obvious at a glance where your strengths lie - whether the glance is from a hiring manager, a clerk, or a machine.
- List your qualifications in order of relevance, from most to least. Only list your degree and educational qualifications first if they are truly relevant to the job for which you are applying. If you’ve already done what you want to do in a new job, by all means, list it first, even if it wasn’t your most recent job. Abandon any strict adherence to a chronological ordering of your experience.
- Quantify your experience wherever possible. Cite numerical figures, such as monetary budgets/funds saved, time periods/efficiency improved, lines of code written/debugged, numbers of machines administered/fixed, etc. which demonstrate progress or accomplishments due directly to your work.
- Begin sentences with action verbs. Portray yourself as someone who is active, uses their brain, and gets things done. Stick with the past tense, even for descriptions of currently held positions, to avoid confusion.
- Don’t sell yourself short. This is by far the biggest mistake of all resumes, technical and otherwise. Your experiences are worthy for review by hiring managers. Treat your resume as an advertisement for you. Be sure to thoroughly “sell” yourself by highlighting all of your strengths. If you’ve got a valuable asset which doesn’t seem to fit into any existing components of your resume, list it anyway as its own resume segment.
- Be concise. As a rule of thumb, resumes reflecting five years or less experience should fit on one page. More extensive experience can justify usage of a second page. Consider three pages (about 15 years or more experience) an absolute limit. Avoid lengthy descriptions of whole projects of which you were only a part. Consolidate action verbs where one task or responsibility encompasses other tasks and duties. Minimize usage of articles (the, an, a) and never use “I” or other pronouns to identify yourself.
- Omit needless items. Leave all these things off your resume: social security number, marital status, health, citizenship, age, scholarships, irrelevant awards, irrelevant associations and memberships, irrelevant publications, irrelevant recreational activities, a second mailing address (”permanent address” is confusing and never used), references, reference of references (”available upon request”), travel history, previous pay rates, previous supervisor names, and components of your name which you really never use (i.e. middle names).
- Have a trusted friend review your resume. Be sure to pick someone who is attentive to details, can effectively critique your writing, and will give an honest and objective opinion. Seriously consider their advice. Get a third and fourth opinion if you can.
- Proofread, proofread, proofread. Be sure to catch all spelling errors, grammatical weaknesses, unusual punctuation, and inconsistent capitalizations. Proofread it numerous times over at least two days to allow a fresh eye to catch any hidden mistakes.
- Laser print it on plain, white paper. Handwriting, typing, dot matrix printing, and even ink jet printing look pretty cheesy. Stick with laser prints. Don’t waste your money on special bond paper, matching envelopes, or any color deviances away from plain white. Your resume will be photocopied, faxed, and scanned numerous times, defeating any special paper efforts, assuming your original resume doesn’t first end up in the circular file
- Resumes should be concise and in a manageable document length.
- Your Name and Page Number should be located on every page, just in case pages become separated while in the hands of the prospective employer.
(The Name and Page number can be in the Header or Footer part of the resume, or at the top of the page using a smaller font size, to avoid distracting the reader. Page Numbers can be written as: Page 2, Page Two, Page 2 of 3, or Page Two of Three.) - Do not put a photograph of yourself on the resume. Potential employers will not be hiring you based on your looks! However, International candidates will need to send their scanned photograph to the Systems Integration Solutions, Inc. International Department representative along with the final formatted resume.
- Type your resume in a word processing document and back it up on a disk. Updating your resume then becomes easy. If you are not a typist, ask a professional to type it.
- Use one typeface such as Times New Roman, Arial, or other traditional typeface. The standard font size is 11 point. Headers may be increased to 12 point.
- Margins should be no less than one inch on sides, top, and bottom. The white space serves as a border and keeps the resume from looking cluttered.
- Avoid underlining within the resume narrative. If you have written the statements well, they will need no further emphasis.
- Always do a print preview of each page of your resume, to view the layout and spacing.
- E-mail your resume document, with a short introduction letter to your Systems Integration Solutions, Inc. contact. The document can then be opened, printed, and distributed to clients.
- Laser-print your completed resume or have it professionally typeset.
- Give or mail an interviewer your resume printed on an off-white, tan, or light gray quality bond paper. Never give them a photocopy of your resume.
Top 5 freelance websites
By Justin Silverton
The following are the top 5 websites that I have found for freelance work. This is for mostly programming/development, which includes PHP and many other languages.
Rentacoder is good place to find small to mid-sized projects for earning extra money. It also offers a rating system which can hurt or help you depending on your work.
Odesk is a little bit different than the rest of the sites listed here. Instead of bidding on projects, you bid on hours. Employers can list the amount of hours/week and # of weeks they need out of a potential freelancer.
Craigslist is great because there is no barrier to entry for either the employer or the potential freelancer/employee (it is also among the top sites on the Internet). This can also be a detriment because anyone with a computer can post a job listing.
2) http://programmermeetdesigner.com/
A unique website that provides an opportunity for programmers to meet and work with designers.
Guru.com is a clean and professional website that has lots of large-scale projects. It also has a fairly high barrier to entry for the employers, which usually means better paying jobs.
How efficient is your favorite language?
By Justin Silverton
How does you favorite language compare? Below is the results of a series of tests performed on various programming languages. The weights of each specific test are listed in the second chart below.
|
 |
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Weights used for the scorecard | |||
|---|---|---|---|
| Test | Weight | Test | Weight |
| Ackermann’s Function | 1 | Array Access | 3 |
| Count Lines/Words/Chars | 3 | Echo Client/Server | 5 |
| Exception Mechanisms | 1 | Fibonacci Numbers | 2 |
| Hash (Associative Array) Access | 1 | Hashes, Part II | 4 |
| Heapsort | 4 | Hello World | 1 |
| List Operations | 3 | Matrix Multiplication | 3 |
| Method Calls | 5 | Nested Loops | 4 |
| Object Instantiation | 5 | Producer/Consumer Threads | 1 |
| Random Number Generator | 3 | Regular Expression Matching | 4 |
| Reverse a File | 4 | Sieve of Erathostenes | 4 |
| Spell Checker | 4 | Statistical Moments | 2 |
| String Concatenation | 2 | Sum a Column of Integers | 3 |
| Word Frequency Count | 5 | ||
(Chart reference: http://dada.perl.it/)
Flickr.com - PHP/mysql case study
Introduction
Carl Henderson from Flickr.com, a very popular photo blogging service has released a pdf (not sure exactly when this was actually released) detailing the issues they faced with having a high-traffic website.
original PDF can be downloaded here
some interesting points taken from this pdf are below.
Classes, libraries, and systems used
1) smarty for templating
2) PEAR and XML for Email parsing
3) perl for controlling
4) imagemagick for image processing
5) mysql (4.0/innoDb)
6) java, for node service
7) apache 2 and redhat linux
8) 60,000 lines of PHP code
9) 60,000 lines of templates
10) 70 custom smarty functions/modifiers
11) 25,000 DB transactions/second at peak
12) 1000 pages per second at peak
unicode support
1) UTF-8 pages
2) CJKV support
Tips: don’t use HtmlEntities(). Also, Javascript has patchy Unicode Support
Why php was used
1) Everything can be stored in the database, including smarty cache
2) a “shared nothing” approach (as long as php sessions were not used)
Mysql usage
Select’s: 44,220,588
Insert’s: 1,349,234
update’s: 1,755,503
delete’s: 318,439
13 select’s per Insert, Update, and delete
Tips: many of the tables that needed to be full-text searched were de-normalized. This does waste space, but because it allowed for little or no joins, it made searching much faster.