wldlyinaccurate

This is really great. A friend and I were going to start building something like this, mostly because we were like "why the hell does something like this not exist already"?

> Some problems are complex and require complex solutions.

And yet some very complex solutions were solved with very simple languages, before Java was conceived.

Care to elaborate, or provide a link?

rawgithub.com is not raw.github.com. You can read about it on the homepage: http://rawgithub.com/

Apple certainly did copy a whole bunch of ideas from Android. But honestly, I think every single one of them looks much nicer on iOS 7.

Somebody correct me if I'm wrong here, but doesn't the .git directory essentially contain the entire history of the repository? The history could easily contain sensitive information like passwords. It will contain names email addresses of contributors, too. Try it yourself: cat .git/logs/HEAD

I recently discovered that I had been serving .git on my blog for a couple of years. All it took to fix was a simple rule in my Nginx config:

    # Don't expose hidden files to the web
    location ~ /\. {
        return 404;
    }

I think you really hit the nail on the head with this, especially with 3. The tryout project.

IMHO any sort of interview process is a crappy way to hire people. The best jobs I've had, I got by meeting people informally. Jobs where I've gone through a really formal interview process have always turned out "just okay" at best.

I'll just reiterate what other people have already said: If this is a serious project then stick with what you know. By all means, learn Ruby by using it for some side projects, but don't use it for serious projects until you really understand it or you'll just end up writing bad code.

If Soylent actually takes off and becomes popular (I really hope it doesn't btw. See my other comment for why), I wouldn't be surprised if some of the big food companies come down on them really hard. I mean, just imagine what this product would do to the food industry.

I'll admit that I'm very interested in Soylent, and I'd like to try it myself. But I completely agree with you on this.

Soylent is the sort of thing that could seriously damage your health. I know that several people have trialled it over the course of a few months, but nutritional deficiencies can take much longer to develop. For example I don't recall ever reading that oral health was being monitored during the trials - when you're not chewing anything, your teeth will fall out.

I'm sorry but I truly do believe that selling Soylent would be dangerous and irresponsible. Please, don't sell Soylent to anybody until you've done some proper clinical trials.

> The sensible answer to this is "just learn CoffeeScript, then".

No, the sensible answer to this is "just read the compiled JavaScript". CoffeeScript compiles down to very nice, readable JS. I would even go so far as to say that compiled CoffeeScript is easier to read than 90% of the JavaScript you'd typically find in a open-source project.

I don't understand how the driver being written in CoffeeScript affects your ability to use it. You can download a precompiled (JS) version of the driver and just use it, right? You don't _need_ to write CoffeeScript to use the driver.

No, no, no, no, no! This is a terrible idea, and will end up causing you a massive headache in the long-run. If I see commented-out code like this, I will delete it because that's what version control is for.

If you really need to turn code on/off in different environments, you should be using feature flags: http://code.flickr.net/2009/12/02/flipping-out/ and at the very least you should be detecting the environment:

    if (ENV == 'dev')
        testStuff();
    else
        productionStuff();

This is much more meaningful to other developers (and to yourself in the future).

So these people are now aware that they are in possession of a stolen laptop. Are they going to give it back? Will they cooperate with the authorities to track down the thief? For some reason I find this whole situation really interesting and I hope Dom gives some updates.

Thanks for the explanations. After reading my comment again I realise that I sounded like a typical Git elitist - sorry about that.

I'll turn it around and ask why, for simple tasks, is the CLI any better than a GUI ignoring personal preferences?

For me, the main thing is speed: I can type much faster than I can navigate a cursor (tab completion helps). I recognise that some GUIs have keyboard shortcuts to speed things up, but then at some point you're using the keyboard enough to justify using a CLI. The other thing is that I don't find graphical representations of my changes helpful at all. I commit early, commit often, so the output of `git diff` generally doesn't need to be paginated. My feature branches are small so I can merge them without the need to see a commit/branch graph.

To be honest it's hard to answer that without ignoring personal preferences because really, that's all it boils down to.

I can definitely understand the want to use a GUI when you're doing complex adds or merges. spacemanaki is right in saying that doing this a lot probably indicates a problem with workflow, though.

I know this sounds very condescending and even a little elitist, but usually when people say "I am proficient with a CLI but prefer a GUI" I hear "I have memorised a few commands but I don't understand them, so I prefer a GUI". The reason being that I have genuinely never found a GUI for an application which is simpler or easier to use than a CLI.

I'm just curious; you seem to imply that you find basic commands (add, commit, push, pull) easier to perform in a GUI than a CLI. Why is that? What is it about a CLI which isn't simple?

First, let me say that I do agree with this post. PHP projects are more often than not full of inelegant solutions written by bad programmers. The "running background tasks in the foreground" is a good example; one that I _hate_ seeing in production.

The thing that I don't agree with though, is that you've described a "capable" programmer who uses good programming techniques and obviously knows how to structure an application. If this programmer is doing the "background-in-foreground" thing and hasn't heard of message queues, then I would argue that they aren't a capable programmer - in which case you're just describing bad programming practices; not a fundamental flaw of PHP.

Yes, I'd definitely like to see Slim tested as a light framework. People keep mentioning Silex as a "light" framework, but I've found it to be almost as heavy as Symfony2 (which isn't much of a surprise considering it's just Symfony2 components strapped together).

Cake was an interesting choice for a PHP framework to test. I wonder why they didn't choose Symfony, which is arguably the leading PHP framework.

I didn't even realise you could type "help". There definitely needs to be some sort of introduction prompt otherwise people (like me) are just gonna leave feeling like they've learned nothing.

Still, nice idea.

London, UK

IPC Media is the UK's leading magazine and digital publisher. We're currently hiring DevOps, PHP (preferably Symfony) developers and front-end developers.

Lately we've been doing a bunch of fun stuff: - Reducing page load times across our sites - Implementing a continuous integration system - Switching to Git and embracing a better workflow with GitHub Enterprise - Building a new platform to serve our mobile sites

If you want to know more about the positions or about the day-to-day work, hit me up: "joseph_wynn" at ipcmedia.com.

I imagine they're using something like wkhtmltopdf[1] (WebKit HTML to PDF)

[1] http://code.google.com/p/wkhtmltopdf/

It's certainly an original and clever idea, but I don't think it makes the resume any more effective. In fact, I think being designed like an Amazon product page makes the resume less effective simply because most people have trained themselves to ignore much of what is displayed on an Amazon product page.

Cached version: http://webcache.googleusercontent.com/search?q=cache:XgCJqd4...

I love Laravel, it's the simplest and most expressive PHP framework that I've used, and it does everything I want it to do out of the box. I really like that Laravel 4's API is practically identical to Laravel 3, too.

Btw you can browse the code on GitHub if you don't want to download it: https://github.com/laravel/framework

If dh42.com was behind CloudFlare, it wouldn't be down right now.

This is just my opinion, but I think detect_indentation should always be turned on. The reason being that having mixed indentation in a file is worse than having the "wrong" indentation.

This post reminded me that 90% of the developers I work with don't set their editor up properly. I'm constantly finding Windows line endings and trailing whitespace. I wrote this (really short) guide that I send to new developers, but imo editors should come configured like this out of the box. http://wildlyinaccurate.com/setting-up-your-editor

I really like the design and the interface, nice work. One thing I found a little confusing is that if you go "back" and then "forward", the "forward" action seems to load a random quote instead of returning to the one you were on.