Go the programmer matrix and figure that each point is going to cost an employer $5000 (for the sake of argument). So if you have a budget of $75,000 you get to assign 15 points. Even if you spread around those points as much as possible, you are still going to end up with a lot of level zeros.

Of course everyone wants to hire a guru or rock star but a) they come with their own management challenges, b) the only way to afford one is to pay in dreams (start-up) or be in the business of printing money (hedge fund).

Great tip (link)! As a developer in a do everything yourself tiny, tiny business, I don't have many peers to compare myself to; and the ones I meet are often "former ICPC team member"-grade.

But do points really cost that much? I'm afraid that we won't be able to hire anyone extra for a long, long time then , I'd spend 6 on just the Computer Science part if not more, having 2.5, 3, 2.5 myself there really, really helps with cracking the harder stuff. 2-2-1 at least would be my minimum...

At 15 points, I would have zero idea where to place them, I'd rather beg for a higher budget than pick where to cut myself...

With 32 categories, hiring someone on par will cost... Aww. And at 5k per point, it's way more profitable to work as wage slave than free man... Aww #2.

I guess I'll have to be glad here in .nl, that wages top out at ~$100k USD pre-tax (and being deep in the 52% tax bracket means keeping not very much of it), and it's really hard to negotiate past $60k for an employee. I know an excellent rocket scientist (literally) at $45k, and he had to get approvals all the way to the top for that exceptionally huge wage. But this way attracting international talents will never be viable.

No they probably don't really cost that much. If nothing else higher steps should cost more than lower ones.

My point was that you can't get someone that's good at everything unless you want to pay an insane amount of money. Your more usual choices are an expert in some narrow area, or someone with broad but shallow knowledge.

It escalated pretty quickly. I still derive a perverse pleasure from seeing people espousing the inane notion that comments are the silver bullet that will turn lead developers into golden ones.

I'm only digging this up because I'm currently trying to figure out what the full list of various error categories postgresql can prepend to a message when logging. I did not find what I was looking for here, but for someone that can barely understand C, I found the comments in this piece of code to be pretty educational:

Looks on par with other often reused code like the Java Classpath. Any less makes your life painful as a consumer of the API, Android often just documents the easy part and leaves out critical details, you've to read the source to be safe. Non API stuff is way more horrible too, reading com.android.calendar makes me want to go STABSTABSTAB on whoever committed that junk.

Byte alignment is highly overrated. Strings of 7-bit characters and 25-bit signed integers for all!

I did some testing if this for some over the wire protocol where I didn't want to force padding on some variable length stuff unless I needed to. No performance difference in my usage on recent intel hardware. Disclaimer: deliberately no SSE going on (no operations performed on the values, just writing them around the place). Apparently anything past nehalem (IIRC) has next to no impact there either (though obviously you're not quite as efficient on cache line boundaries.

^ True, but maybe it would be useful if you wanted to convert an existing PHP codebase? Depends on what you get out of it--if it's unreadable then it's no use. If you can do a first pass with that thing and then pretty it up and fix a few bugs, it could be very useful.

Convert to what -- js running in a PHP VM? That sounds fairly useless. It wouldn't actually let you convert a PHP web application to a javascript web application, because the architecture, model, and libraries are totally different.

I suppose if you thought PHP-language was horrific, but PHP-the-ecosystem was wonderful it might make a certain sense. But AFAIC they are both horrific.

Convert to what -- js running in a PHP VM? That sounds fairly useless. It would actually let you convert a PHP web application to a javascript web application, because the architecture, model, and libraries are totally different.

I figured that just converting a bunch of logic/syntax would be a good first step. But probably you'd want to start fresh with idiomatic code.

It looks like the real motivation was to allow an in-browser PHP editor or REPL or something.

Yeah, I know. IsAsync on the FileStream is false. I'm just not sure whether to be pestering the mono mailing list about it or the linux list (or distro-specific one) or even how to go about answering that question. I'd be sort of surprised if aysnc I/O is flat-out impossible on Ubuntu though.

Silently creating a non-async object instead of what I asked for is pretty questionable behavior. I can find out what happened via the object's properties, but if I have to manually check return values for error conditions that's a good indication there should be an exception.

We went Python/Django for most of our web based works after being horrified by a few jobs modifying PHP sites, it has served us well so far, but I'm missing static typing and Java's superior tooling every day. But Python is just so full of magics, even if you can write and understand all of it, it's still annoying when things just don't work as expected. So I'm looking around again for languages and frameworks with proper IDE support and static or optionally static typing so having a code base doesn't mean you have to memorize all of it.

