mVChr

This is a particularly insightful (if snarky) comment.

The project I just had to refactor had a DSL that was completely unnecessary and had a ton of business logic tangled up within the domain language itself. I ended up being able to remove the DSL and parser completely in lieu of using simple config files and extracting the business logic into middleware.

The DSL was probably originally created due to some Slideshare presentation that had just hit the top of HackerNews 3 years ago. The original devs molded the problem to fit the ability to use a DSL and cool parsing library rather than figure out what the most suitable design for the problem was.

I find Sublime's Cmd-Alt-↓ (goto definition) to be very useful since you jump straight to the source code for that function/class/method. When you grep you may also get all the usage instances which can be quite a lot of noise.

I've spent the last year rebuilding a huge business-critical system from scratch (along with one other engineer). Yes, usually complete rewrites are a Bad Idea®, but in this case product and business decided it was the only way to move forward because the system was in maintenance hell and it was way too difficult and risky to add new features. I discovered why as I learned the architecture, business logic and features of this behemoth pile of spaghetti. Here's what I recommend to do if you're in a similar situation, whether it be a large and great project or a large and horrible project...

- Get a functional dev environment set up where you can mess around with things in a risk-free manner. This includes setting up any dev databases and other external dependencies so that you can add, update and delete data at will. There's nothing that gives more insight than changing a piece of code and seeing what it breaks or alters. Change a lot of things, one at a time.

- Dive deep. This is time consuming, but don't be satisfied with understanding a surface feature only. You must recursively learn the functions, modules and architecture those surface features are using as well until you get to the bottom of the stack. Once you know where the bottom is you know what everything else is based on. This knowledge will help you uncover tricky bugs later if you truly grok what's going on. It will also give you insight as to the complexity of the project (and whether it's inherent to the problem or unnecessary). This can take a lot of time, but it pays off the most.

- Read and run the tests (if any). The tests are (usually) a very clear and simple insight into otherwise complex functionality. This method should do this, this class should do that, we need to mock this other external dependency, etc.

- Read the documentation and comments (if any). This can really help you understand the how's and why's depending on the conscientiousness of the prior engineers.

- If there's something that you really can't untangle, contact the source. Tell him what you're attempting, what you tried, exactly why and how it's not working as you expect, and ask if there's a simple resolution (I don't want to waste your time if there's not). You may not get an answer, but if you've done a lot of digging already and communicate the issue clearly you might get a "Oh yeah, there's a bug with XYZ due to the interaction with the ABC library. I haven't had time to fix it but the problem is in the foo/bar file." You may be able to find a workaround or fix the bug yourself.

- When you do become comfortable enough to add features or fix issues, put forward the effort to find the right place in the code to do this. If you think it requires refactoring other things first, do this in as atomic a manner as possible and consult first with other contributors.

- Pick a simple task to attack first, even if it's imaginary. Get to more complicated stuff after you've done some legwork already.

There are other minor things but this is generally my approach.

The only time I've found talking about a project to be a good predictor is when it's a type of project or tech stack that I'm familiar with. In that case, I can ask very specific probing questions about problems I'd encountered with that problem or tech. In answering these questions whether and how often they talk about specific solutions they came up with versus saying something along the lines of "well I dunno, I wasn't responsible for that piece" or "I'm not sure about the details, I was more involved with the higher level decision making" can be very telling.

Hear hear, the "no assholes" rule is always good to apply, regardless of programmer brilliance.

One take-home project I was given was very cleverly designed. Without going into too much detail, the project description initially seemed pretty simple. The actual getting-it-to-work part took about half an hour. However there was a requirement near the end that said the whole operation had to complete in less than X amount of time. The initial straightforward implementation I wrote took about 8-times longer to complete. Eventually, 3 hours later, after pulling out a lot of clever tricks I had come up with an implementation that met the performance requirements. The benefit of this type of approach is that it allows potential applicants of many levels to understand and tackle the problem while also allowing them to choose to bail out after that 30 minute mark if they can't think of any way to improve performance. Seems like a polite way to set a high bar standard.

And the URL :/

Interesting case, thanks for sharing.

That's good to know.

Just out of curiosity, do you know how that interacts with indecency laws? Like for example if someone is having sex in their home but someone is able to see it from the sidewalk through a crack in the curtains? This is purely hypothetical of course.

> Communities such as San Diego, California are using mobile biometric readers to take pictures of people on the street or in their homes and immediately identify them and enroll them in face recognition databases.

In their homes? I'm pretty sure this is illegal. Or is it not if they are visible from a public area?

Likewise, typing on 2014 Mac Air currently, but my family's first computer was a Commodore VIC20 (I learned BASIC on that) and some years later my dad got me my own computer, an XT (8086) with a 20MB HD (how will I use all that space?!).

I loved both of those computers more than any I've had since.

Now I have a daughter. She won't be getting a Mac. She'll be getting an old box with some flavor of Linux installed and she's going to learn how to really use a computer (only if she's willing and interested, of course). The apps and windows will be there, but I am primarily going to focus teaching her command line and code. Otherwise it's just a gadget and a lot harder to love.

Yes, I was trying to remember his name, thank you.

EDIT: and since I can no longer edit my original comment: *cite

More likely a few years after his return, when public attention has waned, he would die due to an unfortunate accident of some sort, perhaps a hit and run or the like.

