@AviD I don't know about grunt, but tox which is apparently a very similar tool for python, allows me to test against several python versions with a single command. That's the advantage. Good integration when you use tools native to your language.
@Adnan that is the reason. They build HTTP and it obviously lacked (and lack) some functionality so, instead of fixing http, they just "invented" JS, and PHP, and CSS, and flash, and ASP, and shockwave, and... To sum up, a big ball of mud.
@TerryChia I've written Perl and Python at some point, but still would like to actually write bigger stuff. I think I'll convince @Kisunminttu to start learning with me. That'd give me some motivation.
@AviD I'm curious, how do you feel confident enough to review code in a language/framework largely unfamiliar to you? I'm guessing it's a skill I'll have to pick up sooner or later but it usually takes me at least a month to feel confident enough to do anything substantial.
actually in this case, I didnt realize it was node.js. They just dumped a pile of javascripts on me. To be fair, this was simply the test/mockup faux appserver.
And as such, it was pretty trivial. I'm sure they didnt use a fraction of the available functionality.
@CodesInChaos do NOT get us started! ;-)
@TerryChia but as a general answer to your question. I have some experience in picking up a new framework/language/etc, with the perspective only of looking for the security holes, and usually the low-hanging fruit at that.
I wouldnt feel at all confident enough to write the code, especially not if its going straight to production. but reading code is a different skillset.
Personally, I do try to avoid it, especially the hipster frameworks. Even if only because I would be less efficient.
@TerryChia to begin with, sure. But I've found that it is pretty easy to go far beyond that, fast.
> Hackers start reading the manual one page after the developers stop.
once, I had to review a coldfusion app. This was in Netherlands.... and I had the 5 hour flight to read a ColdFusion book.
Luckily, I had a "ColdFusion Security" novellette... and unsurprisingly, by the time I got there I was able to shock the experienced CF devs with a few loopholes they'd never considered.
@AviD I remember a time I got sent out on a test + Java Code review in a team of two, so I assumed the other guy knew about Java code review.. turned out not to be the case
@AviD yeah luckily it turned out the code didn't do much just passed everything to an out of scope back-end system, so it was just piles of constructor stuff...
@TerryChia if you have enough experience in several different languages / frameworks, you could usually pick up just enough syntax and peculiarities to have a clue what the code is saying. Then it is just a question of finding the common mistakes, loopholes, bad practices, and antipatterns.
To be fair, to a large extent this isnt even about reading the code, but the system design. The code is just the implementation of it, and most flaws are not in the code.
@AviD Oh no. In an enterprisey system, the string that you want to print should be stored in an XML file to make it data driven. You know... separation of concerns and all that.
@RоryMcCune That means they bought this oven off the shelf and then modified it with an arduino-based board. It's basically the same oven just with a new brain that knows how to heat using temperature profiles etc.
@RоryMcCune You should. It makes it easy to do things without paying a horrendous amount of money for them. I'm working on a board with an RF wireless chip like the one in most wireless mice that has a barometric pressure sensor and a humidity/temperature sensor that will help me predict inclimate weather.
To collect all of the data all i need to do is walk by them with a board with the same chip and an SD card
@RоryMcCune Yeah i hear that... Fortunately it's what i do for a living so there isn't much that i need to study outside that i already study for work
@RоryMcCune If you do want to get started with that sort of thing I'd recommend getting an arduino. But it really depends on what you know to start with.
btw @TerryChia re code review in an unfamiliar language - another huge part of it is knowing programmers, the way they work, patterns they use and mistakes they commonly make. This is mostly irrelevant of a specific language.
It's like with poker - you don't play the cards, you play the players.
after talking with a programmer and discussing the application (and a few pointed questions), I can often predict with a high probability most of the types of bugs I will find in their code.
this says less about me - and more about programmers being predictable.
@AviD I'm not sure if I could determine the type of bugs I'd find. But I can tell with pretty good certainty the quantity.
Helping a customer one time, I had an hour phone call with a developer who did part-time work for them and wrote a particular component. After talking to him, and knowing nothing about the code that he had written, I already knew that the customer would bee needing someone to re-do his work from scratch within the next year.
It "worked" of course. The same way a motorcycle built of toothpicks and wood glue can be made to *work" at least till it's turned on.
@AviD he makes a very interststing point. Well, several i guess
I don't like his conclusion though. He seems to be suggesting that some people are exceedingly good at the initial skills acquisition phase but don't get deep enough in any one territory. I think I find the opposite to be true.
People get moderatly good at one thing, and don't branch out so they don't understand what they don't understand, and Dunning-Kruger themselves into mediocrity.
It's like, "I spent months learning [language X], so I do everything in [language X] because learning another one will take sooo long it won't be worth it"
every crappy programmer in the world says that
in school, one of our classes required us to lean a new programming language every week. One a every damn week. And all the homework is done in that new language. You start to learn how they're similar, different, you pick up the patterns. You begin to understand language design.
By the end, you can pick up a new language in an hour. It's just a matter of syntax and standard library.
@AviD those articles referenced about turnover and the "dead sea effect" make something that one of the Google interviewers said to me make more sense.
He told me that people there hop between jobs within the company all the time. He said (caveat: sample size of one) that if you leave your team in less than a year, it looks bad. But if you are still around after about 3 years, your boss starts wondering why you're still hanging around.
Most companies like you to settle in to a position, be predictable, be dependable. But if you cater toward the to x% of developers, I can see how your culture would reflect a certain need for constant change.
@AviD right. His story: he was working on team X for 2 years, and decided that team Y (something only vaguely related) would be fun to try. He tells his boss, and within a week, 2 managers from team Y's at different offices each take him out to dinner trying to convince him to join them.
Coming from "traditional" software companies, this seems almost silly. I'm intrigued enough to want to learn more.
I can see how a place like that would have little trouble retaining talented developers though. It's a classic (serious) problem that most companies face, and they seem to have solved it just by having more stuff for people to do.
@AviD at IBM there was lots of stuff to do, and it's reasonably easy to move within the company. But your departing group would fight to keep you if you were really good.
It wasn't till I was older that I understood just how unusual it was to work in a place that housed a sizeable server room, an army of lawyers, a set of presentation halls, a catered cafeteria, and an entire chip fabrication facility all in one building.
The only time I have (and probably ever will) troubleshoot a network failure while wearing a fully-enclosed bunny suit
Taking apart machines in rooms like that, you're totally thrown by the fact that even though somethings been sitting there for 7 years, there's absolutely no dust inside. It makes sense, but you don't expect to see it.
brand new / that old, and never been cleaned?? / WTF happened here?!? / Oh, that's awesome, get a pic of that! / HOW is it even working?? / OH CRAP ITS MOVING BY ITSELF CALL AN EXTERMINATOR!!!!
@AviD On my computer at one software company, they took out an old network card but couldn't find a blank to replace it. No big deal. A year later I open up the box to find that a mouse was now living there.
I had never thought that putting blanks in the old card slots was a big deal. Apparently it's what keeps out the rodents.