Scala/Java/Play looks kinda nice, except some trouble with getting Eclipse or IntelliJ to work properly the first time and the general lack of documentation. Little things like just get Scala IDE instead of get the latest beta, earlier ones won't work, or open template as Scala file will crash with a ClassCastException, known issue, but it's recommended in the documentation and Google has only questions, not answers. IntelliJ was even worse, as the Play generate IDEA project files thing is broken and you'll have to go into many dialogs and fix it yourself, get the latest nightly Scala plugin, know to grab SBT as well, etc.

At least it seems to have some big names deploying it in production, but I wonder if it's good in actual use.

-The general code quality of Play is very good. They know what they're doing.

-The Java APIs are a shitshow. As far as I'm concerned, Play should really be considered Scala-only.

-Akka is great. The Akka integration in Play is greaterer.

-Scala templates are a great idea in theory. In practice, waiting for them to compile is pretty brutal.

-SBT is just plain Not Good and you'll hate it if you have to do anything except the most basic things with it. Have fun.

-Configuration (like, per-server) is really annoying. It's not really built for use in a multi-app environment and you'll end up repeating yourself left and right. (I ended up with a Python script that wrapped their SBT calls, passed in local configuration files, etc.; that helped, but it was still pretty rough going.)

-Communication is a problem. There is no community to speak of. There is a Google Group; that's not a community. Decisions seem to be made offline and there doesn't appear to be much visibility into the project's future. Tickets on Lighthouse go ignored and requests for direction for things you'd like to contribute likewise are left untouched. And their IRC channel is dominated (in volume) by asshats (and mind you, this is me calling them asshats, that is a fairly high bar) who desperately want Scala to be Haskell.

Overall, more good than bad, but I'm very comfortable with the building blocks that compose stuff like Dropwizard and it's easier for me to just bolt together my own and get rolling.

If IDE support is a must, though, you're probably screwed. I never found it particularly onerous to set up in IntelliJ even before they had their ownest own speshul plugin for it, though.

When I said "Django", I really meant excluding the templates part - we ripped it out and replaced it with Jinja2 which is much nicer, back then, even simple expressions were impossible leading to {% ifequal a b %} instead of {% if a == b %}, and expand that for ifnotequal for every operator...

If Scala templates are a lost cause for IDE support, so be it, we're used to using an "html" editor and ignoring funky warnings caused by special tags. It's the model part that must be maintainable, once you go over 100k, Python is bleeeeeh. At a first glance Scala seems to be pretty alright, ctrl-space everywhere while doing the tutorials kinda work. Template, if it's crap, I bet there's a way to replace the renderer, can't be worse than monkey patching django core in the 0.96rc1 days

I'll just give it a try, it can't hurt to learn another thing. Akka looks promising as well, my experience with concurrency is limited to classic threads and java.util.concurrent.

Cross-platform async I/O would probably best be described as a clusterfuck. That goes for any language (not just Mono); there's a lot of inconsistency out there.

If, as your code implies, you're working with an external device (a USB device, in this case), it's possible that async I/O isn't possible on the platform you're targeting.

Async I/O is always possible, even if in the worst case the system has to emulate it with blocking I/O in a background thread. And if a framework is unwilling to do that then it should throw an exception when it can't open a file asynchronously.

Yeah, I know. IsAsync on the FileStream is false. I'm just not sure whether to be pestering the mono mailing list about it or the linux list (or distro-specific one) or even how to go about answering that question. I'd be sort of surprised if aysnc I/O is flat-out impossible on Ubuntu though.

It has nothing to do with the distro, but what the kernel supports in that situation. UNIX filesystems were traditionally synchronous I/O only. Moreover, when they do support asynchronous operation, it's not through the "typical" select/poll non-blocking mechanism but rather the AIO mechanism.

Cross-platform async I/O would probably best be described as a clusterfuck. That goes for any language (not just Mono); there's a lot of inconsistency out there.

If, as your code implies, you're working with an external device (a USB device, in this case), it's possible that async I/O isn't possible on the platform you're targeting.

Async I/O is always possible, even if in the worst case the system has to emulate it with blocking I/O in a background thread. And if a framework is unwilling to do that then it should throw an exception when it can't open a file asynchronously.

Ugh, environments when background threads aren't allowed (hardware can't handle multi-tasking!). On the plus side, when I go to implement async IO myself, I will have DMA hardware that will let me know when it's done.

Yeah, I know. IsAsync on the FileStream is false. I'm just not sure whether to be pestering the mono mailing list about it or the linux list (or distro-specific one) or even how to go about answering that question. I'd be sort of surprised if aysnc I/O is flat-out impossible on Ubuntu though.

It has nothing to do with the distro, but what the kernel supports in that situation. UNIX filesystems were traditionally synchronous I/O only. Moreover, when they do support asynchronous operation, it's not through the "typical" select/poll non-blocking mechanism but rather the AIO mechanism.