Ha! I should totally know better, but for a second, I mixed up .com and .net and thought, "Ben has a blog? And posted about recipes? Did he pull them into his 8 bit computer or something??" I didn't realize my mistake until I clicked.
I don't think the article is an argument that as a hard rule CS majors are predetermined to be great job candidates. In fact, the author draws a line between students who take on side projects and are passionate about the material and students who are doing it for the supposed payout.
Recruiting software engineers is about finding the passionate engineers who are proven problem solvers regardless of programming language or given tools. Those people might be computer science majors, and they might be non-majors (or non-students) who have a passion and skill for problem solving.
I've worked with and learned from great engineers who did not formally study engineering and those who have devoted their life to it. It's ultimately about having the drive to pursue (software) engineering. Those people tend to self identify by enriching their education with their own side projects.
Ultimately, Computer Science education is (and should be) exactly what it says. The science of computing. It doesn't require a computer, and it isn't software engineering. By studying great algorithms, data structures, design techniques, etc, you are well on your way to skill set of a successful software engineer, not because you know about splay trees or automata, but because you have practiced advanced problem solving, which is at the core of any engineering.
Am I the only one who always feels that the search for "passionate engineers" really means "cheap, doesn't know his value, works for rent and pizza"?
What about competent? Professional? Experienced?
Nobody looks for a "passionate lawyer", that would even be a red flag, indicating that he can't evaluate a legal situation objectively.
Nobody looks for a "passionate basketball player". As long as he shoots those three pointers, who cares whether his secret passion is really boardgaming.
This is a very good summary of my intent in writing the article. I didn't mean to say that CS majors are inherently superior, but I wasn't pleased that the original article seemed to imply the opposite. I believe that computer science education the way I described it gives you a better chance, but doesn't necessarily make you better.
This one in particular uses the jQuery onepage-scroll plugin [0] for the scrolling effects, prism.js [1] for code syntax highlighting and some plain HTML and CSS. Here's the complete code: https://github.com/emisfera/Splitchar.js/tree/gh-pages.
In reference to some other comments on this thread, this isn't built using Jekyll. GitHub pages supports pure static sites and Jekyll-powered sites if you put either on the gh-pages branch of the repository.
You're right, thanks. I'm finally home and managed to look at the source, it doesn't use Bootstrap. The author built it all from scratch. Kudos to him.
Hiding your content below the scroll and having a single, tiny, ambiguous, low-contrast visual indicator that more information is below seems to be "the in thing" in web design in 2014.
This one actually uses the canvas element instead of svg. Just another awesome thing about D3: it works equally well with both. You can draw svg paths just as easily as you can draw them on a canvas.
Cool example of canvas[0] vs svg[1]. The canvas renders heavy animation a bit better. Both are around the same number of lines of code.
Ah! Thanks so much - I was wondering how this maze would work as a collection of svg elements. I'll look into using d3 with canvas for a project I'm doing.
IME, it gets pretty laggy beyond a few hundred svg elements. The catch to using canvas with d3 is that you lose the ability to bind event handlers to the canvas "elements" (since on a canvas they're not DOM elements, just pixels).
For my latest project I used a kineticjs canvas to get handlers on the canvas shapes. That's positioned on top of a d3-bound svg container. Best of both worlds, reasonable speed up to a couple thousand canvas shapes. Though it was quite tricky getting the same input events to trigger separate handlers on sibling dom elements. (Can't just let the events bubble up unless you make the canvas a child of the svg or vice-versa, but that approach creates more problems.)
It's awesome to see interesting algorithm visualizations in D3 (or other web standards) as opposed to Java applets. Especially as a student who has to do algorithm visualizations... in Java applets.
A few years back Jamis Buck did a survey of maze generation algorithms: http://weblog.jamisbuck.org/2011/2/7/maze-generation-algorit.... The different algorithms seem to create mazes with different 'feels' to them. For instance recursive division algorithm appears more blocky and some have more dead ends than others. This d3 generator appears to be toothy (lots of short dead ends) on the right edge of the maze.
Interesting! I did a maze flooder last year http://bl.ocks.org/robinhouston/6023888/653206574a69127d7fa2... using uniformly random mazes[★], and the flood-filling is much less uniform. The uniformity here must be a reflection of the way the maze was generated.
★ There are algorithms that generate each possible maze with equal probability, if by maze you mean a spanning tree of the grid graph. I used such an algorithm, Wilson's algorithm.
