What exactly are you trying to say?
1,658 karma · joined January 10, 2009
Interests include NLP, algorithm analysis, programming languages, and photography.
Contact me at dave@madwombat.com.
Modals are also really really hard to make accessible, and are often confusing. If you MUST use modals, please use a well-vetted library instead of rolling your own.
There's a lot of things that look really cool but make life difficult for people that aren't you. We appreciate your consideration when you build your UX. <END OF PSA>
Standup at 9:06 is important, though. In order for pairing to work, you need to have everybody there at the same time.
The iron bargain is that you work a rigid eight hour schedule, but then you go home (or wherever) and don't think about work. No overtime or crunch mode, ever.
It's not for everybody, but many folks really really really like it.
We switched to Go because Ruby's concurrency model was obtuse/inefficient and scaling the codebase was challenging even with excellent developers and great engineering practices. The performance gains with Go were a really nice bonus.
If you're solving Google-style problems like writing a PAAS, then the benefits of Go outweigh the headaches. If you're writing a more straightforward CRUD-style Web API, then Rails might be a better choice.
People sometimes work less, due to doctor appointments, child care, home repairs, and such. However, they never work more.
My personal suspicion is that optimal is probably in the 35-45 range, but I'd love to have more data.
Code quality shows up in your velocity over time. My favorite saying right now is "quality is future speed". We also do regular reviews to assess things like cyclomatic complexity and how well SOLID principles are being followed.
Sustainable pace is super important for creating and maintaining high performance teams. Crassly, it's just a more profitable way of doing business.
I wish more managers would stop buying into the myth of "time in seat == productivity", and look at the real output of their teams. When you actually run the numbers there's a lot of results that run counter to conventional wisdom.
People with more strenuous computing needs are miffed because the MBP used to fit our use case, and now it doesn't. There isn't a single Apple product focused on the high performance market any more, and some of us are bitter.
You can have a polished high quality codebase, but still have a dying startup because you've built something that nobody wants. Conversely, having a desirable product makes up for a vast multitude of sins.
However, technical debt is expensive. Having a clean well-factored codebase makes changes cheaper, which means your company will have lower overhead and be more responsive to market demands.
As far as "forcing you to build loosely coupled code", good TDD should involve a thin layer of integration tests (Selenium/Capybara/Whatever), which drive out unit tests for the individual components. If you let the tests drive your code design, and follow the "Red -> Green -> Refactor" workflow, it tends to shepherd you into writing small easily testable functions and objects that are loosely coupled.
You can also use TDD to salvage crappy code, and derive good design even after the damage has been done. For a beautiful demonstration of this process at work, I strongly recommend Katrina Owen's video on "Therapeutic Refactoring". http://www.youtube.com/watch?v=J4dlF0kcThQ
Of course, there's no substitute for having good technical instincts. I couldn't agree with you more on that point. TDD isn't a silver bullet. It's just a damn useful tool, and more startups should be using it.
Good TDD forces you into building loosely-coupled code that's easy to refactor and change. When new business requirements come in, the effort for implementing them isn't increased because of your previous code getting in the way. There's an overhead to writing the tests, but it's a fixed continuous cost. As a result, you're always in a position where you can ship a new feature in a predictable (and reasonably fast) fashion.
Not doing TDD often leads to tightly-coupled brittle software, which can be very fast to implement but also difficult to change down the road. It certainly doesn't have to, but in reality that's what happens 90% of the time.
There's a few successful startups that immediately spring to mind that use TDD (Taskrabbit and Modcloth spring immediately to mind). However, the real question you should be asking is, "Which startups died because they got buried under the weight of their own codebase?" That's a long and very depressing list. In many of those situations, some TDD might have helped.
In short: TDD won't make your startup healthy, but it helps ward off some of the more common fatal diseases.
I can't speak to the particulars in Daisey's story (since I don't know which ones were made up), but the overall picture he painted sounded familiar. It's unquestionable that there are horrible working conditions in Chinese factories.
That's the tragedy here. There's millions of awful wonderful horrible stories you can tell about Chinese factories, and Mike Daisey is obscuring them by making up his own.
Chinese factory conditions are often horrible, and there's often a blatant disregard for human life and dignity. Mr. Daisey did a pretty good job of conveying these ideas in a way that well-heeled westerners could understand at a gut level.
However, his pursuit of storytelling over journalism is going to destroy all that. People are going to (rightfully) pitch the fact out along with the fiction, because there's no way to distinguish the two.
It just makes me sad.
There's a lot of folks (myself included) that would have been happy to jump in and assist, but couldn't due to the closed-source nature of the platform.
The real prize, however, is Enyo. It's a great Javascript framework, and works in virtually any webkit-based browser. The biggest problem was the licensing terms: You could only use it on WebOS phones. Now that barrier's being removed.
I'm really looking forward to this. Can't wait to dive into the code. :)
A lot of people bring up the possibility of fraud with these crowdfunding sites (IndieGoGo, Kickstarter, Rockethub, etc.). While fraud is definitely a concern with crowdfunding, it turns out to be a much smaller problem than you would think.
First of all, the very nature of crowdfunding seems to act as a natural brake on fraudulent behavior. While it's easy to fool one person, most campaigns have dozens or hundreds of contributors. It's trivially easy for any of those contributors to sound the alarm (to the crowdfunding platform and other contributors) if there's anything fishy.
To reinforce this point, it's also been shown that "outside contributions" (contributions from people not personally connected to the campaign or campaign owner) generally don't happen until a campaign's received around 30% of their target amount. Social proof is really important, and it's hard to get if you're a scammer.
Secondly, we (IndieGoGo) take fraud very seriously and invest a lot of resources into preventing it. We've got several layers of automated fraud detection, as well as a couple sets of human eyes on every campaign. While we can't guarantee fraud won't happen, we make every effort to make it vanishingly small.
In a nutshell, we're working pretty damn hard to make crowdfunding a safe and trustworthy marketplace. So far, the results seem pretty positive.
As for the specifics of this legislation: No comment, other than "We're looking at it."
H1B okay, No telecommute (sorry)
IndieGoGo is a rapidly growing funding platform, based in beautiful San Francisco. Our site is used by people all over the world to raise money for creative projects, businesses and causes. Millions of dollars have been contributed to over 25 thousand funding campaigns in over 200 countries.
Our customers are passionate about their funding campaigns, and so are we.
We're venture backed, and are looking for folks to fill the following roles:
* UX Designer
* Senior Rails Developer
* Junior Rails Developer
* Visual Designer/Developer
* Product Manager
This is a chance to have a lot of immediate impact on the world, while working with a cool team in a casual atmosphere.
More info: http://www.indiegogo.com/careers
Or, you can contact me directly: david@indiegogo.com
Now that Android has exploded in that market, I expect most of those developers to migrate away from Symbian to Android if they haven't already.
One thing to remember is that we're talking about the entire population of software developers. Certain demographics (like HN readers) will show up more heavily on certain platforms (like iOS). However, the general trends will always mirror marketshare.
Android has been beating the bejeezus out of iOS on unit sales for a while now, both in the U.S. and globally. Even more importantly, Android's growing at a faster rate.
Developers will gravitate towards the platform with the most users. Period. This has happened time and time again over the past 30 years. IBM, Microsoft, Oracle, Adobe, Google...
There's a lot of nuance underneath the headline numbers, and certain communities (like HN) will be friendlier to iOS. However, in general I would expect Android to capture the bulk of developer attention going forward.
That'll probably go up with Fukushima out of commission.
Also, the landline data networks seemed to be up and stable, so Skype worked great. Something to remember next time you're in an emergency and need to get a call out.
Initial notifications are minimally intrusive (similar to Growl on OS X). From there, they can be trivially dismissed or minimized and left for later. This makes triaging incredibly easy and lightweight.
On my Pre, I'll often set alarms on my to-dos and then use them as kind of an on-demand dashboard of my daily tasks. As something gets finished, the notification gets dismissed with a flick of the thumb.
On WebOS, notifications actively make me happy. In comparison, Android is kind of clunky and the iPhone is horribly broken.
Email me, and I'd be happy to discuss your situation and provide pointers where I can. (address is in profile)
According to Google's most recent numbers, Android is shipping 300,000 devices per day. While Apple has a lot of mindshare, the reality is that they're in a solid #2 position in the US, and #3 worldwide.
After that, he started building a system for extending emacs with JS, named "ejacs". It never got fully baked, but the effort produced the very nice js2-mode. Details here: http://steve-yegge.blogspot.com/2008/11/ejacs-javascript-int...
So, I think NBL was just "Javascript". Awesome call. Despite the problems with the standards process, JS has exploded in popularity over the past three years.
Really, there's no excuse for needing iTunes. If Palm can get this right with their miniscule resources, Apple certainly has the capacity to do cloud-based backups. They just haven't made it a priority.
Anything that requires balanced matching is NOT parseable with standard Regular Expressions, and by not parseable I mean that you will literally have an infinite amount of bugs. Shoot me an email and I can show you the math.
Even with Perl's whiz-bang recursive not-really-regexes-regexes, it's strongly not recommended to tackle balanced matching problems like HTML or XML. It might be theoretically possible (I haven't actually checked), but your brain will leak from your ears and you probably won't get it right, no matter how smart you are.
At the Droid X launch, Google claimed 160,000 activations a day, which translates to a run rate of almost 60 million devices a year. More importantly, the Android growth rate looks like an exponential curve up at this point. Google's announcements show a 60% growth in Android over the past 3 months.
In the long run, Apple simply can't match those numbers. Their install base will give them the lead for another year, and their total unit sales will continue to grow, but the marketshare future looks like it belongs to Android.
One factor that you're leaving out is the moral horror of painfully slaughtering these giant and beautiful creatures. Often the colossi are completely benign, and you have to figure out a way to injure them to get their attention or bring them down to your level. My wife watched me play the first level, and left the room horrified.
Thus, the emotional reaction of the player is a key component of the art. I began the game tackling the first colossus with feelings of guilt and shame for being such a butcher, but that was tempered by the knowledge that the kill was a necessary act. You have a love to save, after all.
However, as you progress through the game your revulsion subsides. You become numb to the screams of pain, the frenzied attempts to shrug you off. It becomes simple sport, instead of a vile but necessary act. The kills devolve to "just a game". Your character physically reflects this, as you become gradually darker and deformed, but at such a slow pace that you don't notice until the corruption is quite far along.
And then, at the end, after you thrill to the final hard-won kill, the morality comes rushing back. What you've done was wrong. Evil. Even though you set out with the best of intentions, your soul is now irredeemable. The guilt is intense. Then, finally, redemption of a sort.
SotC is emotionally richer than most films, and the responses that it evokes would not be possible in any other medium. SotC is art of the highest caliber.