@jasonlotito did great job saying what I'd already planned on saying. I'll just add that it can be easy to write off signs, or to say you can cope with it, especially when one is successful.
I was surrounded by clear ADHD cases growing up. They were more-or-less bouncing off the walls and constantly getting in trouble. I knew I wasn't like "those kids". But the inattentive types—those that can't focus or tend to hyper-focus on one thing to the detriment of others—fall through the cracks because they're not acting out. And, if they're otherwise high-performing, they'll be able to pull through their work with the occasional forgotten assignment or scheduling snafu. Teachers, bosses, even the affected themselves seem to think just need to concentrate harder and they'll do better next time.
But, telling someone with ADHD to concentrate harder is like telling someone nearsighted to squint if they can't see the chalkboard. And it's not a flaw in their character anymore than myopia is.
Anyway, I don't know your life or backstory, just that seems pretty familiar to me (tried pomodoro, thought of/started on a similar system before abandoning it in graveyard that is my ~/Projects folder). If any of this has struck a chord, I've found that simply changing my work circumstances have helped me immeasurably. Two years ago, I was working at home and left to figure out every choice and solve every problem in a pretty open-ended project. I'd spend hours reading papers, tutorials, and blogs with little to show. Now I'm in an office with an open floor plan and a team working toward a common goal with a time constraint. Medication would probably help me even more, but I exercise quite a bit and am wary of side-effects. Therapy would probably be even better, especially because, while my organization and execution at work has gotten better, my own tasks are about where they were before.
If you're interested, I found "Driven to Distraction" by Hallowell & Ratey to be a pretty good reference (although, if you get through the whole thing, you might not actually have ADHD).
Old, but good, and apropos given the Prop 8 and DoMA discussions in the US Supreme Court. While it uses gay marriage as an example, it's really good rundown of several things that may seem "fixed" in any database schema design problem and how you might (or might not have to account for them).
Looks interesting, but can we get some background about why it's particularly remarkable? I haven't heard of the author, and though it's an interesting topic, there seem to be a lot of other textbooks in the same field. What's special about this one?
I feel like something similar could have been said about Xmonad. Yet, through its configuration and extension mechanisms, it's become a gateway for a lot of people wanting to learn Haskell. This niche isn't likely to fragment as long as it's made up people obsessively scratching their own itches.
I think the author and Armstrong have significantly different ideas of what a "type" is. That's not a huge surprise—depending on background, you'll often get several definitions from different people.
One way to see types are things with fundamentally different access pattern: individual entities, sequentially retrieved ones (e.g. lists), fixed-length ordered lists whose elements are accessed positionally (e.g. tuples/vectors, fixed-length maps whose keys are known at compile-time/records/objects can also be viewed this way), unordered collections of distinct entities (sets), etc. I'd argue Armstrong's view is similar to this based on what he put in Erlang.
I can't tell what the author's view is, aside from "a class is a data type". This suggests that he equates a type with the set of functions that can be called on something and not have the compiler or runtime blow up (or perhaps, the set of functions that the programmer, by putting them in the same file, has explicitly said won't blow-up, whether or not that set is correct or complete). This throws fundamentally different things like lists, tuples, sets onto the same level as Person, Account, and PayrollRecord—which are often just short-hand names for tuples with different arities or names for their elements' positions.
If one has the later view, confusion over the point 3 is understandable: creating a new type for time is easy, just do class Time and define a bunch of properties and methods. In Armstrong's example, time is just a 6-tuple (or 3-tuple if all you want is hms). If you wanted to store it or send it over the wire, anything that could handle a tuple of integers would already know how to use it. If one function calls the last member "sec" and another "second", they're local names, so it doesn't matter as long as they're both accessing the same member.
One can object that it's easy to write serializers or that a compiler or library could figure it out, or that having different names for the same data elements indicates inconsistency in code that should be caught earlier. De gustibus non est disputandum. But, don't throw up your hands and say "this makes no sense!" without considering another perspective first.
Or, if the masters are too hard at first, see if their pupils have written annotations. I tried Turing, couldn't even understand why what he was talking about was important (or why his "computers" seem so much... lamer than the ones I was used to), and then found Charles Petzold's "Annotated Turing".
He takes Turing's "On Computable Numbers..." and mixes in chapters giving the necessary background on the history of mathematics, number theory, logic, etc. in-line (albeit, it takes about 100 pages to get to the first sentence of Turing's paper). I whole-heartedly recommend it.
I love Trello. I've been using it to plan my wedding. At first my fiancee was worried that it would add too much overhead. (She was never overly concerned that it was spectacularly nerdy to be using a software project planning suite—and that's a sign I found a keeper.) It's really shined with the guest selection/invitation process.
We created a couple of lists to group and sort guests into Definite, Good to Have, and Maybe lists and used labels to relations to whoever wanted them, which really helped with the friends and extended family that the other didn't know. We used checkboxes to track addresses that we were waiting on, who's save-the-dates have gone out, etc. I've used the API to total up people for the headcount (since cards we often for "Jack & Jill Smith"). If we were doing assigned seating, we'd probably make lists for each table and move the cards around. Thankfully, we decided to go for heavy hors d'oeuvres.
The thing's versatile: very few things feel like they're driven by the project planning domain (e.g. voting for cards). I'd love to see some kind of ability to embed scripts and save some checklists as templates that I could apply to cards with one or two clicks, but the API access suites my needs right now (and I know some people are using Greasemonkey scripts).
I'm only a somewhat familiar with the geography there, but IIRC, it's similar to what's described here:
"Cables almost never land in industrial zones, first because such areas are heavily traveled and frequently dredged, second because of pure geography. Industry likes rivers, which bring currents, which are bad for cables. Cities like flat land. But flat land above the tide line implies a correspondingly gentle slope below the water, meaning that the cable will pass for a greater distance through the treacherous shallows. Three to thirty meters is the range of depth where most of the ocean dynamics are and where cable must be armored. But in wild places like Porthcurno or Lan Tao Island, rivers are few and small, and the land bursts almost vertically from the sea. The same geography, of course, favors pirates and smugglers."
Anyone else having trouble finding a good definition of "Structured Dialogic Design"? Apparently it's been used in the Cypriot peace process, but I can't find a good description of how it differs from "getting a bunch of people in a room to talk about a problem".
I'm hoping he threw that term out as a teaser for part 2.
How would you describe the attention to craftsmanship of software in scientific computing? The most illuminating thing about Climategate to me was the state of the software: is this kind of code widespread? Is there interest in improvement? If I went to work for a research team and suggested pairing, code reviews, version control, continuous integration, or other accepted good practices from my experience in software development how would that be received?
Also, the dilemma in my mind is whether I can stand going back to grad school in my late 20s for a career I don't really know much about. I'm not sure if you can speak to that experience, but would you say it's been rewarding?
I'll admit I'm struggling not to anthropomorphize Spirit too much here. Maybe it's the face-like features of the mast mounted pan-cam. Maybe it's that XKCD strip from awhile back...
Or maybe it's the compelling story of excellent engineering that created something able to keep expanding our knowledge of the Universe so much beyond what was planned.
Either way, I can't help but feel a twinge of sadness, even as I say congratulations to everyone who worked so hard to make it the succes it was.
I'm not sure why "encourage" is in quotes. If you mean, "inspire the next generation of city planners and architects to design places that people want to actually live" you're right. But I'm reading a more dismissive tone and I'm not sure why.
Jacobs' work directly contributed to the decline of the urban superblock (that mainstay of 1960s urbanism and blight on 21st century cities) and a rebirth of the mixed use development. The later is especially popular in inner suburbs going through phases of new growth looking for an antidote to their original strip-mall and subdevelopment plans (usually lack of plans).
So any word on if it'll be closed or open when it's done? I wouldn't mind paying (especially if that would speed delivery of a usable product), but I'd be worried about it becoming abandonware a couple years later (cough TextMate).
As a bit of meta-commentary, I have to say: it's exchanges like the one's between you and jsdalton and you and pakeha that make me love HN. It's pretty rare to see such honest conversation and useful, constructive criticism both given and then accepted in the spirit it was given. Thanks to all of you.
First off, I think this is pretty well-reasoned. This part struck me as interesting:
"I believe tests should be written in the language most natural for the problem... I have never coded my way through a surfing session."
To take that a step farther, we usually don't write prose-form descriptions of surfing sessions either. Following that, it seems the language most natural to describe a user interacting with an application through a browser is a straight recording of clicks and form interactions (if I understand correctly, this is what Selenium IDE tries to accomplish, although I've had problems with that particular tool), rather than Cucumber's descriptions, which compared to that, are more like code.
This is why I abandoned Cucumber: it seemed to be another way of writing code and left me on the wrong side of the gap between specification and actual interaction. I don't fault anyone who has found it to be valuable—as the poster said, it's possible to write good tests with any tool. Choose one you like.
Thanks, I've been looking for a crank adjustable base like this. The motor-operated ones seem overly complex for a task that could easily be accomplished manually and the OP's 2 person solution struck me as horribly inefficient.
Definitely not a new idea—I remember something like this running through the dorms in 2000. Still, it's a good example of using the existing notoriety to pivot and the Facebook integration is certainly something we didn't have back then. In any event, good luck!