Beta

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Programming Things I Wish I Knew Earlier

Soulskill posted more than 3 years ago | from the no-substitute-for-experience dept.

Programming 590

theodp writes "Raw intellect ain't always all it's cracked up to be, advises Ted Dziuba in his introduction to Programming Things I Wish I Knew Earlier, so don't be too stubborn to learn the things that can save you from the headaches of over-engineering. Here's some sample how-to-avoid-over-complicating-things advice: 'If Linux can do it, you shouldn't. Don't use Hadoop MapReduce until you have a solid reason why xargs won't solve your problem. Don't implement your own lockservice when Linux's advisory file locking works just fine. Don't do image processing work with PIL unless you have proven that command-line ImageMagick won't do the job. Modern Linux distributions are capable of a lot, and most hard problems are already solved for you. You just need to know where to look.' Any cautionary tips you'd like to share from your own experience?"

cancel ×

590 comments

Sorry! There are no comments related to the filter you selected.

faggot (-1, Troll)

Anonymous Coward | more than 3 years ago | (#33490234)

cunt nigger

Re:faggot (0, Troll)

IllusionalForce (1830532) | more than 3 years ago | (#33490274)

>>> cunt nigger
  File "<stdin>", line 1
    cunt nigger
              ^
SyntaxError: invalid syntax
>>>

Thank you for this great tip!

Comment your code (5, Insightful)

Nkwe (604125) | more than 3 years ago | (#33490276)

Put enough comments in your code so that five years from now you (and others) can remember what you indented the code to do. Remember that comments are not for describing what the code technically does (that is what the code is for), comments are for what the code is intended to do. Try and comment the decisions you made when developing the code, specifically why you took the approach you did and why you didn't use other options.

Re:Comment your code (5, Funny)

Anonymous Coward | more than 3 years ago | (#33490306)

Put enough comments in your code so that five years from now you (and others) can remember what you indented the code to do

I indented the code to make it readable. That's so obvious I don't need a comment to remind me.

Re:Comment your code (2, Funny)

Anonymous Coward | more than 3 years ago | (#33490312)

"indented the code to do"

So the real question is tabs or spaces?

Re:Comment your code (2, Funny)

Anonymous Coward | more than 3 years ago | (#33490318)

> Remember that comments are not for describing what the code technically does (that is what the code is for), comments are for what the code is intended to do.

Corollary: Never debug comments, only code.

Re:Comment your code (5, Insightful)

kantos (1314519) | more than 3 years ago | (#33490352)

Commenting is not enough... you need to make sure you clean up the comments in a file before resubmitting it... dead comments can be more dangerous than dead code... as dead code at least doesn't run... dead comments mislead the person following later into believing a lie a lie that could potentially have major impacts on the software. Lastly... write meaningful test cases... if your tests only prove the happy path, that's OK... but if they prove that the happy path is the only path.. that is better.

Re:Comment your code (1)

hedwards (940851) | more than 3 years ago | (#33490390)

Well, yes commenting on your intent is a good idea, but it's not really enough. You also ought to be commenting on _why_ you're doing something rather than an alternative it makes it a lot easier later on when you're debugging and wondering why you picked that solution. Makes it a lot less likely that you fix the code and reintroduce whatever it was that you were trying to avoid in the first place. But when it comes to the what, if you have to put a what comment into your code, then you've done something horribly wrong and need to rewrite it ASAP.

As for the indents that people are talking about, tabs are more reasonable now than they used to be, but you're giving up screen space for them. Not really the problem it was when you were limited to 80 character columns, but it still has it's benefits and costs.

Re:Comment your code (5, Insightful)

Anonymous Coward | more than 3 years ago | (#33490436)

Commenting code isn't enough, it's just a small part of the design and documentation process. Comments are there to tie the code to the relevant part in your design document, which really is a part of programming people should put more effort into.

Re:Comment your code (5, Interesting)

russotto (537200) | more than 3 years ago | (#33490730)

Commenting code isn't enough, it's just a small part of the design and documentation process. Comments are there to tie the code to the relevant part in your design document, which really is a part of programming people should put more effort into.

It's been said for years, but it is almost never done. When it is done, it's most often (IME) done _after the fact_ because of some requirement to produce the paperwork. Perhaps it's time to give up on it. Is there a real reason for insisting on a design document, or is it just some sort of self-flagellation on the part of programmers?

Re:Comment your code (0)

Anonymous Coward | more than 3 years ago | (#33491282)

I think it is to futility try to prevent scope creep. I've never seen it work, but some people insist upon it anyway.

Re:Comment your code (4, Informative)

TheLink (130905) | more than 3 years ago | (#33490496)

> As for the indents that people are talking about, tabs are more reasonable now than they used to be, but you're giving up screen space for them

Why would you be giving up screen space with tabs? On most text editors for programming people can adjust the tabs to display as whatever indentation they want. So if someone wants to view tabs as 2 spaces and another prefers 4 and another prefers 8, they don't have to change anything in the code if their editors are already set up for that.

The disadvantage of tabs is where you have some stuff that requires you to use spaces in (text string etc) and for some reason you want certain parts of it to align with your indents. Or you are mixing your indentation - spaces and tabs (try not to do that OK? ).

Shit Coders Like Nkwe (-1, Troll)

Anonymous Coward | more than 3 years ago | (#33490454)

You can always spot the shit coders like Nkwe.

99 percent of the precious comments he writes are:

* Of absolutely no use - glorified versions of // set x to zero

* Flat out wrong compared to the actual code

Crappy programmers like Nkwe are most often motivated by the terror of being in a field the have no business being in. They hope by constantly spouting their desperate pleas to comment code that they will be able to grasp what all those smart and competent programmers keep cranking out.

Nkwe, don't fret. The world always needs another ditch digger.

Re:Comment your code (4, Insightful)

Xtifr (1323) | more than 3 years ago | (#33490470)

Put enough comments in your code so that five years from now you (and others) can remember what you indented [sic] the code to do.

But not so many that you (or others) will find it more work than it's worth to change the comments when the code changes.

I prefer code with no comments to code with actively misleading comments, and I hate code with no comments! :)

Re:Comment your code (2, Insightful)

negativewashout (1879516) | more than 3 years ago | (#33490486)

This is the best, IMHO. I, too, have looked code and gone, "WTF was this idiot thinking???? ...Oh wait... that's my code."

And agreed - dead comments have to be updated. I didn't always do it perfectly, but I pretty much got in the habit a few years ago of commenting as I go, right by the code in question. One of those times when it's good to be a bit verbose.

Re:Comment your code (4, Insightful)

Manip (656104) | more than 3 years ago | (#33490488)

I could never find the correct degree of commenting. Didn't help that in school they made us comment in an idiotically verbose way to the point of "this is a for loop to find needle in haystack" and we lost marks if we failed to. My reaction to that level of stupidity was to lose interest in comments entirely which obviously later bit me in the butt.

I really need to find some kind of "idiots guide to when to comment and when NOT to comment."

Re:Comment your code (5, Insightful)

sourcerror (1718066) | more than 3 years ago | (#33490948)

Think of comments as an API documentation*. If something complicated is going on, I usually include several usage example as well. Just look at the documantation 3rd party libraries, and try to follow that granularity and style.

Re:Comment your code (0)

Anonymous Coward | more than 3 years ago | (#33490656)

Read "clean code" and write well crafted code that defines its intent clearly without relying on all too often "out of date" comments.

Re:Comment your code (1)

Haeleth (414428) | more than 3 years ago | (#33491192)

Read "clean code" and write well crafted code that defines its intent clearly without relying on all too often "out of date" comments.

If the comments are out of date, then the code has been modified by someone who was too lazy to update the comments.

Such a lazy person is also unlikely to have made well-crafted changes that kept the code's intent clear.

Now you have unreadable code without comments. Please explain to me why this is a step forwards.

Re:Comment your code (1)

hibiki_r (649814) | more than 3 years ago | (#33490668)

The problem is that it's easy to follow this rule and forget another important one: If the code you are writing needs a lot of comments, chances are you need to try a different solution, because you are trying one that has the complexity in the wrong places.

The best code has enough comments to be understandable, but it also doesn't have anywhere near as many comments as there is code.

Re:Comment your code (5, Funny)

DMiax (915735) | more than 3 years ago | (#33490688)

Put enough comments in your code so that five years from now you (and others) can remember what you indented the code to do.

I know, Python right?

Re:Comment your code (1)

wootest (694923) | more than 3 years ago | (#33490764)

Or to put it another way, because I see you've been misunderstood: Let the code describe what the code does. Methods, classes and variables have names, use them.

If you still need to, let the comments describe *why it does that*. If you need to explain at every turn why it does that, either you're doing things in a weird way or you're over-documenting. You'll risk turning a blind eye to unwarranted comments and spend time maintaining and garbage collecting out-of-date comments.

Even when you do comment, skip the essays. Write down what's important. Spending five paragraphs telling a story about a bug in a library and then leaving out the bug ID in their tracker is to optimize the wrong way. Spend up to two sentences summarizing why and what and what it means, but don't fall through the rabbit hole so the reader doesn't have to.

Re:Comment your code (1)

Twinbee (767046) | more than 3 years ago | (#33490876)

About the 'other options', I often find that I need to keep two different pieces of code that essentially do the same thing, but there are advantages and disadvantages to each approach (often speed versus flexibility). I obviously have to choose one approach, but I keep both just in case I eventually decide to go for the other approach.

Hence, I usually have more commented code than actual code.

This would be fixed if Visual C++ etc. actually allowed one to force loop *unswitching* (different to loop unrolling!). Alas it does not, so you get very messy code, and/or loss of speed.

Re:Comment your code (1)

dodobh (65811) | more than 3 years ago | (#33491112)

Put comments in your commit messages. That way the comments never need to be updated, and they can be removed from the source itself.

The hard way is more fun (5, Interesting)

msobkow (48369) | more than 3 years ago | (#33490298)

The truth is that the "hard" way of doing things is often more fun, because you have the challenge of learning a new tool or API. Plus sometimes it's actually easier in the long run because you've engineered a solution for the outer bounds conditions of scalability, so if your application takes off, it can handle the load.

I guess the real issue is that you have to engineer a "good enough" solution rather than a "worst case" solution.

Re:The hard way is more fun (1)

pseudonomous (1389971) | more than 3 years ago | (#33490364)

I'd like to add to this that one of classic reasons why someone writes an appllication is because they need program to do something, on the other hand, if you always find and use existing solutions, you end up not writing any but short bash scripts. (I speak from personal experience)

Re:The hard way is more fun (1)

amaupin (721551) | more than 3 years ago | (#33490372)

Also, doing something the "hard way" the first time often leads to a greater understanding and appreciation of the "easy way."

Reading the article, I fail to see why I should avoid PIL for ImageMagick. In neither case is Linux going to just "do it" for me. And in either case I have to tell PIL or ImageMagick how to process my images, right?

Re:The hard way is more fun (2, Insightful)

jellomizer (103300) | more than 3 years ago | (#33490978)

Well if you are coding professionally. You are wasting time going the hard route unless there is a real good reason to do such. Newbees want to show off that they can do all these things. Mature programmers know they can but if there is an easier way then go for it as it gets your project done faster and you look better to your boss who can give a rats ass on how you did it. Just as long as there isn't any consequences in the future.

Re:The hard way is more fun (0, Troll)

daveime (1253762) | more than 3 years ago | (#33491022)

Obviously the author had ImageMagick pre-installed on his Linux box, and has never had to actually install the fucker.

What a chore, pages and pages of mumbo-jumbo flying up the shell, then just when you think your done, it turns out it needs all kinds of extra libraries for certain filetypes (installed in VERY specific locations) to handle popular formats like JPG. Why in God's name the supposed "number one image processing solution for Linux" can't even handle JPG out of the box is beyond me.

It's not like you have to pay for the additional libraries, just download them from somewhere else, make some extra incantations, and sacrifice one extra chicken.

Re:The hard way is more fun (1)

dodobh (65811) | more than 3 years ago | (#33491090)

Which Linux distribution doesn't ship with ImageMagick? RedHat, Debian, Fedora, Ubuntu all ship with it.

Re:The hard way is more fun (1)

jlarocco (851450) | more than 3 years ago | (#33491144)

Trolling?

apt-get install imagemagick

Was that so hard?

Re:The hard way is more fun (0)

Anonymous Coward | more than 3 years ago | (#33491254)

I tried ImageMagick once. Its JPEG compression is, I'm sorry, awful. It produced much larger files with very poor image quality than anything else I tried.

Re:The hard way is more fun (0)

Anonymous Coward | more than 3 years ago | (#33490394)

Not only hard way is "fun", but the guy doesn't know what scalability is. You can't *buy your way out* as he writes regarding scalable systems. You can't throw hardware at a problem that does not scale.

Re:The hard way is more fun (4, Insightful)

hedwards (940851) | more than 3 years ago | (#33490424)

Eh, isn't that the basic difference between a programmer and an engineer? When I took my programming courses, there was a distinct focus on writing code with the smallest amount of new code possible, using preexisting libraries whenever possible and if there was any suspicion that the code might be useful later to split it off into a subroutine or method of some sort as done in the particular language. Sure it's a good idea to be able to write your own libraries and solutions, but it's a waste of time once you get to the point where you know how to do it. And generally using a library that's shared by other projects is much less likely that you're going to stumble on an undiscovered bugs with your program.

Re:The hard way is more fun^H^H^H educational (1)

petes_PoV (912422) | more than 3 years ago | (#33490504)

You might learn something from doing things the hard way, but all you'll achieve is a version #1. As we all know (or will learn) version #1 of pretty much everything should be thrown away and should NEVER see the light of a production server. However, timescales being what they are as soon as an application gets close to functional it gets snatched away and put live - no matter how ugly it is. After that, all you ever have time for is to patch the worst parts. Doing a complete rewrite from the ground up, to do it right, is a luxury few of us experience.

Re:The hard way is more fun (1)

Morth (322218) | more than 3 years ago | (#33490680)

The problem is that you're far more likely to end up with crappy code. If you want to ask your user for a password, it's insanely much easier to do a system("stty -echo"); instead of learning the ioctls to accomplish the same thing, plus you get portability for free.

I recently replaced a SMTP protocol implementation with a pipe to /usr/sbin/sendmail. Guess what? It worked much better.

Re:The hard way is more fun (1)

jgrahn (181062) | more than 3 years ago | (#33490860)

The truth is that the "hard" way of doing things is often more fun, because you have the challenge of learning a new tool or API.

People are different. I hate learning new tools and APIs (although I like learning the ones I already use better).

By extension, I distrust the people who're constantly looking for excuses to play with new toys. When they get tired and give up half-way through, people like me have to clean up after them.

I guess the real issue is that you have to engineer a "good enough" solution rather than a "worst case" solution.

If you mean you have to write shitty code so you don't risk being 70% done at deadline, I don't think that's true. But you probably should use techniques you know well.

Re:The hard way is more fun (3, Interesting)

msobkow (48369) | more than 3 years ago | (#33491166)

Actually I volunteer for the projects that are going to expose me to something new, rather than only taking on projects where I already know how the solution will work. The latter are bread-n-butter to the company, the former are the future of the company.

For example, I've spent the past year on a Freeswitch project rather than on the older Asterisk based code. Freeswitch scales better, is better architected, and is more flexible. The downside was spending 3-6 months working with the Freeswitch team to resolve issues with the code.

In the end, Freeswitch is where we are going; Asterisk is where we were. At the time that the Asterisk code was started, Freeswitch hadn't even reached it's first release, so Freeswitch wasn't an option back then.

Next up is a rework of the database IO codebase so that it becomes feasible to plug-n-play different databases. We could do it with the existing code base, but it would be very painful, kludgy, and difficult to maintain. Instead we're going to make a clean break on our next release to a new architecture for the database code. Sure it'll take longer at first -- but by the time we're on to our third database we should be well ahead of the curve and saving time.

Lesson #8 (4, Insightful)

pedantic bore (740196) | more than 3 years ago | (#33490304)

Don't ask for advice about programming on slashdot unless you have a pile of salt grains ready.

Re:Lesson #8 (4, Insightful)

thoughtsatthemoment (1687848) | more than 3 years ago | (#33490636)

That applies to other sites as well. So many people are trying to preach than genuinely teach. The internet is great for seeking specifics, but for insight on programming, it has to come from within yourself.

HUH????? (1)

Schnoogs (1087081) | more than 3 years ago | (#33490314)

His first rule is crap. Shit...he didn't even make it out of the gate without stumbling.

There are so many obvious exceptions to that rule. Better inform my boss we can no longer access more than one database!!! LOL

Re:HUH????? (0, Troll)

Anonymous Coward | more than 3 years ago | (#33490532)

Agreed. The entire article is awful.

newfangled stuff is not worth the risk

That's why you test new stuff, idiot.

If you have a process running and you want it to be restarted automatically if it crashes, use Upstart.

Hang on a minute, new stuff is not worth the risk, apparently. Perhaps when he said "Upstart" he meant "mon", or "monit", or one of the other well established process monitoring tools?

Parallelize When You Have To, Not When You Want To

I'd like to see this wonderkid take his non parallel code and parallelize it in five years time when he realises his non-parallel implementation doesn't scale.

Crap, crap, crap, crap, crap.

Re:HUH????? (0)

Anonymous Coward | more than 3 years ago | (#33491300)

I'd like to see this wonderkid take his non parallel code and parallelize it in five years time when he realises his non-parallel implementation doesn't scale.

From reading his other articles, you deal with the lack of scaling once you have a working product that people actually use. The huge majority of the time the load levels never appear to make scalability remotely relevant.

But I'm sure you're built lots of apps with millions of users, right? That's why you're hanging out on slashdot...

3 things I've learned. (4, Insightful)

Anonymous Coward | more than 3 years ago | (#33490324)

Sometimes it's easier and faster to code from scratch than it is to use off-the shelf software - especially in the age of "frameworks".

In that train of thought, its often better to toss and rewrite (or write new programs) than it is to extend existing programs.

It's easier to implement a whole new framework than it is to convince your boss that writing anew is actually faster.

Here's MY list (-1, Troll)

.Bruce Perens (150539) | more than 3 years ago | (#33490334)

Programming Things I Wish I Knew Earlier

1. Don't get into programming and do something else.
2. Bathe periodically.
3. Dried cum on your keyboard looks like donut glaze, but tastes radically different.
4. Open Source is a great idea, but altruism doesn't pay the rent.
5. Parents will eventually charge rent.
6. You can't get your name removed from Diakantana's credits.
7. CTL-C, CTL-V. Took me 15 years until someone showed me that shortcut.
8. The sun, it burns.
9. As far as your family is concerned, "network admin," "programming," "database management," ... to them, it's all "computers."
10. Linux sucks.

Re:Here's MY list (-1)

Anonymous Coward | more than 3 years ago | (#33490498)

hehe, reminds me of linuxcon 2000. Before the .com crash, when VCs were throwing money around and life was good. I was hanging out in Taco's suite at the hotel (VA Linux must have rented out the entire floor). Cowboy Neal shows up with a box of plain donuts. And a skank girl. She proceeds to give taco, hemos, and pater a blowjob, spitting into a cup when done. Do I want some? Hell yes! She had some good blowjob skills. Afterwards, Pater takes the cum cup and glazes the donuts. He took them downstairs, so I can only assume what happened next.

Later, I found out the girl giving blowjobs was actually a tranny.

The Kitchen Sink (0)

Anonymous Coward | more than 3 years ago | (#33490362)

Python already has a library to do the details for you. Perl does too, but the documentation may or may not be as nice and may require a separate install.

python -c "import this" (0)

Anonymous Coward | more than 3 years ago | (#33491064)

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!

Don't code in C (-1, Flamebait)

Anonymous Coward | more than 3 years ago | (#33490376)

Don't program in C if Python will do the job.

C is good for things like device drivers. It is pathetic that professors tell their students that they can do anything in C. We used to say the same thing about assembler.

Choose the right tool for the job. You don't have to use an expensive knife to carve a roast but it beats the heck out of trying to do it with a piece of flint.

until you find out why Python doesn't do the job (3, Informative)

tepples (727027) | more than 3 years ago | (#33490476)

Don't program in C if Python will do the job.

But in a lot of cases, Python does not do the job. It doesn't do the job on iOS because Apple has explicitly banned everything but Objective-C++. It doesn't do the job on Xbox 360 or Windows Phone 7 because IronPython uses Reflection.Emit, and the version of .NET used by XNA doesn't support Reflection.Emit. And it doesn't do the job on Nintendo DS because the runtime uses up a lot of the available 4 MB of RAM.

Re:until you find out why Python doesn't do the jo (1)

iammani (1392285) | more than 3 years ago | (#33490792)

But in a few cases, Python does not do the job.

FTFY.

Re:until you find out why Python doesn't do the jo (1)

TheLink (130905) | more than 3 years ago | (#33490834)

Funny thing is sometimes you wait a year or two and:
1) The C guy still hasn't finished the job either (at least not got all the annoying bugs out).
2) Intel and friends now let you use Python to do the job ;).

Not usually true (hopefully ;) ) but, a few years ago I wrote some TCP/IP servers/services in Perl and they performed OK, it wasn't my stuff that was falling apart regularly due to load, unexpected/malicious input, etc.

Thanks go out to Intel, AMD and the DRAM bunch :).

The smart phones are already more powerful than many old PC desktops still creaking on merrily...

Re:until you find out why Python doesn't do the jo (4, Insightful)

daveime (1253762) | more than 3 years ago | (#33491160)

Look, the PHB usually wants the code to run on HIS server for HIS use only. That's what he pays you for. Not to code it in the most cross-platform friendly language-du-jour and take 2 years to iron out all the bugs.

He doesn't give a shit if it'll run on the Xbox 360 or a Linux-ready Dead Badger.

And neither should you, unless you are some kind of anal retentive who spends all day arguing the merits of absolute versus relative positioning, fixed vs percentage tables, and worrying whether your code will run on every machine conceived in the next 50 years.

I have news for you, it won't.

Hell, I got an N900 6 months ago, and it's already EOL'd as far as updates to the OS are concerned.

I suppose I could wait till there's a port of Android or something, because the three coders on the project are doing a fine job, in less than a year I'll have the same functionality as a 3210.

Re:Don't code in C (1)

PenisLands (930247) | more than 3 years ago | (#33490918)

You're wrong. C is more like a swiss army knife which has a chainsaw, a sword, a lightsabre, a rod of destiny, and a diamond tipped blade. Python is like a playdoh toy, and that's why it's so popular with the Ubuntu developers.

Re:Don't code in C (3, Insightful)

topham (32406) | more than 3 years ago | (#33491088)

No. Sorry, I strongly disagree.

C is like a swiss army knife that can be used to assemble a chainsaw, a sword a lightsaber, etc. You'll have to carve out all the pieces, file them down and put them together yourself, but the swiss army knife will help you a long the way.

But don't forget the bandaids.

dicQk (-1)

Anonymous Coward | more than 3 years ago | (#33490378)

xargs <-> mapreduce? (1)

Anonymous Coward | more than 3 years ago | (#33490396)

I guess I'm an idiot, but.. err... did someone REALLY use mapreduce to solve an argument passing problem (the domain of xargs), or is the writing just shit?

Re:xargs mapreduce? (3, Informative)

tepples (727027) | more than 3 years ago | (#33490522)

I guess I'm an idiot, but.. err... did someone REALLY use mapreduce to solve an argument passing problem (the domain of xargs), or is the writing just shit?

xargs and its successor GNU parallel [wikipedia.org] implement the "map" part of MapReduce.

Making use of a database (4, Insightful)

sphealey (2855) | more than 3 years ago | (#33490398)

A database is not a bitbucket. Re-building basic database functionality in an external app is not a good idea. Applications, frameworks, languages come and go; data remains forever [1]. Business logic is part of the database. If you find yourself adding more and more "application servers" to get performance than you have a fundamental problem with your architecture (and probably a fundamental misunderstanding of how databases work). While it is not impossible to learn and implement good data management/database development practices using Microsoft tools, such a result is seldom seen in the wild.

sPh

[1] Per Tom Kyte of Oracle, whose first database job at the Department of Agriculture involved working with datasets stretching back to 1790.

no MVC pattern... (1)

drolli (522659) | more than 3 years ago | (#33490412)

unless tcl/tk wont do the job

2-port programs, Linux, PIL, expensive hardware (4, Insightful)

tepples (727027) | more than 3 years ago | (#33490426)

If you are writing a program that touches more than two persistent data stores, it is too complicated.

I disagree. Is a program too complicated if it has 1. input, 2. output, and 3. logging? Is a program to prepare images for an online store too complicated if it reads 1. raw source images and 2. an overlay image and writes 3. finished images?

If Linux can do it, you shouldn't.

That'd be fine if we all ran Linux. But in an organization that already has to run Microsoft Access for other reasons, we have to take Windows into consideration. And I don't think Ted Dziuba was talking about just using Windows as a shell to run Linux in VirtualBox OSE either.

Don't do image processing work with PIL unless you have proven that command-line ImageMagick won't do the job.

Our programmer is far more experienced in Python than in bash, and if I felt like it, I could benchmark PIL against subprocess.Popen(['convert', ...]).

if the physical machine is not the bottleneck, do not split the work to multiple physical machines.

Yet PC game developers split a 4-player game across four PCs when one could do, and increasingly, PS3 and Xbox 360 game developers are following the same path.

It is far more efficient to buy your way out of a performance problem than it is to rewrite software. When running your app on commodity hardware, don't expect anything better than commodity performance.

If you are writing software to be used internally, sometimes springing for better hardware is worth it. But if you are writing software to distribute to the public, you can generally assume your customer has commodity hardware unless your software costs at least 1000 USD a seat.

Re:2-port programs, Linux, PIL, expensive hardware (1)

Peach Rings (1782482) | more than 3 years ago | (#33490976)

Funny how in the same post he bashes EC2 for selling brute-force massive scaling and then says it's better to buy more hardware than to fix your application...

Re:2-port programs, Linux, PIL, expensive hardware (1)

SanityInAnarchy (655584) | more than 3 years ago | (#33491314)

Actually, he bashes EC2 for virtualizing away the hardware, meaning you don't know how long fsync takes.

But then he bashes people for not benchmarking. So... erm... benchmark EC2?

Re:2-port programs, Linux, PIL, expensive hardware (1)

JamesP (688957) | more than 3 years ago | (#33491042)

I disagree. Is a program too complicated if it has 1. input, 2. output, and 3. logging? Is a program to prepare images for an online store too complicated if it reads 1. raw source images and 2. an overlay image and writes 3. finished images?

Logging is write-only for the program. But yes, the definition is debatable (not the 'spirit' so much).

If Linux can do it, you shouldn't.

That'd be fine if we all ran Linux. But in an organization that already has to run Microsoft Access for other reasons, we have to take Windows into consideration. And I don't think Ted Dziuba was talking about just using Windows as a shell to run Linux in VirtualBox OSE either.

But windows and libraries does a lot as well. The problem here is reinventing the wheel.

Don't do image processing work with PIL unless you have proven that command-line ImageMagick won't do the job.

Our programmer is far more experienced in Python than in bash, and if I felt like it, I could benchmark PIL against subprocess.Popen(['convert', ...]).

Yeah, debatable. But it's sometimes easier to do in ImageMagick, if you need only file->file ops.

Re:2-port programs, Linux, PIL, expensive hardware (0)

Anonymous Coward | more than 3 years ago | (#33491216)

if the physical machine is not the bottleneck, do not split the work to multiple physical machines.

Yet PC game developers split a 4-player game across four PCs when one could do, and increasingly, PS3 and Xbox 360 game developers are following the same path.

Except in the case of a 4-player game, the physical machine is the bottleneck. You can't have 4 players simultaneously use the same set of input peripherals, display, speakers, &c.

I RTFA (3, Informative)

Jorl17 (1716772) | more than 3 years ago | (#33490430)

I just RTFA. It isn't that good. These aren't many tips and they also don't seem to be too specialized. Most of them are already known or predictable. I can say that I didn't learn anything from TFA.

I think that anything that reads "___ things to know about ____" or similar gets instant hits on /.

-1, Boring from me; hope it helps others.

Re:I RTFA (0)

Anonymous Coward | more than 3 years ago | (#33490698)

What would the Daily WTF do if it wasn't for these kind of mistakes?

I wish I'd known that CMS's are really hard (2, Informative)

petes_PoV (912422) | more than 3 years ago | (#33490434)

Sure, you can do all the superficial stuff with simple point and shoot. But I wish I'd known (before I started?) that to do anything beyond that meant diving deep and dirty into PHP, Javascript, CSS, DOM, and a whole lot more alphabetti spaghetti.

And that's before you get into the really difficult stuff (that very few have managed to master) of getting a website that is easy to navigate and intuitive to use

Re:I wish I'd known that CMS's are really hard (1)

Peach Rings (1782482) | more than 3 years ago | (#33491008)

That stuff is really easy though, and it's a lot better to have to muddle around in PHP and HTML/CSS/Javascript than to have a "platform within a platform" with pluggable modules and highly configurable styles.

My advice... (0)

Anonymous Coward | more than 3 years ago | (#33490466)

Don't listen to other people they are the biggest source of painful misconceptions.

What I want people to remember (4, Informative)

93 Escort Wagon (326346) | more than 3 years ago | (#33490492)

Don't assume that, even six months from now, you're going to remember why you did things a certain way.

And the corollary: Don't assume you're going to be the one modifying the code a year or two from now.

Either way: Add comments liberally. Even if you're a conservative.

Re:What I want people to remember (1)

AnonymousClown (1788472) | more than 3 years ago | (#33490776)

I agree. Here's what I normally do when I code - regardless of language (For 'C' style languages):

/* (and a lot more asterisks)
* Function: FooBar
*
* Input: void.
* Output: Returns 'true' if there's a bar
*
* Purpose: This function checks to see if there's bar etc...etc...etc...
*
*
* (a lot more asterisks)*/

I tell you my employer LOVED it. It made it much easier for the Indians to understand my code when they took it over after the company canned me.

Re:What I want people to remember (1)

daveime (1253762) | more than 3 years ago | (#33491220)

please sir to be sending me an explanation of your code. I am reading your comments, but you have not explained HOW function FooBar works, only that it is doing something and getting this result. there is no input, so what bar are we checking ? please to be answering quickly sir, as my employer will be withholding my $2 an hour salary until I fix this.

Thing I wish _others_ would know (5, Insightful)

melted (227442) | more than 3 years ago | (#33490548)

Do not make things super-modular and generic unless they 100% have to be. In 99.9% of the projects no one, including yourself, will use your stupid dependency injection, and logging / access control can be done just fine without AOP. Don't layer patterns where there's no need. Aim for the simplest possible design that will work. Don't overemphasize extensibility and flexibility, unless you KNOW you will need it, follow the YAGNI principle (you ain't gonna need it).

Re:Thing I wish _others_ would know (0)

Anonymous Coward | more than 3 years ago | (#33490952)

I'd combine this with the earlier replies about thorough commenting:

When you follow that advice and don't make things "super-modular and generic", for !#%!%! sake, document the limitations of your quick-and-dirty implementation in the code. If it does the job at hand, then there is nothing wrong with it at all. Get it done. But at least take a few seconds to put "NOTE: Does not handle case X" or "Depends on this being true", so that when someone tries to re-use your code later, you will realize whether or not it is up to the task. This holds even if you are only writing code for yourself, such as when you come back to the code months or years later after you've remembered "Oh yeah, I did something like this before", but forget the limitations. Writing reliable, generic, modular code is difficult and time-consuming. Writing "Beware of this limitation" is not, so do it!

I'm just re-writing some code now. The original code made the assumption that there would be only one return from a listing of files with a particular pattern -- so I said exactly that in the comments. I also said if the assumption was ever wrong it would have to be fixed. It sure made things a lot easier when I looked at that code months later because it was breaking in certain situations, and there the problem was, already documented as something that might someday need fixing. Even better is if you put a little trap in the code to pop up a "This should never happen, but if it does it needs to be fixed" message at key points. It saves the time of implementing a condition/fix you don't think will be necessary, but still provides useful information if it ever does.

Re:Thing I wish _others_ would know (3, Insightful)

Anonymous Coward | more than 3 years ago | (#33491190)

(too lazy to log in)

hear hear.

i'm working in an over-architected codebase now and all the Design Patterns thrown in haven't done squat for making it flexible or modular,
they've just made it obtuse.

This is te problem with Linux (3, Insightful)

bogaboga (793279) | more than 3 years ago | (#33490562)

"Modern Linux distributions are capable of a lot, and most hard problems are already solved for you. You just need to know where to look."

First off, I must say this piece says a lot about the Linux ecosystem. Specifically that this system's documentation is anemic at best. Why won't we have something like:

"What do you want to do?...with an associated answer...this kind of arrangement surely cannot hurt the Linux ecosystem.
 

Re:This is te problem with Linux (3, Informative)

jpate (1356395) | more than 3 years ago | (#33490922)

apropos

Re:This is te problem with Linux (2, Informative)

costing (748101) | more than 3 years ago | (#33491150)

whatis apropos

Overengineering can be a good thing (5, Insightful)

caywen (942955) | more than 3 years ago | (#33490564)

You know, I find that as I get older, I am able to avoid overengineering things a lot better than when I was twenty something. There's nasty effect, though. I'm learning a lot less in depth about systems than I normally would.

Overengineering is terrible for a project, but it often is highly educational.

In Defense of Not-Invented-Here Syndrome (1)

satuon (1822492) | more than 3 years ago | (#33490640)

... When you're working on a really, really good team with great programmers, everybody else's code, frankly, is bug-infested garbage, and nobody else knows how to ship on time. When you're a cordon bleu chef and you need fresh lavender, you grow it yourself instead of buying it in the farmers' market, because sometimes they don't have fresh lavender or they have old lavender which they pass off as fresh.

I read this in Joel Spolsky's article (http://www.joelonsoftware.com/articles/fog0000000007.html) but I think he has a point.

One more tip (2, Informative)

Posting=!Working (197779) | more than 3 years ago | (#33490660)

Visual Basic - Don't. Just don't.

It's always great to learn a language then have the company change it so drastically in the next version that all your knowledge of the language is useless. I don't believe it'll be the last time that happens either. I do know I will never bother to learn another MS programming language again.

Good luck to all you C# programmers when they switch to C#.NET, or whatever they call the next one. Hope you like reading!

Time for some pedanting the pedants (0)

Anonymous Coward | more than 3 years ago | (#33490718)

Most of that stuff isn't even part of "linux", strictly speaking. No, I can't resist pointing out this nitpickery after having been annoyed to death by "gn00/linex/debjan" and all the overlong designations that crowd of painfully annoying pedants felt on slapping onto systems that worked Just Fine without their oh-so-open goo. Like, just about all modern members of the BSD family. Thanks so much for that guis. Anyway. If we're to be properly open-minded about our tools, one could argue that "linux" is just as much part of "Unix" these days as the entire at&t Unix and BSD families and perhaps even minix and a bunch of others are. Why be so centric on a single mass of code?

Yes, and no (2, Informative)

drwho (4190) | more than 3 years ago | (#33490736)

Some oversimplified philosphy, some good hints. Programmers and SysAdmins who do a lot of resource management eventually become managers. This isn't neccessarily a bad thing, as the world needs more managers with extensive experience with that which they are managing, and the respect of those people they are managing. It's true that it's silly to adopt some software, technology or process just because it's new. But Ted seems to be resistant to any change, which is not good either. The problem with "don't fix it if it ain't broke" reasoning is..what do you do when it eventually breaks? This is a mistake made by many in process control / automation eniveronments: failure of a part which is so obsolete that it has become difficult and expensive to obtain a replacement. Just try to find a new motherboard with an ISA bus these days. Or a composite monitor. The same thing can happen with software and the OS..where are you going to find a guy who knows enough about that old Kaypro which was running some COBOL software on CP/M, which controlled the electroplating machinery? This is why companies have lifecycle management, so that the pain of switching to newer software / hardware comes with predictable cost and timetables instead of sudden, possibly prolonged unavailability and expensive, awkward, band-aid fixes.

This flows into the idea of organizational amnesia, where important processes become lost. This is perhaps best illustrated by the US DoE forgetting how to make this secret substance called FOGBANK, which is a critical component of H-bombs. Upper management felt as though, because there was no need for additional H-bombs, the process was unimportant, and didn't take into account that H-bombs become (more) dangerous with advancing age, and eventually these needed to be replaced. It took considerable time and money to re-engineer FOGBANK.

These are both examples of failure to consider that all equipment wears out, and failure to plan for long-term needs.

Anonymous Coward (0)

Anonymous Coward | more than 3 years ago | (#33490746)

"The purpose of software engineering is to manage complexity, not to create it."

Bill Catambay, Pascal Programmer on Macintosh and Open VMS

Sounds like good advice (0)

Anonymous Coward | more than 3 years ago | (#33490828)

I've been building a website. Mostly its just a big pile of bash scripts building everything. I have one script that calls about a dozen others. It builds Apache from source, PHP from source, MySQL from source, and my content manager Typo3 from source, plus a dozen support packages all from source, patches (hardens) PHP and adds in a security module, patches Apache (modsecurity2), configures everything (all scripts and configuration files, get configured from this one main script), and also builds an ODBC driver plus builds ODBC connectors for OpenOffice, all from the one main script. With nothing else running, my CoreI7-920 runs at 800% for about 20 minutes. I have a backup script mostly using rsync to back everything up once per week. I wrote the bash scripts, but I didn't write the web server, database engine, interpreted web language or content management system (although I have heavily configured all of them). If I ever needed functionality exceeding the bounds of what the pre-built packages can do, then I would write a program (likely in C) to provide the functionality. Its just a matter of efficiency. If I can get 90% or 95% or 99% of the functionality I need at 1% of the effort (or whatever the ratio is between writing a software package yourself versus just configuring a pre-built one), I get much more done in a smaller amount of time. Likewise, its easier to modify the Apache source code, rather than building my own web server from scratch. If I really wanted to build my own web server from scratch, I suppose I would. But alas, the desire is not within me.

What is this? (1)

MacGyver2210 (1053110) | more than 3 years ago | (#33490992)

I was hoping for some actual programming tips or tricks.

This was completely irrelevant to me, and aside from the NoSQL review, not even that interesting.

Don't name your stack (1)

NotSoHeavyD3 (1400425) | more than 3 years ago | (#33491020)

q since that makes no sense. (Yes, I've seen an open source project with a stack that had the name 'q'.)

Pipe to a subprocess in C too (1)

WebManWalking (1225366) | more than 3 years ago | (#33491030)

I don't know if Linux has everything Unix has, but in C on Unix, you can call popen() to pipe to a subprocess from within compiled code. That allows you to use any utility that reads from stdin or writes to stdout. That goes along the "don't do stuff that Linux already does" and Python subprocess.Popen sentiments.

Some tips from a C guy. (4, Interesting)

Murdoch5 (1563847) | more than 3 years ago | (#33491066)

Hey

I know these might sound odd but hear me out. Start by trying to rewrite the basic library's. make your own printf, strcpy. strlen etc..... Write copies of your own link list and tree storage methods and above all really really start to understand how memory works.

Another really really important thing that I have learned is stay FAR FAR away from OO programming until your really really comfortable in lower level languages. The reason is that to many students and beginners sit there trying to figure out why there variable started with value X and ended up with value Y only to find out that there object bashed some memory earlier on.

Basically just grab a good C compiler, I mean C COMPILER, not C++, not C#, not F# and start to learn how all the functions you use on a dailiy basis work, it will give you new insight into why and how you can quickly avoid and fix problems when and before they happen. It's also important to get a really really good handle on using a CLI over a GUI, Stay away from Visual Studio and other simular compilers. Use GCC and CC and make sure you look at how LD is working and understand how compilers do optimizations and improvements to your own code. This post is taking about grabbing tool to do Image processing and preform functions that have working solutions. However taking the time to see how the solutions work and why they work will give you good insight into not only great code design but great programming methods. It might seem odd for me to suggest to a beginner to try and rewrite strcpy or strcmp, but once you see how they really work you'll be far less likely to make the simple mistakes that can ground your program / project from working. It's the same say with with a beginner figuring out how malloc works and where memory gets taken from and put to, all of these suggestions are coming from the way I learned to program in C and other languages.

Feel free to throw any of these away or take any of them into your own programming adventure, but one thing is for sure. When you can figure out how the basic functions you use every day work it will save you hours and days of trouble shooting and leave you with a greater pallet of tools to use in the class room and on the job. I welcome and one who wants to add ideas to this post and attack it with there own view points.

Ok, I will bite (1)

Zangief (461457) | more than 3 years ago | (#33491078)

How does xargs replace hadoop, even in trivial examples?

Unless you are talking about running hadoop in a single machine, which is just waaay too trivial an example.

Don't program! (0)

Anonymous Coward | more than 3 years ago | (#33491084)

I have a shock collar around my neck hooked to my computer, it activates if I attempt to use any IDE, compiler, or script interpreter.

Oh if you find yourself repeating some code (1)

NotSoHeavyD3 (1400425) | more than 3 years ago | (#33491098)

Consider making it function, especially when you've repeated the same 8 damn lines over 70 times. (Yes, I've seen that one too. Yes it bit the guy writing it in the ass and no it wasn't me, I had to code review it.)

So whats the argument against PIL? (1)

synthesizerpatel (1210598) | more than 3 years ago | (#33491174)

I read his page and the comments here and I can't seem to find any arguments on this?

Comment your data too! (5, Insightful)

LihTox (754597) | more than 3 years ago | (#33491194)

I'm in a different boat from most commenters here, I think, because I am a scientist writing simulations; some simluations run a long time and create a lot of data which would be costly to reproduce, and what I wish someone had told me early on was that I should comment my *data files*, not just my code. Each file should include the exact parameters used to create it, an explanation of what each column represents, and preferably there should be a way of knowing what version of your simulation code was used to create it. A couple of times in grad school I had toss out months of data after I discovered a bug in my code, and didn't know when the bug showed up and which data was affected by it.

(I'd welcome other advice from simulationists too; I've never had an advisor who was particularly programming-savvy, even though programming was always a large part of my research, and so I always had to make it up as I went along.)

"Easy" solutions vs time (1)

gmuslera (3436) | more than 3 years ago | (#33491236)

Sometimes you have a command, an app, something, that makes things trivial or are already installed and are easy to use instead of installing a complex heavy app to do that. With a good amount of pipes and installed by default command line software you can do complex processing in a lot of data, or do a somewhat trivial python/perl script for that, But sometimes you don't know exactly what, or learning how to do it would take more time than the "non optimal" way. The priority is to solve problems, if takes too long to learn how to do it in the "right" way you first must solve it. And then learn how to do it right for the next time

Emotional Things I Wish I Knew Earlier (2, Insightful)

daseinw (244962) | more than 3 years ago | (#33491258)

we could not figure out whether the author was an incredibly elaborate troll or just a run-of-the-mill idiot.

Reading this comment of his reminds me of something I read recently:
Physicists stand on each other's shoulders. Engineers dig each other's graves.

I've never understood why so many software developers feel the need to disparage one another in an attempt to prove their intelligence/superiority. There are plenty of tough problems out there and we all can learn something from one another, no? I've definitely been guilty of this in my tech career but lately I'm wondering more and more, why does the person who has a different solution always have to be an "idiot?" Why isn't he/she just someone who has a different take on solving this particular problem?

Now, I'm not saying that engineers do this more than any other group but out of all of my friends (some of whom are doctors, lawyers, teachers, etc.) it certainly seems like a more common event among software developers.

Don't do it unless it's absolutely necessary (1)

Draco_es (628422) | more than 3 years ago | (#33491276)

Resist the urge to start coding and think hard about the problem your program will solve. If it can't be solved without coding, resist again, and design every piece of the program carefully, and, paraphrasing Dijikstra think about LOC's as lines spent, not lines produced.

social advice, especially applicable to geeks (0, Offtopic)

FuckingNickName (1362625) | more than 3 years ago | (#33491296)

You're not that great.

Even if you think you're the best person in your department, there are other departments.

Even if you think you're in the best department, there are other firms.

Even if your organisation's top of its league, empires rise and fall, and so will yours.

There is no silver bullet. You are no Superman. You're not going to change the world.

So shut up, listen and chill. Feel free to do your best, but remember to be nice. Money buys you hookers, but love gives you peace.

flock() works just fine? (1)

Rogerborg (306625) | more than 3 years ago | (#33491310)

flock() isn't POSIX, doesn't have a standard behaviour across Linux/Unix/BSD platforms, can and will deadlock a process against itself, doesn't play well with either fcntl() or lockf(), doesn't work on NFS mounts, but does work on o2cb-based ocfs2 clusters, and God alone knows what the version(s) of Python / Perl / Java on your target system(s) are using to do locking under the hood - and He sure won't have documented it for you.

Doing it the easy way works 95% of the time, but if you don't take the time to find out what's inside that handy black box, you'll have a hard time putting it all back together (often on a customer site, and always at 11pm at night) when it does finally explode on you.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?
or Connect with...

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>