While this may sound like conspirilogic, I can site many similar instances of deaths of journalists and other instigators under mysterious circumstances in this country if necessary.

Bug note: if you're browsing by popular and add a book to your shelf, the page is kept in the query string but the popular=1 is lost so you jump to that page of date sort instead.

I had severe right arm problems and in addition to getting treatment from doctors was looking for every way to relieve the issues in my workspace.

I had a friend let me borrow a https://www.kinesis-ergo.com/shop/advantage-pro-for-pc-mac/ and it took a while to adapt to it but it ended up helping. I didn't want to keep it indefinitely so while I thought about buying one for myself I wanted to try something different. I did some research online and ended up buying a Truly Ergonomic 229. I liked the keyboard layout for the most part, especially the most used keys being on the central line, but there were a couple annoyances (top-left escape/tilde/1 order I never got used to and always typoed). The major problem to me was what seemed like a bonus at first: it's too compact. While it's easy to pack away in a laptop bag, it was impossible for me to get an ergonomic arm position. My forearms were always angled inwards with my hands and wrists angled out. This ended up exacerbating my right arm problem and I had to stop using it. Unfortunately I really wanted it to work and had kept at it past the refund period so it's just sitting in a drawer now waiting for me to throw it up on ebay.

If the http://www.keyboard.io/ models were available I would have tried one of them next but I ended up going with a Microsoft Sculpt http://www.amazon.com/gp/product/B00CYX26BC/ since the price was right after blowing the money on the TEK and I couldn't justify shelling out for the Kinesis now. I am still using the Sculpt and would definitely recommend it. I would also recommend the Kinesis if you're willing to spend the extra dough and don't mind (or appreciate) the archaic looks.

Useful aggregator and time-saver for voracious seekers of new jams. Having more than just EDM along with a filter by genre option would be nice for those of us who like DnB, Techno, Trap, etc.

You guys are missing a key factor. FB paid him $12.5k but didn't lose anything.

Find line of code containing bug and:

    git blame -L2469,2469 -- app/core/shitty_auth.php | \
        egrep -oh '[A-Z][a-z]+ [A-Z][a-z]+' | \
        xargs -I {} python dock_monthly_pay.py \
            --employee-name="{}" --amount=1041.67

> Compared to Haskell and Clojure, which are soaring to put it mildly.

Soaring comparatively.

I am a big fan of OCaml, but I think one thing this infographic is heavily biased by is ease of adoption for programmers of all levels. Javascript, Python and others in the top all have that. OCaml and the like are all a bit steep on that front.

However if you find OCaml in the tiny graph on the bottom you'll see that it's steadily increasing at least. Up about 50% in active repos from 2013 to 2014.

I'm talking piece of the puzzle not the entire pie.

Awesome! I've been meaning to mess around with Erlang/Elixir.

+1 for Sleep-Sort

Puppet drop may be due to options. Was just Chef, now is Ansible, Salt and even Docker.

And totally agree that Ruby is surprising. I'm a Pythonista myself, but always thought Ruby was fairly comparable if having a different approach. I don't have enough experience with it though to understand the possible reasons for the drop.

For a scientific paper, you are correct.

For practical or business purposes, this is a nice bit of incomplete information to help make a decision. I want to take a serious, time-invested dive into a new statically compiled language, but which one should I pick? An old die-hard or the new-hotness? I could make a guess from reading the docs and such, but I'd also want to know community activity and support. This is a handy chart for getting a sense of that.

Or, I'm a business owner who just hired my first engineer. He's saying the backend should definitely be built in Groovy, or maybe he'd be willing to do Scala or something else, but definitely Groovy, yeah, Groovy man. I might be able to get a better idea of which would be beneficial for my long-term business prospects (hiring more engineers, etc) by checking out a chart like this as I might not have time to do real in-depth research.

As a scientist you require complete, sound and accurate statistical data. As a business practice (this site is about start-ups, no?) you need to be comfortable making serious and important decisions based off of incomplete and possibly inaccurate information because making fast decisions is often paramount. You can and will always make other fast decisions later and decide whether it's worth the effort to course-correct if you need to due to new and more accurate information.

This is maybe too deep an analysis of a fun little infographic, but as a former professional poker player who made a living off of incomplete information you got my cockles up.

Back then Indie was called Alternative, don't you remember 90's kid?

Yeah, otherwise it would be http://www.the-erlang-must-flow.com/

Side-note: Soderbergh's editing is absolutely fantastic and original too (see: The Limey, Out of Sight). Fine, fine film-maker, one of the few to be able to cross from pure art film to Hollywood blockbuster and back again through everything in between with ease. It will be interesting to see where his "retirement" takes him.

And text-only cache for the spartan:

http://webcache.googleusercontent.com/search?q=cache:tjZs5Ve...

Right, you could do that, it was more a question about how the closures work.

How about distinguishing between public, private and protected properties? How about being able to quickly identify classes versus instances? How about explicit is better than implicit?

> - Identifiers are case and underscore-insensitive (FOO_BAR === fooBar === fo_ob_ar)

In the language design stages who in the world thought this would be a good idea? Even PHP doesn't do that.

What about variables nested within these functions then? Is scope enforced? i.e. you can reach back to variable aa in function a() from nested d() but can't reach variable dd in d() from a()?