haar

I prefer using the comments/discussion themselves as an indicator to whether I'll find the article a worthwhile read in the first place - how often do users actually comment/discuss an article without reading it beforehand? What's the point in that?

I feel like I must be in the minority here: I enjoy multiple (smaller, 28" max, sub-24" preferable) displays.

I run iTerm2 in full screen with Vim split alongside 2 or 3 console panes; I find the separation from the rest of my OS a blessing. The second screen I use for Chrome, HipChat, Flint, Sparrow etc; I still notice chat notifications, and to keep a eye on my dock (which displays all notification counts across my multiple programs) is a simple key combination if I'm in 'the zone' and don't wish to break out of my programming environment (iTerm2).

I've tried larger screens in the past, and found myself physically looking around the screen a lot more, simply due to having all my content splatted together.

Combine this with a keyboard-based window manager and the 1/2 - 1/4 screen segmenting and I feel much more organised and efficient than trying to manage a 30"+ monster of a screen.

If you were to ask anyone in my office, you'd hear how much I praise TDD as a software development practice. However, when I'm absolutely clueless as to how to even begin to tackle a technical problem (usually due to not enough understanding of the overall system requirements), then I start by spiking the problem - trying to get a feel as to everything that's required. This initial spiking I wouldn't test-drive, as it's a learning process and not production-ready code.

After I've got a strong enough grasp as to the overall requirements, then I throw away this spiked code to start fresh, working along similar lines to 'programming by wishful thinking' whilst keeping the original spiked out structure in mind.

By following a strong TDD philosophy, it's easier for me to throw away my initial 'spiked out' code base for a couple of reasons:

1. Personal experience of how much better a test-driven code base can be than ones I've later tried to wrap tests around/dismantled in the process. 2. Having the understanding from the get-go that this code is not 'production-ready', and should not be considered reliable, but as a very fast learning experience. 3. Knowing that I've spent a small time prototyping as preparation, and having this laid out as an overall part of the process means I'm not considering this time 'wasted'.

If I were to have one question to ask the author based on that blog, it would be 'What job/career does his other half have?'.

I have pretty much free-roam of where I am, considering I work remotely and have flexibility over which hours I work due to clients in numerous time zones, however my girlfriend is a micro-biologist which makes where she can work rather limited to Universities and other research locations.

If you've been rotating them against a surface in that time period; then they'll certainly be a lot more round than when they started.

Thank you. I really enjoyed the concept and was playing around with Floobits last month, but found it quite testing at times using the vim integration.

My colleague was using the ST integration, and found that sometimes he would be locked out of a file completely after I'd done some visual block changes. I'll give it another whirl some time and provide proper feedback if it still exists.

Multi-pane input via cmd-shift-i, and saved pane/window configurations through cmd-shift-s and cmd-shift-r also come in handy.

Using the "back" and "forward" swipe motions on OS X 10.8 (Chrome 24.0.1312.57) broke the site for me.

EDIT: Scrap the swiping, just pressing back and forward on the site break it.

The first half of our initial Haskell module covered breaking the enigma machine, it was great fun and the lecturers made sure to give the back story in detail covering both the british and polish efforts (probably in an attempt to make the module appear 'cooler'). It was a great module and I have the upmost respect for Turing and the unsung Polish efforts made in breaking it.

The critique I was hoping to get was more aligned with the technical and UX aspects (design, usability, etc), of which I've seen numerous high quality examples (and discussions of) demonstrated by the HN community.

Not to mention the sound would sometimes lag behind my typing (I only wrote three sentences until I had to close the tab), which sounds somewhat similar to scraping your fingernails down a chalk board, only with more bass.

You don't have to use the rspec controller matches if it's outside of what you're used to/how you understand it. You can use response.status.should == 200.

  Try out ZSH if you want to try something slightly different to Bash
  Package Manager: Homebrew - https://github.com/mxcl/homebrew
  Terminal/Emulator: iTerm2 - http://www.iterm2.com/
  Vim running in iTerm2 via Homebrew
  Chat Client: Adium - http://adium.im/
  MySQL DB GUI: Sequel Pro - http://www.sequelpro.com/
  Mail: Sparrow - http://sparrowmailapp.com/
  Git GUI: GitX (L) - http://gitx.laullon.com/
  Window "manager" : Shiftit - https://github.com/fikovnik/ShiftIt
  General productivity: I love QuickSilver, however it's been crashing
  quite frequently on me since I installed Lion, so I'm giving Alfred a try at the moment.

Note: all of the above are at least free (lite), if not completely free. I was thrown completely in the deep-end with terminal vim and just took to it as part of my "getting used to Mac" steps, which I think benefited me with respect to getting down with the nitty gritty of it and not complaining it was different to my Notepad++ experience prior on Windows.

You have several typos in the Joosy website (unless it's part of a joke I'm unaware of, as they repeat the same incorrect \n correct pattern).

    ack -l "Deterimes" | xargs perl -pi -E "s/Deterimes/Determines/g"

in your root if you don't want to search for them manually.

Note: requires ack installed (like grep, but typically much faster and nicer to use, for me at least).

Dota2 has a co-operative play against AI players, and I assume you can play this mode on your own if you wish; however this entire genre typically focuses on multiplayer values to get the most out of the game. For example, there is no storyline, and the gameplay depends entirely on working together with your team-mates to overcome a huge range of situations that develop from different hero line-ups.

It requires a lot of effort to get information. The embedded auto-playing video reminds me of pre-Facebook social networking, requiring further effort turning it off (especially after scrolling down trying to figure out what's what) before a user can then move their cursor around the site to access the content they wants.

The HackerNew extension makes searching from the search bar at the bottom of the page extremely difficult.

An alternative use-case would be when using a program such as Adobe Photoshop, rather than launching Photoshop, clicking File, open, navigating to your desired directory, selecting which files to open the pressing open; if you already have the directory open, drag the files onto the Photoshop icon and it'll open them.

Even if you test manually what you just changed, in a relatively complex codebase how can you guarantee that your changes haven't broken behaviour in a separate yet related aspect of the system?

This is what I find the major advantage of a comprehensive test-suite to be, I don't have to worry as much about breaking any part of the system as a whole - if my suite passes, then I know everything I've worked on so far works, not just the bit I think I changed.

The API page seemed to break on smaller resolution pages (read: thinner).

I made several drawings of a similar nature to those shown when I was a child; I'm not sure if my parents still have them or not - though it spanned more from my fascination for mathematics than physically seeing them.

I use tir_black for Vim (Terminal Vim via iTerm2 with xTerm reported); I find it softer on my eyes that a lot of other colour schemes I've tried.