megaduck · HackerTrans

megaduck

no profile record

Submissions

HP to open-source WebOS

precentral.net

20 pointsby megaduck15 yıl önce3 comments

Ask HN: Consulting while bootstrapping?

8 pointsby megaduck16 yıl önce8 comments

An Open Letter from Mark Zuckerberg (2006)

blog.facebook.com

3 pointsby megaduck16 yıl önce1 comments

comments

5 yıl öncediscuss

What exactly are you trying to say?

7 yıl öncediscuss

<BEGIN PSA> Please, please, please, do not use hover controls. They are useless for touch users as well as screen readers, and the discoverability is poor.

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>

8 yıl öncediscuss

I run the Pivotal office in Singapore. Breakfast is wonderful, but it's hardly mandatory.

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.

9 yıl öncediscuss

I've worked with Eno (the OP) on the product that he's talking about (Cloud Foundry). It's worth noting that the first versions of Cloud Foundry were written in Ruby/Sinatra for the reasons that you're talking about.

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.

9 yıl öncediscuss

Predictability. We pair program, so we need everybody to be there at the same time.

People sometimes work less, due to doctor appointments, child care, home repairs, and such. However, they never work more.

9 yıl öncediscuss

I'm not convinced it's optimal! However, it's a "known good" number that's easy to convince people to follow along with. Running experiments is hard and expensive, so we just haven't tackled that yet.

My personal suspicion is that optimal is probably in the 35-45 range, but I'd love to have more data.

9 yıl öncediscuss

We use Pivotal Tracker, and it's pretty easy to see how many bugs are popping up and how often.

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.

9 yıl öncediscuss

I enforce a militant "40 hours only" policy for my employees, and it's incredible for productivity. When you work longer hours defect rates increase, code quality drops, and things are on fire all the time. You also lose really good people due to burnout.

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.

9 yıl öncediscuss

You're clearly the target market for these new MBPs, and that's great. Glad you have a machine that fits your needs.

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.

13 yıl öncediscuss

Clarification: Your code != your startup.

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.

13 yıl öncediscuss

I work at one of those "contracting shops" (Pivotal Labs), and I think you're misunderstanding the reason we push TDD so damn hard: It's not about speed. It's about predictability.

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.

14 yıl öncediscuss

I know because I've seen it. My wife and I used to live in China, and we did traveling in both the high and the low places.

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.

14 yıl öncediscuss

What's really tragic here is that the truth in Mr. Daisey's story will get dragged down by the weight of his lies.

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.

15 yıl öncediscuss

This is fantastic news. WebOS has always been full of great ideas, but held back by shaky underpinnings. It's like the inverse of most open-source projects. Great UI, not-so-hot implementation.

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. :)

15 yıl öncediscuss

Full disclosure up front: I work for IndieGoGo. I can't speak for other crowdfunding platforms, but I assume that they're similar on this topic.

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."

15 yıl öncediscuss

IndieGoGo, San Francisco CA

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

For the devs, exposure to functional programming languages is a plus.

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: [email protected]

15 yıl öncediscuss

Who says they haven't been? They certainly were in markets where Symbian was dominant. When I was in China (2008-2009), the developer support for Symbian was dramatically better than BlackBerry or iOS.

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.

15 yıl öncediscuss

I am amazed that we've got 56 comments on this thread, and nobody's brought up market share.

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.

15 yıl öncediscuss

I'm a Tepco (Tokyo) customer. Looking at my most recent electric bill we're paying about 22 yen a kWh, or around 27 cents.

That'll probably go up with Fukushima out of commission.

15 yıl öncediscuss

Smartphones were better than regular phones during this emergency. My android phone was useless for voice and SMS, but still had a data connection. So, my wife and I were able to send gmail back and forth to stay in touch.

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.