First 100 miles on my E-Bike - <AUTHOR> https://yilunzh.com/2017/12/30/first-100-miles-on-my-e-bike-what-i-learned/ <comment><USER2> I have put about 3,000km on my E-bike in the last 1.5 years. It's limited to 25km/h, because then I don't need a license, it's fast enough for city traffic (mostly in bike lanes anyways) and I get to tow a trailer for my kid.

Biggest advantage: Hills don't exist for me. We live in a city with quite a few hills and day care is about 70-100m below our appartment. Doing this trip twice a day with its 15% slope would take way longer and exhaust me, before the day even started. The way downhill to day care is now something like 10 minutes and back up 11 minutes.

Biggest disadvantage: If you drive on mostly flat terrain, there's no real benefit – it might even slow you down. I get my regular bike to 25km/h easily. An E-Bike accelerates until it hits 25km/h and then it's just a damn heavy bike (17-20kg) that is slower than a regular bike (if you're a somewhat fit person).

Anyways, I love the E-Bike for the simple fact that I go almost anywhere by bike, can take my kid with me and don't have to think about any hills at all.

<comment><USER3> I've read about motorized doping in bike races, with motors hidden inside the gearing, I wonder whether anyone's thought about this sort of thing for consumer bikes, and what sort of benefit you could get for, say, 1kg or half a kg of extra weight. E-bikes at the moment seem to have reconciled themselves to being twice the weight of ordinary bikes.

<comment><USER4> Something like this: [https://www.vivax-assist.com/en/product/vivax- assist/vivax-a...](https://www.vivax-assist.com/en/product/vivax-assist/vivax- assist_4-0.php)

I think the problem is range, you won't be able to hide much battery, the one on my bike weighs 6LBs and is quite bulky.

In reality it doesn't really matter because the motor will more than offset the extra drag and weight of a heavy bike.

<comment><USER5> Can you pedal and use the motor at the same time in a regular ebike? I think what the parent posters want to be able to turn off the motor completely.

<comment><USER6> You can; it's called "pedal assist", and usually, the motor controllers can be set to do it at different levels of pedaling intensity. It's usually implemented by spacing magnets around the crankset and then calculating how fast they're passing by a sensor.

</comment></comment></comment></comment></comment><comment><USER7> >>> If the ride is so great and economics so favorable, why haven't I seen more adoption here in US and Canada?

The author's answers to this question focus solely on the bike technology itself. This is a common thread in a lot of discussions about cycling: If we only built the right bike, more people would ride. This is usually followed by a CAD rendering of the perfect bike, that looks like nobody would want to ride it.

I don't think it's the bike. I think that there are a lot of cyclists who are simply not candidates for e-bikes because riding under their own power is part of the attraction. I'm one of those people. A friend of mine who loves his e-bike finally gave up trying to understand why I don't want one.

So you have to reach the same people who were deterred from cycling in the past for reasons good and bad. The motor addresses the issue of effort, but not safety, weather, or a variety of other factors, including the fact that driving a car is fun for a lot of people. The e-bike could produce a marginal uptick in cycling, in the short term, but not a revolution.

<comment><USER8> > including the fact that driving a car is fun for a lot of people

Hmmm... Communting to work is fun for people? I want to live where they live.

Keep the car for weekend cruising, the bike probably makes the boring commutes more fun than a car would.

I built an bike 6 or 7 years ago but only took it once to work (a 20 mile commute). It was underpowered and under-batteried but it was an interesting starting point. I mean to try it again.

<comment><USER7> I think a lot has happened in the past few years, so that it's worth trying an improved motor and battery system.

Winter is a great time to get geared up for the next season, and there might be some seasonal discounts to take advantage of right now!

</comment></comment></comment><comment><USER9> Here in India I see a few people cycling to work. A "few" (we have a LOT of people).

I can't see adoption increase. I myself won't ride a cycle, because

1\. There's way too much pollution on the roads. I'll die breathing that air

2\. If I don't die breathing that air, some car or bus driver who doesn't give a shit about other people's lives and is on their phone while driving will hit me and perhaps kill me (or worse, leave me disabled for life)

I want to cycle to work everyday. I want the exercise. I want to live, and to be healthy, and to protect the environment.

But the flip side is, I might die.

<comment><USER10> Is 1 really all that different from driving in a car with the AC on? If I understand correctly, car filters typically only filter very large particles that would damage the engine.

<comment><USER11> Engine air and cabin air are two separate intake paths.

The cabin air in modern cars is _highly_ filtered.

" Most dust filters will stop 100 percent of all particles that are 3 microns or larger in size, and 95 to 99 percent of particles 1 to 3 microns in size. The combination dust and odor filters have a layer of activated charcoal or baking soda to absorb odors and air pollutants. Some of these filters may even be lightly scented to enhance the driving experience."

[https://www.knowyourparts.com/technical- resources/filtration...](https://www.knowyourparts.com/technical- resources/filtration/cabin-air-filter-replacement/)

So yes. Being in a car with AC on is much better.

<comment><USER10> Makes sense, thanks!

</comment></comment></comment></comment><comment><USER12> I'm surprised the author spent so much money building on top of a base bike of such low quality. That department store bike is what bike snobs would call a "bicycle-shaped object". You certainly shouldn't not be cheaping out on the actual bicycle for an e-bike, as you're putting the bike (and particularly the brakes) through forces they were not properly designed for. The author even admits such:

> The brakes are often too soft to handle continuous elevated speed. What ends > up happening is that I spend more money overtime to upgrade the bike to my > desired state. So far I spent about $1500, including parts and tools, this > is accounting for a fairly cheap used bike on craigslist ($200). Had I > bought a new bike, I would have had to spend probably close to $1900. To > make it exactly the way I want it, I estimate that I have to spend an > additional $800 to get install IGH, bigger brakes, and more efficient tires > with less rolling resistance.

Frankly, the author's setup just sounds dangerous. The several-$K all-in-one bicycles that they refused to get on grounds of cost are expensive because they are actually built to handle the rigors of e-bike usage, and have incredibly useful features like hydraulic disc brakes. The brakes on that department store bike are "disc" brakes, but they're certainly not hydraulic, or even good, at that price point.

<comment><AUTHOR> Yup, the brakes is definitely the limiting factor currently, but other parts of the bike have held up surprisingly well. I didn't really know anything about bikes before starting this, so it was a cheap way to learn. I figured I can always upgrade the parts over time if needed. I had set a max budget of $1500 for the initial purchase and had to make tradeoff somewhere.

<comment><USER13> I've been getting interested in e-bikes recently. Work is 15km away, but I do weight near 0.1 [t] :)

Hows the battery holding if you carry extra weight? How much does the total setup, you included, weights?

<comment><AUTHOR> My bike is around 50 lbs. I weight about 150 lbs. I often carry a bag about 20 lbs. So all in, it's about 200 lbs or ~90KG. I think my battery pack can go about 50 miles per charge, but I never went that far on a single charge. I usually charge after 30 miles to ease strain on battery, but that should still be plenty for you to get to work and back.

</comment></comment></comment></comment><comment><USER14> "Most of the commercial E-Bike uses 250W or 350W motors, because that's what the European specs are. While that amount of power is able to achieve 20MPH range, it does take its time to get there. In the US, with the open roads, that's simply not enough power to keep up with traffic. Quite frankly, they still feel like a plain bicycle and it's a bit boring to ride. Higher adoption require more power."

As I understand it, the EU standard says there's supposed to be no power assist past 25km, which is about 16mh. That is, for e-bikes which don't require a license.

I agree. If you want a more powerful e-bike, you should have a license.

<comment><AUTHOR> Yeah, in the US, my understanding is that the regulation is much looser relative to the rest of the world. You can have a maximum of 750W with a top speed of 28 MPH without pedal assist, which in my view is plenty fast for a bike. The problem is that because US is such a small market for EBike that most are imported with European specs. In the US with straight and open roads, they just aren't fast enough

<comment><USER15> No. In the US the top speed is 20mph [1].

The author's bike is not street legal. It's classified as a motorcycle under US and Arizona law.

[1] [https://en.wikipedia.org/wiki/Electric_bicycle_laws#United_S...](https://en.wikipedia.org/wiki/Electric_bicycle_laws#United_States)

</comment></comment></comment><comment><USER16> The laws around e-bikes in the US can be a deterrent. E.g.: [The Murky Legality of E-Bikes]([https://www.citylab.com/equity/2016/02/the-murky- legality-of...](https://www.citylab.com/equity/2016/02/the-murky-legality-of- e-bikes/426969/))

The second paragraph gives you the flavor of it:

> Under federal law, an electric bike with a maximum assisted speed under 20 > miles per hour can be sold as a bicycle, not a motor vehicle. Under New York > state law, riders would need to register these as they would a motorcycle, > moped, or car. But there's no clear way to register them. Because of this > regulatory patchwork, e-bikes are legal to sell as bikes anywhere in the > U.S. but effectively illegal to ride in New York, since they can't be > registered as motor vehicles.

<comment><USER17> I actually worry about the "something must be done" crowd cajoling lawmakers into lazily shoehorning electric bikes into the "motorcycle" category and erasing much of their advantages to own as a bicycle.

This happened with boats here as my little plastic kayak with a tiny electric assist has to be registered and taxed as if it was a full sized bass fishing boat with a v8.

<comment><USER18> I would worry about the kit aspect of the bikes.

You're lucky to merely have to pay some money for your "power kayak".

In my state, to actively discourage the construction of home built boats, if I want to build a 15 foot sailboat, I need to work with the coast guard and state DMV (spoiler, they don't actually work together, the finger pointing is hilarious) to get a hull number assigned, then fight the DOT to get it titled (boats are titled where I live, and its agonizing although it only costs $5) and its quite a fight involving official inspection because most "homemade" boats are people trying to register are Crestliners with the serial numbers filed off, then I can fight the DNR to register myself obtaining a DNR customer number, and then fight the DNR to register the boat, essentially linking my CG hull ID number to my DNR customer ID number for a mere $17/yr, ironically the total cost of all of this for the first year would only be roughly $30 but it takes like 100+ hours of phone calling and meeting people and filling out forms. I pay $35 for a quart of good topside marine paint so the point is not the expense but the bureaucracy agony. All that for basically an inland lake dingy with a sail on it.

<comment><USER19> That sounds like insanity. My country by comparison is too far at the other end of the scale. Anyone can buy (or make) a boat, with a 200 horse motor, grab a six pack and a tank full of fuel and hit the water and go anywhere, into any harbour, with no training whatsoever.

</comment></comment></comment></comment><comment><USER20> I also completed my first 100 miles on an ebike this past week, on a bike I bought two weeks ago. I splurged and bought a top of the line pre-built[0]. Call it a mid life crisis.

It is a class three bike. The electric motor will only activate under 28mph. There is no throttle, the motor multiplies your pedal force by 55-200% depending on the setting (eco-turbo).

I can beat the bus on a few bus routes. I use to take the bus if the route had too many hills but now I maintain 17mph without getting winded on steep hills. An electric shortens and flattens any bike trip, I'm never sloughing up a hill, and I'm never asking myself if it's worth riding the bike. Even if bus or uber is faster it wont be twice as fast. Biking is still fun and still a workout, I'm a out of breath with sore legs after a ride.

I'm sometimes self-conscious about 'cheating'. I'm not sure how fast I should be going on a mixed use bike path. I'm afraid this bike will get stolen one day, even with a ulock and cable. If not stolen, vandalized.

I think that electric bikes could be the future of city transit if the price comes down. Secondary problems include theft and weather.

[0] [https://www.trekbikes.com/us/en_US/bikes/hybrid- bikes/electr...](https://www.trekbikes.com/us/en_US/bikes/hybrid- bikes/electric-hybrid-bikes/crossrip/crossrip/p/1373000-2018/)

<comment><USER21> I also bought a top of the line pre-built ([https://www.stromerbike.com/en_US/e-bikes/st2.html](https://www.stromerbike.com/en_US/e-bikes/st2.html)) almost 2 years and 7500 miles later, I have zero regrets. My goal is to break even for car cost for the price ($0.55 cents per mile). It hasn't happened yet, but I would already call it worth it due to the peace of mind of not having to sit in traffic every day.

</comment></comment><comment><USER22> > My third favorite thing is that I can get to work in basically the same > amount of time as driving. On my E-Bike, it takes 22 minutes to get to work > (7.5 miles). It takes me 15 minutes to drive there.

I live about 6 miles from where I work in Los Angeles. I ride my bike (not an E-bike) in three or four times a week. It takes me 25 minutes on average. By contrast, it takes me at least 35 minutes to drive, not including time to park and walk to the office.

I ride on neighborhood roads most of the way for safety, I have to do some personal cleanup when I get there and Los Angeles is particularly bad where traffic is concerned. With all that in mind, it's still worth considering for others in a similar situation.

</comment><comment><USER23> Daily, year-round bike commuter in Seattle - I think electronic bikes are awesome for the hills in Seattle for folks new to biking. I'm concerned with the possibility of this increasing accidents, however.

My commute is mostly on roads with cars. I don't ride as fast as I can. Driving defensively, you want to be able to break and avoid a collision.

I witnessed a really bad accident, where a car t-boned a cyclist. This has cured me of riding as fast as I can into work.

I see a lot of normal bikers as well as e-bikers going faster than is safe and I think e-bikes contribute to riders putting themselves into jeopardy.

<comment><USER24> Also year-round commuter in Norway w/ an e-bike. I agree that the increased speed increases the probability of an accident. I've personally had several close calls vs cars in roundabouts and on bike lanes (!).

I also have a motorcycle license and I've been riding motorcycles for about 5 years in traffic. A lot of the risks are very similar to the ones you experience on an e-bike in my opinion.

Edit: The best tip I can give to two-wheel riders is to increase visibility as much as possible, and be observant of cars. Lights and bright colored clothing helps a lot.

</comment></comment><comment><USER25> I bought a Pedego electric bike this summer to replace a car.

I work from home, and there are many stores, restaurants, my Dr, etc. within a 30min e-bike ride, so we tried this experiment.

It's working out rather well in Myrtle Beach, SC.

My bike did cost me over $3k, however I too went through the process of evaluating what it would cost to build my own. aconsidering my weight (300lbs) The Pedego Stretch was one of the few bikes designed to handle that weight, and has the largest battery in the Pedego lineup. I've been happy with my purchase (including 0% APR financing for 1 year - making it a cheaper monthly payment than the lease I traded in - and that cost goes to $0 this coming summer).

It definitely opened up possibilities beyond a standard bike, and removed the feeling of being 'trapped' while working from home with no car while my wife has it at work.

</comment><comment><USER26> For the author, I'm really curious about the section "Economics of owning an E-Bike relative to car". Would you mind sharing your rough math on how you came to those numbers? The IRS rate for expensing milage is $0.54/mile which (in theory) is supposed to cover standard maintenance and fuel.

However mostly it just seems really high for the bike to be $0.14/mile. My back of the envelope calculation for electricity cost is: ~$0.10 per KWHR. The battery pack is sub 1 KW so even with charging inefficiency should cost no more than $0.10 to charge. Divided by roughly 50 mile range means an electricity cost of $0.002 per mile. I could be way off, hence why I'm curious.

<comment><USER27> I think he gets to that $0.14/mile by including the cost of the complete bike (assuming 500 charge cycles of the battery, which at 30 miles/charge should last him about 4 years with a 15 mile commute).

Over those 4 years, he'll ride 15 miles/day * 253 working days/year, or 4000 miles/year, or 16000 miles.

So.... $1400 / 16000 = $.09/mile

He also included maintenance, so if he spends $200/year in maintenance (not unreasonable if he takes it to a bike shop for maintenance), that gets him up to $0.14/mile.

</comment></comment><comment><USER28> Author seems to think an internal drivetrain for a bike would be more reliable. Maybe somebody more mechanical can chime in, but my understanding was that the opposite was true: only reason cars have to use an internal drivetrain is for cooling and external ones are generally more reliable?

<comment><USER29> Internal gearhubs are drastically more reliable than derailleur gears and require almost no maintenance. They use an epicyclic gear train in a sealed oil bath, so most of the mechanical parts are protected from moisture and foreign objects. The use of a gearhub also facilitates the use of an enclosed chaincase, or a belt or shaft drive.

The Sturmey Archer 3-speed gearhub has existed largely unchanged since 1938 and is faultlessly reliable, even when horribly neglected. As long as they're rebuilt every 10,000 miles or so, they'll last a lifetime. They're the standard gearing option on Dutch utility bikes and were once the most popular of all bicycle gearing systems. The only real downside of the Sturmey Archer gearhub is that it offers a narrower range of ratios than a derailleur system, although it's more than adequate for utility cycling in moderately hilly areas.

Newer gearhubs offer eight, eleven or fourteen ratios, matching the gear range of a mountain bike derailleur system. They're less popular than derailleur gears because of the higher cost and marginally higher weight, but I think that they're a vastly superior choice for utility cycling. One great advantage for casual cyclists is that gearhubs change smoothly and instantly, even under heavy pedal load or at a complete stop. Changing gears on a derailleur system requires a degree of finesse to avoid jerky changes and dropped chains.

Rohloff manufacture the most sophisticated of all gearhubs, which have been successfully used on several round-the-world tours.

<comment><USER28> Can you buy bikes that come with internal gearhubs on the consumer market, or is this always an aftermarket thing nowadays?

<comment><USER29> Yes, although they can be somewhat hard to find in some markets. Any Dutch or German bike shop will have a wide selection of bikes with gearhubs, but in the US you might need to speak to a dealer that specialises in urban utility bikes. Some department store cruiser and hybrid bikes have Sturmey Archer 3-speed gearhubs, although the rest of the bike may be mediocre.

Dahon and Tern are both manufacturers of folding bicycles and both offer a good range of bikes with gearhubs. Folding bikes can be a very practical choice even if you don't use the folding feature very often - they're compact, agile and easy to ride.

</comment></comment></comment></comment><comment><USER30> This is a better article than I thought it would be; it's a bit scattered in that it discusses buying an ebike vs retrofitting one, and then also the user experience of being on an ebike: propensity to pedal rather than throttle, 1 gear being sufficient for flats, and 3 gears for hilly terrain, the comfort factor of biking faster when merged with traffic, and not being sweaty upon arrival when commuting.

I wish there were the political capital to put in more physically separated bike infra in American cities. Sharing infrastructure flat out does not work here, we are not mature or disciplined or standardized enough in our driving competency. A huge part of this is generational, my mom is all "This traffic sucks! Rip out the trees, rip out the sidewalks, put in more road lanes!" even though she bikes once a week to go play bridge with friends, and my dad won't even get on a bike. Millennials probably would like to rip out roads and put in more public transit and bike infra, and get rid of cars. I for sure would like to get rid of death by cycling, and single occupancy vehcicles. But there really isn't the political capital right now to do anything but piecemeal approaches.

</comment><comment><USER31> I don't grok e-bikes. I like them and I'd like to get one but I just don't know how I will manage the charging. I am livinig in a big city and have no garage and no wall socket in front of my street door. And 100% of all destinations I ride to don't have wall sockets for charging neither.

So, I would need to carry every time the heavy battery upstairs (3 floors)? I am anyway always full-loaded with bags or whatever and don't want to carry every-time this stupid battery as well.

Then, the really beautiful e-bikes have an integrated battery in the frame, a bit like the iPhones. How should this now work?? I carry the 17-20kg bike upstairs every time?

Ok, only if you have a house with a garage in some suburb you can ride those bikes but then you are usually so far way from the city center that you need a car again.

As a final note: These bikes are so much heavier (17kg and up) and I am wondering if it's that much more effort to ride a light 10kg bike without any electrical motor.

So, I am really curious about the real use case of e-bikes.

Edit: Why the downvote?

<comment><USER32> > Edit: Why the downvote?

Maybe it's because you've said you don't understand e-bikes for the ridiculous reason that they don't fit your very specific living situation like what kind of housing you have, which floor you live on and how many bags you're prepared to carry.

Other people have different living situations, and e-bikes suit them. It's not a mystery.

<comment><USER31> Then again what is the living situation ('use case') where an e-bike works? I also made the example with a house and garage. I don't see any killer use case but are happy to learn relevant use cases.

<comment><USER32> I mean just to look at one part of the world, but which many of us will understand, look at somewhere like San Mateo, the sub-urban area halfway between San Francisco and San Jose in Silicon Valley. Imagine living in a house with a garage somewhere like Foster City.

[https://firstname.lastname@example.com,-122.2920167,13z?h...](https://email@example.com,-122.2920167,13z?hl=en)

A family could get all around this area very nicely on an electric bike. Maybe you bike to an office in Redwood Shores, your wife teaches the College of San Mateo campus up the hill and she can get there on an electric bike there as well. She basically recharges it on the way back on the down hill. Your daughter goes to Hillsdale High School where she can electric bike to and works a part time job at the Whole Foods Market there which can bike to as well.

Your suburb example was flawed because not everyone is trying to get into a big city centre.

<comment><USER31> (1) Having a town house with some wall socket at the entry or a garage and (2) not trying to get into a big city centre might be a use case, yes. Thanks for elaborating your example but I don't think that this use case is strong or ubiquitous enough (maybe in SF) to lead e-bikes to mass adoption. I still think the concept of an e-bike, in particular the charging, is super flawed. If the battery is removable you can charge this thing but you have to carry a fat battery pack back and forth and your bike looks super clumsy (and yes, all bikes with removable batteries look clumsy) or if it's integrated it looks nice but it's hard to charge that thing.

I mean, I see that all bike manufacturer start to produce e-bikes and they form a large part of their revenues because they are much more expensive than normal bikes but if I'd make a mini poll here, how many of you guys have an e-bike, how many a normal bike? I bet the rate is 1:10 (e-bike:bike) or even lower.

<comment><USER33> If the battery is removable, it will be stolen.

<comment><USER27> As will everything else on the bike that's not bolted on (and sometimes even that is stolen). So take it with you when you park in an unsecured area.

</comment></comment></comment></comment></comment></comment></comment><comment><USER34> I swear the best commuter ebike is the Revelo Flex ([https://www.revelo.ca/pages/flex-electric-folding- bike](https://www.revelo.ca/pages/flex-electric-folding-bike)). It's like someone shrank a penny farthing and put a motor in the back wheel: the front wheel is 20" and has pedals attached to it (so you can help the motor when uphill), the back is 16" and has the motor inside (torque!). You can order it with bike ABS as well ([https://www.bikerumor.com/2012/11/27/hands-on-sabs- antilock-...](https://www.bikerumor.com/2012/11/27/hands-on-sabs-antilock- bicycle-brake-pads/)). Since it's folding and rolling folded you can easily carry it on public transit. It's only 15kg which is just about the lightest possible (those batteries are heavy). There's no chain to maintain, no grease, nothing. Just hop on, zip along and _stop_ when the situation warrants -- the stopping distance of the SABS pads is nothing short of incredible (I have been rearended by another cyclist once when I fully engaged them to avoid a collision with a car -- normally when riding in a bike lane I don't grip them like my life depends on them because I know how they behave).

<comment><USER35> With such a small front wheel and your feet on the front wheel, how do you climb a curb? That just looks like designed for a OTB. That funny one foot down maneuver kickbike-riders do to jump might work but doesn't look easy.

<comment><USER34> Vancouver, BC is a very accessible city so the curbs have ramps at crossroads. And we have a really nice bike lane network. I never had this problem.

</comment></comment></comment><comment> amiga-workbench I built mine last year to get to and from work, 1000W motor and a 10AH battery, cost me just under a grand and its paid for itself many times over.

I don't need that power all the time, but there is a rather steep hill on my way home which would be a challenge to get up on a less powerful motor.

</comment><comment><USER36> Question to e-bike owners - did you have to handle any sort of negativity from non e-bike riders? Stuff like "oh you are lazy", "this is unhealthy" etc?

<comment><USER7> Every group has its snobs. There are also people who think that car drivers are lazy and unhealthy.

I'm a conventional cyclist, but some of my friends have e-bikes.

For the most part, people get along. While cyclists don't know what to expect as e-bikes get more popular, we also recognize that e-bikes provide access to cycling for a larger population. The hope is that the overall popularity of cycling will be better for everybody. There's a general observation that car drivers behave better towards cyclists as cycling gets more popular in any given locale.

At least in my locale, e-bikes are arriving on the scene gradually enough, that people can have a wait-and-see attitude about how they will mix with conventional bikes as they get more popular. For now I have a laissez-faire attitude unless or until problems emerge.

</comment></comment><comment><USER8> > Having now gone through the experience, I would definitely recommend the > build route. You just get much more value for your money.

And then there's the "IKEA effect". ;)

</comment><comment><USER37> I had my own ebike startup 2 years ago (Lectro). What killed it was the fact that large lithium battery packs were classified with hazmat status. This classification might have been spurred by the exploding hoverboards. Product shipping and liability became too high for profits. I would assume big box retailers have similar concerns. If the BMS in the battery had an issue, It was very difficult for the customer to ship back.

</comment><comment><USER38> I left a comment on the author's page (awaiting moderation), but I'll copy it here: if you're going to try this at home familiarize yourself with local laws. I'm all for getting more people on bikes, but some of the suggestions he makes are illegal in my state. Be aware of power limitations, braking requirements, and how the resulting vehicle would be classified (and should be labeled).

</comment><comment><USER39> Logging all your e-bike miles on strava is kind of lame. Even in your screen shots you can see you're taking KOM segments that others enjoy competing for from people, and I doubt those are other e-bike users. The whole point of the site is to act as a athletics tracker, and using a motor driven cycle here undermines that.

</comment><comment><USER40> I still think the opportunity cost of not having a car is greater than whatever you pay to make it instantly available, should you want to take that trip during poor weather, or sufficient distance to make the ebike non applicable.

Unless you are content with the daily patterns that are constraint by the range of your e-bike.

<comment><USER41> A parking space where I live (London) would cost 1100/month. I find it very hard to imagine getting that much value out of a car - what would I ever use it for? I mean sure it would make it easier to make a spontaneous trip hundreds of miles while carrying lots of luggage for some reason, but how often do I want to do that?

<comment><USER40> well when you live in a dense urban environment, you are already prioritizing certain things above having a car.

</comment></comment></comment><comment><USER42> I'd like to understand e-bike usage from a user perspective. Why does it appeal to a traditional biker to use an e-bike in the city (not talking cross country)? Why not "just bike" or the opposite as in scooter/e-scooter? How come there is such a big market in between?

<comment><USER43> I recently built an ebike like the OP to commute. Up to now I would bike commute sometimes and ride my non-ebike or take transit for most non-work trips, but for work commuting there was too much extra friction -- too far, too much to carry (I work in construction) -- to bike consistently. However I enjoy biking and it's a great way to commute in my car-congested city (if I solved the friction problem).

The extra watts of the ebike removes the friction.

</comment></comment><comment><USER44> > In order for E-Bike to really take off, I think there is a need to design it > from the ground up. Instead of building the motor and battery pack around > the frame, the right way to design an E-Bike is to build the frame around > the motor and the battery pack.

That's a motorbike. So is an e-bike really, but regulations allow it to be classified as something different so that you don't need a license.

EDIT: should clarify I enjoyed reading the article, and I think electric motorcycles and e-bikes have a bright future. I use a motorbike for my daily commute; non-riders should realise that they are far more vulnerable on two wheels. If you realise this and ride appropriately I think it is a reasonably ok thing to do. Having a bit of power actually makes things safer in an urban environment as it means cars aren't pushed into attempting dangerous overtaking maneuvers.

<comment><USER45> That's a good point..

But I don't care about that point, what I care about is efficiency in the design.

Just make the best damn, longest reaching, cheapest version that you can while sustaining your business with something people actually want.

</comment></comment><comment><USER46> Very similar to this guy's article from 2016: [http://dalybulge.blogspot.co.uk/?view=magazine](http://dalybulge.blogspot.co.uk/?view=magazine)

</comment><comment><USER47> I worry about the safety of 20-30MPH and trying to stay with car traffic. e-bikes make more sense to me as an assist for riding at normal bike-like speeds than as a way to ride at moped speeds.

<comment><AUTHOR> I should clarify that on the bike path, I generally do stay in the 15-20 MPH range, as there are many pedestrians traveling at low speed. On the road however, staying at typical bike like speed actually feel more dangerous to me. It kind of feels like driving on the highway at 45MPH when everyone is going 75MPH and a bit nerve wracking.

</comment></comment><comment><USER48> The author mentions that ebikes in China run around $500. Has anyone here tried importing one of those models?

<comment><USER49> I've imported my european bike for $800. It lasted quite a while, until I tried to fix a flat tire in the Lance Anderson bike shop in Austin, TX. They've got coffee, but have no idea about e-bikes. They broke it (short circuit), but thanksfully there was an e-bike repair in Austin. They could repair it to 95%. There' was still some leakage. I think there's one repair shop every 1000 miles. There's none in Houston. It was stolen after 2 years, which was expected.

My imported bike was far better than any $1000-2000 bikes in the states. They are all a scam.

</comment></comment><comment><USER50> That attached battery would get stolen in a pinch. Not practical unless you have closed/safe parking at every destination, i.e. won't work in Europe where we mostly park on the street.

I'm curious about the second picture: it looks like the motor is in the way of the pedal crank arm?

</comment><comment><USER51> For those looking for a totally integrated electric bike company in North America, checkout out [https://www.radpowerbikes.com/](https://www.radpowerbikes.com/) and they are less expensive than cobbling a retrofit together.

</comment><comment><USER52> This feels like one of those things Tesla could tackle in a heartbeat.

</comment><comment><USER45> Should have just bought a faraday bike

</comment><comment><USER53> No insurance and a powered vehicle?

</comment><comment><USER54> > If the ride is so great and economics so favorable, why haven't I seen more > adoption here in US and Canada?

1\. What's an E-Bike?

<comment><USER54> I can't believe the number of downvotes this has gotten. It's a very large contributing factor that was overlooked by the author. Get over yourselves.

<comment><USER55> You could have been less snarky about it.

</comment></comment></comment><comment><USER56> e-Bike prices are a scam. An e-bike can't possibly cost thousands of dollars, when components only add about $100-$120 to the total cost.

Until prices go down significantly, I am refusing to buy one.

<comment><USER55> Not sure why this is getting downvoted when TFA says that e-bikes here typically cost 6-10 times what they do in China.</comment></comment>


Time capsules unearthed amid Christchurch, NZ devastation - <AUTHOR> http://tvnz.co.nz/national-news/time-capsules-unearthed-amid-chch-devastation-4042763

<comment><USER2> I live in Christchurch. Sometime over the next few days I'd like to post a quick writeup detailing the significant role that the web and social media has played following the earthquake, if anyone is interested?

Also worth mentioning, a group of New Zealand developers have launched <http://www.appappeal.co.nz> to raise funds for the victims of the quake. Your support and tweets would be greatly appreciated.

</comment><comment><USER3> Can you change the title to correctly say "Christchurch" instead of "Chirst Church"?

<comment><AUTHOR> My bad, I'm sorry for that.

</comment></comment><comment><USER4> While this may certainly be interesting for a few people here, it is most certainly not "Hacker News", Ben.

<comment><USER5> "On-Topic: Anything that good hackers would find interesting. That includes more than hacking and startups. If you had to reduce it to a sentence, the answer might be: anything that gratifies one's intellectual curiosity."

<http://ycombinator.com/newsguidelines.html>

<comment><USER4> I know the guidelines well, and knew this was in there. I guess my threshold for things "good hackers would find interesting" is higher than this particular story. (I suspect - or rather hope - that that is the case for the majority of people who still visit HN, too). Also see:

[http://al3x.net/2011/02/22/solving-the-hacker-news- problem.h...](http://al3x.net/2011/02/22/solving-the-hacker-news-problem.html)</comment></comment></comment>


Ask HN: How do I start with test driven development? - <AUTHOR> I'm a student developer, @pravj on GitHub. I try to follow the best possible development practice when I'm working like documentation, respecting language's style guide etc.
But one thing I don't like with me is that I never write tests.
Why I never followed that aspect is because I always felt that the thing that I'm writing, sounds totally OK.
One another negative point is that I don't actually get it that How to do/start this and what type of tests I should write for any given project. Maybe this is because I have never done this before.
For example recently I wrote a identicons library, Penticons[1]. It generates GitHub contribution flavored identicons. You can read the development story here[2].
Now, the thing that stopped me from writing tests was, I thought that ultimately it's a image generation library, why this thing needs any tests.
I don't want to lost my 1 point in the Joel score. Whenever I see a build passing label on a GitHub repository, It makes me crazy.
I'm asking here because I just love HN, I know people will suggest some awesome things here.
1. https://github.com/penticons/penticons.go
2. http://pravj.github.io/blog/penticons-the-hash-game/ <comment><USER2> As far as writing tests... I'm sure you are testing your code manually yourself already, right? When you make a change, you do something(s) to make sure your change had the effect you wanted, and your software still worked. You just do it yourself, manually, and do different things every time of course.

Take those things, write automated tests to test them. Run the automated tests instead of testing manually, every time you can. Especially when making changes don't run the software yourself to see if your changes did what you wanted, write a test to do it and run that. The first time one of your tests catches a bug that you never would have expected, you'll be hooked.

"Test-Driven Development" actually refers to (almost) always writing the tests _before_ you write the code they test. Not everyone subscribes to this, at least universally. I wouldn't worry about that for now, I think if you just start writing automated tests every time you would have been manually testing, you'll be on the path and things will fall into place.

<comment><USER3> This is the point. You are most likely already testing your code (logging, printing, or the like).

I learned how to write tests and I was sold on the value of TDD only after I was in the middle of writing a non-trivial, multi-module client/server app. Right now, you think "I don't need to write tests for my penticons library, because I know it works." That's understandable. But as soon as you start incorporating it into other projects, or you extend it with other projects, having tests will make the process so much simpler.

Think about it this way: computing is essentially a way to repeatedly do things really quickly. I could take a pencil and a paper and write the numbers from 1-100 without too much trouble. But when that number is over 1000, or if instead of simply writing the number you perform some tedious formula, then you start to yearn for something like a `for` loop control structure.

The same with testing. Once you have a bunch of moving pieces, and every change you make you find yourself diving into the repl for 10 minutes doing the same thing over, and over, and over... you will actively WANT to know how to test.

So don't sweat it. Learn it if you want. Sooner or later, you're going to _need_ and _want_ to know how to write good tests, simply to save yourself the hassle.

</comment></comment><comment><USER4> I can't recommend the discussion between Kent Beck, David Hansson and Martin Fowler enough. They look at how and where it should be used and in particular discuss their approach to mocking which I feel is an often misunderstood tool.

Part 1 - [https://www.youtube.com/watch?v=z9quxZsLcfo](https://www.youtube.com/watch?v=z9quxZsLcfo)

Part 2 - [https://www.youtube.com/watch?v=JoTB2mcjU7w](https://www.youtube.com/watch?v=JoTB2mcjU7w)

Part 3 - [https://www.youtube.com/watch?v=YNw4baDz6WA](https://www.youtube.com/watch?v=YNw4baDz6WA)

Part 4/5 - [https://www.youtube.com/watch?v=gWD6REVeKW4](https://www.youtube.com/watch?v=gWD6REVeKW4)

<comment><USER5> This was a great discussion, but I think it is not appropriate for a beginner just getting into TDD. There were so many nuances in this series that I don't think it would be helpful as an introductory resource.

</comment></comment><comment><USER6> I can give you some pointers. 1) A good discussion about Unit Testing on Hacker News. Is most unit testing a waste or not? [https://news.ycombinator.com/item?id=7353767](https://news.ycombinator.com/item?id=7353767)

2) A story about unit testing at Airbnb: [http://nerds.airbnb.com/testing-at- airbnb/](http://nerds.airbnb.com/testing-at-airbnb/)

3) Practical tips for test driven development: [http://soundsoftware.ac.uk/unit-testing-why- bother/](http://soundsoftware.ac.uk/unit-testing-why-bother/)

<comment><AUTHOR> Reading the Airbnb story now, thanks for the links.

<comment><USER6> Sure, you're welcome. If you would like to grasp where you can go with test driven development and continuous integration, check out this article: 'How Etsy Deploys More Than 50 Times a Day": [http://www.infoq.com/news/2014/03/etsy-deploy-50-times-a- day](http://www.infoq.com/news/2014/03/etsy-deploy-50-times-a-day) (Btw. I won't say that deploying 50 times a day is a best practice in all cases)

</comment></comment></comment><comment><USER7> My favorite resource for learning how to test your code is [http://getpython3.com/diveintopython3/unit- testing.html](http://getpython3.com/diveintopython3/unit-testing.html)

Once you start testing your code, it's addictive. Testing gives you confidence.

\- By forcing you to detail your requirements, writing tests helps you make sure that you're building the right thing.

\- Testing lets you refactor your code with confidence -- if your old tests still pass after you refactor, your new version works the same way as your old version.

\- Testing makes your code much (MUCH!) more maintainable. As long as your old tests still pass, you can be confident that the new code you wrote didn't break any of your old code.

<comment><AUTHOR> Yeah, addictive it is.

I remember last year contributing[1] to a 2048 python game, where the maintainer committed[2] test suite lengthy than my commit and He was doing it like a charm.

I think I should start from that very repository as I know it very well already.

1\. [https://github.com/bfontaine/term2048/commits?author=pravj](https://github.com/bfontaine/term2048/commits?author=pravj)

2\. [https://github.com/bfontaine/term2048/commit/6f9a46283c2cc0a...](https://github.com/bfontaine/term2048/commit/6f9a46283c2cc0a2bf105f3e899e3f127d62610b)

<comment><USER8> That looks good. For counterpoint, here is my 2048 including tests for just the tricky bit: [https://github.com/darius/sturm/blob/master/2048.py](https://github.com/darius/sturm/blob/master/2048.py)

I have Emacs set up to run them on a keypress without even having to save the file; you can create and run these tests even quicker than trying things out in a REPL, and unlike the REPL they persist to be rerun after the next change.

If you've been feeling like testing is too much work, one angle is to reduce the amount of work it'll take to start.

</comment></comment></comment><comment><USER5> Start watching James Shore's "Let's Play: TDD" videos [1]. Yes, it is in Java and about making a basic desktop app for finance tracking - but that doesn't matter. I'm cutting out paradox of choice and just telling you to start here :)

This is a great introduction to the basics of TDD, is appropriate for beginners, shows trial and error (not edited/rehearsed 'final versions'). It is very digestible (15 min per episode) and free to watch on YouTube. It will seem tedious at times, but just commit to watching the first couple episodes and stick with it.

Destroy All Software, "Is TDD Dead" Hangouts, other more specific books, etc are all _amazing_ resources - but they are not a good place for a beginner to start. Once you have a basic understanding and have personally run into some of the tricky situations (mocks/stubs, testing at system boundaries, slow test suites, etc) these are invaluable, but until then just file them away to revisit later.

[1]: [http://www.jamesshore.com/Blog/Lets-Play/Lets-Play-Test- Driv...](http://www.jamesshore.com/Blog/Lets-Play/Lets-Play-Test-Driven- Development.html)

<comment><USER9> Thanks for the plug. :-) I also have a JavaScript TDD screencast at [http://www.letscodejavascript.com](http://www.letscodejavascript.com). Different technologies and challenges, same concept.

</comment></comment><comment><USER10> I've found the Craftsman series by Uncle Bob[1] to be very helpful in showing how to do not only TDD, but also pair programming. Before that I would complete tutorials and exercises, but was never able to effectively use it in actual projects. The Craftsman series shows the steps of using TDD in both easy and tricky situations, such as socket code, and enabled me to become much more comfortable with the process.

[1] [http://www.objectmentor.com/resources/publishedArticles.html](http://www.objectmentor.com/resources/publishedArticles.html)

<comment><USER11> I was just about to post this! Craftsman was the the thing that made me actually grok TDD.

</comment></comment><comment><USER12> I got into it by watching DAS (destroyallsoftware.com) by Gary Bernhardt (creator of the WAT presentation), it has truly shaped me into a better developer. Not only will you learn how to practice TDD, but so much more: refactoring, unix tools, OO-principles ... I could go on forever, it's really a great series.

</comment><comment><USER13> Hi, currently writing a book on the subject and I'm doing a bit of research myself.

There are two aspects of testing that you need to discern: the development and the project management point of view. The first regards what and how to test things. This can be achieved by any developer and is moderately easy with the right help and mentoring. The second instead is the most difficult: trying to force tests in a non-test-focused environment, where the business does not understand the meaning and/or the value of testing can be poisonous to us and the business itself. In other words there must be an effort in both directions. I can keep talking about these two points, but I'll skip them for now unless you're interested.

Regardless of the current environment you're in, and taking for granted that the second part is - if not fully, at least partially satisfied, let's have a look at how to start with TDD: the major problem you're facing is that TDD does not define "what to test". That's why BDD was introduced, to fill in the gaps that TDD has.

Still BDD is somewhat lacking depth and proactive understanding from the project level on how much should be spent on unit tests, how much on functional and acceptance tests. On this note, Google has defined the ACC, which helps you define the testing plan for your application; I think it's totally worth from both a developer and business perspective to dig a bit more into that, especially if you want to get into testing properly.

If you still fail to see why tests are important, let's put it down this way, using James Whittaker's words: "although it is true that quality cannot be tested in, it's equally evident that without testing is impossible to develop anything of quality".

my 2 cents

<comment><USER14> "Hi, currently writing a book on the subject and I'm doing a bit of research myself."

"trying to force tests in a non-test-focused environment, where the business does not understand the meaning and/or the value of testing can be poisonous to us and the business itself"

Sorry to be a bit negative, bit it sound like you have a conclusion that you want to reach before you have done your research. That's not really how research should work. Research should be done and conclusions reached afterwards.

</comment></comment><comment><USER15> TDD is a subset of automated testing as a whole. You'll find proponents of testing who might not actually like TDD. It's more of an opinion about the best approach. Anyhow TDD is essentially writing the APIs, interfaces, and function signatures first, then writing tests, then implementing things under the hood, then getting tests to pass.

Automated testing (unit or integration tests) is an extension of taking those little one-off things we do during development to make sure things work, and formalizing them to be a permanent part of the code base. Some people go further then and try to add tests for every feature or (gasp) every single line and sub-line of code.

It's easy to get carried away with testing. And some people have valid arguments against testing. But it's nothing too hard or unapproachable. The point really is that everyone does testing already, but not everyone keeps all their tests and makes them nice.

<comment><USER16> Case in point: I'm big on testing (I have pushed testing hard at three companies I have been at), but I dislike TDD strongly. I have often found that I am not sure how I would like to design components until I start implementing, and TDD is too rigid for arriving at an optimal implementation. I prefer to figure out the implementation, then write a thorough set of tests.

</comment></comment><comment><USER17> The reason you _need_ tests is so that (a) when you change some code in the future it doesn't break any of your functionality without you knowing about it and (b) if someone else changes you code it doesn't break any of your functionality without you knowing about it.

If you don't believe that you need unit tests, you won't write them - so step one is persuading yourself that they're useful. So try to remember a time when you broke your code in an unexpected way, and then try to work out what kind of unit test would have helped avoid that.

</comment><comment><USER18> Well the question looks more like a why instead of a how.. answering the how is simple, if you are starting on a new project (as you seem to be), start with unit tests for all functions, for anything that talks to DBs/external APIs use mocks.

Answering the why,

scenario 0 - it forces you to have functions that do one thing and one thing well. Unit testing mostly helps people keep functions small and focused.

scenario 1 - assume you are working on a fun app without tests. Everything is fine and the app works great. After some time you decide to add a new feature X, and you realize you need to modify an existing function to achieve that.. you modify that, and the new feature X works fine, but two days later you will realize that an old feature Y is broken.

scenario 2 - scenario 1 but with collaborators instead of yourself revisiting the app.

scenario 3 - people use unit tests to understand code - while reading/working on other people's code. Unit tests also serve as excellent examples on how to call/use something, which params to pass etc.

There are a lot more reasons esp for large projects, and you never know when a small one off project grows into something big and critical so its recommended to always start with unit tests as adding them later is usually 10x more work as it would require refactoring etc.

</comment><comment><USER19> Testing and certainly TDD usually fall by the wayside because it takes too long. At least that is the perception. I see two keys to keep tests lightweight, fast, and desirable.

First, you should choose testing and mocking libraries and learn them completely and totally. They are usually not that complicated. Read all the docs and memorize all the neat things they can do. Most libraries have a best practices guide. Read it and follow it. The point of this is to make sure that you can write tests as quickly as you can write trivial if/then statements.

Second, keep your tests as simple as possible while still testing behavior. Do not verify that every variable is set or if every method is called, or the right thing is passed everywhere. The tests should read like documentation: it should do x, it should do y. If you find the process of writing tests arduous or difficult to maintain, you're overcomplicating your tests (and probably your code, too).

In a word: lightweight.

</comment><comment><USER20> In general, don't worry (too much) about tests in the beginning of a project until it's likely you'll have more than one user (aka yourself) and/or paying customers. If you have neither users nor customers, don't feel too guilty about your lack of tests. In many cases, it's more important to make something useful enough that makes an investment in more testing later worthwhile. Later, when you _do_ have users and customers, you will want your tests to discover regressions before your users do.

However, the longer you wait, the higher the risk that you'll discover your code is not easily testable... which will require lots of refactoring to make testable. And that refactoring is made harder by the lack of tests...

In the meantime, if you're truly stuck, write down a list of how you're currently manually testing your code and write down edge and corner cases you're worried about.

(disclosure: I make testing tools for a living.)

</comment><comment><USER21> In August of this year I walked into a job interview for an entry-level'ish Rails dev position at a start-up. Already having a great job in education, I made clear that I was weak in testing and needed a plan to patch things up. I'm now very confident with testing using MiniTest. Here're my 2 cents:

\- Build something super easy (<4 hours), using Test-Driven Development. The example I used was a URL shortener.

\- Rebuild one of your existing apps using Test-Driven Development. If you're wondering where to get started, watch videos titled "creating a simple app using ____ and TDD", or even consider calling the Rails hotline.

\- Get someone to look at your test code for you. I learned a ton from this, I can't even begin.

\- Use MiniTest. RSpec is amazing, but I found MiniTest to be more transparent as to what was actually happening.

\- Check out the codeschool and codeacademy tutorials. Very helpful.

Best of luck. It's a very difficult topic, one that I really struggled with.

</comment><comment><USER22> I would like to point out that TDD isn't really about tests, it's about design of your program. It forces you from the very beginning to deal with really important questions: how do one use a piece of your program? Is it easy, clear and simple? Can it be tested? What do you expect from the program? Is your program or component overcomplicated?

Design your programs from top to bottom fleshing out details as you go. Deal with one abstraction at a time. And when you're finished you can throw away non-critical tests so that they don't outlive their purpose.

Do remember that tests are code too and that they have to be maintained and that they can become a part of technical debt. Do not use TDD for prototypes when you really don't know how or why implement your program. Create a prototype, explore possibilities, throw the prototype away and write a production version with TDD.

<comment><USER14> A lot of the time (certainly in my work) the requirements are incomplete / vague enough, that it is easier just to build a prototype and work from there. As such tests will just require two or three times as much code, and there is a fair likely hood that they will be thrown way afterwards.

I know this does not fit waterfall or TTD / agile methodology, but I am certain that there is a very large percentage of IT workers that have to work this way.

</comment></comment><comment><USER23> TDD without refactoring is like sex without orgasm. Okay, maybe it's not that bad.. ;)

Seriously, the most fun I ever had with TDD was when using a language that my IDE had great refactoring tools for. Just write all your code inside a test to start with, don't bother with production anything. The test becomes a little like a command line program, launches immediately from the IDE and you can iterate super quickly. Your output is whether the test (with the test data) passes or fails. I'd pick the test framework by whatever the IDE liked best. Pursue solutions that viscerally satisfy until you know better.

Once you have a test working like that, do "Extract Method" followed immediately by "Move Method". The destination of the move is the production class. With two menu selections, you have a perfectly testable interface, called perfectly by the test. A good extract refactoring always proposes parameters for the method and lets you order and rename them. It will also recognize extractions that can't work, like when two results are generated by the selected code. In that case, extract more than one method and move all the methods to the production code.

Want to add more code? Do the same thing again and again and again, each time as a new test.

When you are done, you'll have production classes that are the composite of the extractions and all the tests that once contained inline code (but now contain method calls to the production code).

At some point, you will ask "how can I improve my tests?" The answer is easy: Code coverage tools. You should shoot for > 80% of your production code having test coverage. Some say more, few say less. Make some rules for yourself about things you don't bother testing, like getters and setters, use the 20% leeway so you aren't flogging yourself. Keep having fun, don't make a death march out of testing every last line of code.

This habit becomes really fun. You'll start telling your friends. Nirvana will ensue.

<comment><USER24> What IDE did you use? Can this workflow work in Visual Studio using NUnit?

<comment><USER25> ReSharper is an add-on component for Visual Studio that is (IMO) the best refactoring tool available for any IDE. ReSharper includes an NUnit-based test runner, too.

JetBrains is the company that makes ReSharper. I also use AppCode (their alternative to Xcode) in a way that's similar to how I use ReSharper. I do most of my iOS development in Xcode but load the project in AppCode before committing so I can take advantage of its superior code inspection and refactorings.

</comment></comment></comment><comment><USER26> So TDD is a difficult thing to get into from the beginning. The more experienced you are as a developer the easier it will be to write tests. The thing that is great about TDD is that it forces you to write discrete and modular code as it tends to be easier to test that way.

This week, one of my coworkers described being new to TDD like being new to vim. There is a horribly steep learning curve but once you "get it" it becomes second nature. The real win of TDD, especially for open source, is that when the projects start to get bigger and harder to manually test you can merge PRs with a bit more confidence that you're not breaking things. I can speak with a bit of experience here as an OSS co-maintainer of two pretty large (>500 unique contributors) projects, graphite, and salt.

</comment><comment><USER27> TDD takes time and is hard to get right at first. I'm sure you will find the usual tutorials so I would rather recommend this blog post: [https://www.stevefenton.co.uk/Content/Blog/Date/201305/Blog/...](https://www.stevefenton.co.uk/Content/Blog/Date/201305/Blog/My- Unit-Testing-Epiphany/)

and Ian Cooper's talk "TDD, where did it all go wrong": [https://vimeo.com/68375232](https://vimeo.com/68375232)

In a nutshell: test your high level API and not your implementation, minimize your usage of mocking.

</comment><comment><USER28> For .Net developers I can recommend the combination of local dev machine continuous testing using NCrunch, manual runs using the unit test runner in Resharper and then the NUnit test runner in TeamCity.

TeamCity is a gatekeeper. Builds that fail unit testing don't get automatically deployed. Locally NCrunch keeps you updated on what is broken without you having to think about running your tests, since it runs them in the background for you. Resharper unit test runner helps you run and debug specific tests or groups of tests.

I work on a large application with many other developers and this flow works well for us.

</comment><comment><USER29> James Shore's TDDJS series is supposed to be excellent: [http://www.letscodejavascript.com/](http://www.letscodejavascript.com/)

</comment><comment><USER30> I usually start with an "it works" test that calls each method with expected inputs and asserts an expected result. The expected result most of the time is that it didn't throw an exception. I found that such tests usually cover most of each method and are pretty effective at detecting regressions.

When I'm fixing a bug, I first create a test that fails when reproducing the conditions that cause it, then I make necessary changes until that test passes.

</comment><comment><USER31> Thinking about testing can help with good overall design. Consider:

\- How can I build a small, testable unit that can be combined with other small, testable units?

\- How can I design a small, testable unit with a stable interface?

\- How can I test this small testable unit in isolation and in various production/deployment scenarios?

Choosing the right building blocks to focus on meshes well with testing thinking b/c it lends itself to a bottom-up philosophy.

</comment><comment><USER25> The best introduction to TDD that I've seen is Jon Reid's video tutorial here...

[http://qualitycoding.org/objective-c- tdd/](http://qualitycoding.org/objective-c-tdd/)

Even though he's demonstrating TDD with Objective-C, I've recommended this video to .NET developers and they've still had an "Aha!" moment when Jon explains the "TDD Waltz".

</comment><comment><USER32> > ultimately it's a image generation library, why this thing needs any tests

So you can be confident that it generates correct images, even three years from now when you've mostly forgotten about it but you dip back in just to add a quick feature without thinking about it very much -- or, for that matter, when someone submits a pull request, and you want to make sure it doesn't break anything.

</comment><comment><USER33> One very easy thing to test for is wether your SVG creating code actually returns valid XML/SVG or not.

Then you might want to make some of these magic values configurable so users can create different sizes or different color schemes and some of them might be dependent. Unfortunately, I doubt that this refactoring is done without mistakes. Maybe you should write some tests before and then refactor.

</comment><comment><USER34> TDD in what language? It's all about workflow. So if you're using java, you should get familiar with mvn and the junit lib. If you're using NodeJS, then you need to do something like mocha and grunt.

TDD gives you insane test coverage, but your process becomes: 1) Write a failing test 2) Write some code 3) Run test 4) Repeat 2 & 3 until test works, then go back to 1.

</comment><comment><USER35> Long time ago I also didn't write tests. Now this software causes me the most problems. For start you shouldn't focus on testing with any methodology like TDD, BDD, etc., just ignore it. Better read about Right-BICEP, this going to help you shift way of thinking. Anyway after some hellish struggling you should be able always to think out tests before code.

</comment><comment><USER36> >Now, the thing that stopped me from writing tests was, I thought that ultimately it's a image generation library, why this thing needs any tests.

I'm not sure this one does. It's a very simple library and there's no bugs in the issue tracker.

I would write a test for the first bug you encounter, though.

Or, if you start writing a more complex method on a new feature, start TDD'ing that.

</comment><comment><USER37> There were two things that helped me get started: pairing with a more experienced developer who did TDD, and reading Growing Object-Oriented Software, Guided by Tests by Steve Freeman and Nat Pryce. You might not have the luxury of the first, but the second is pretty accessible, even if you don't use the particular tools that the authors demonstrate.

</comment><comment><USER38> I thought TDD seemed like a waste until I wanted to really figure out Rails and went through mhartl's Rails tutorial. By the end of the book, I realized that TDD had automated all the silly manual tests I did, and actually saved me time. I was kind of shocked, though thats what I get for thinking I actually knew an answer...:)

</comment><comment><USER39> Really, you start by starting.

First grab a testing framework for your language, if it's not built-in. Something that runs the tests in your project once you run a command.

Following that, add a test to a function in your project. You can start with an easy one. Try that and see what works, try covering corner cases, etc

Then you can go for actual TDD once you write new code.

</comment><comment><USER40> Tests for Penticons sounds straightforward to be honest. After saving some example images generated from a set of inputs, write some code that checks those inputs produce those images. Imagemagick has image comparison commands that can help . I did something similar when optimising a gaussian blur filter and found it useful.

</comment><comment><USER41> I personally got started with Gary Bernhardt's excellent Destroy All Software screencasts. I started with the third season for his series on untested code, and got the other four soon after.

[https://www.destroyallsoftware.com](https://www.destroyallsoftware.com)

</comment><comment><USER42> Personally I love Uncle Bob's videos. He has some great TDD theory and work throughs - it is how I got started: [https://cleancoders.com/](https://cleancoders.com/)

Specifically episodes 6 and 7. But if you have time - I recommend most of the videos

</comment><comment><USER43> Writing tests is like writing articles. You just have to start writing and at some point you will get better.

Writing tests will change your coding style and way of thinking which is great. You might read some articles about testing for your language of choice.

Just start :)

</comment><comment><USER44> When you're writing your procedures, you have to think about what you want them to do. What small unit of work each procedure should perform. That's the best time to write the tests for the procedure, because it will help you to think of edge cases that you might otherwise miss, and it will confirm that the procedure does what you expect before you move onto the next. It's also the easiest time to write the test for the procedure, because you haven't yet committed to any particular level of complexity or dependency structure. If you write tests first, your code will always be testable. If you attempt to show up the next day and start writing tests, you may find that the person who wrote the code yesterday wrote some pretty untestable code. Another benefit to having the tests is that they will continue to pay off as you modify the code weeks and months later, always confirming that you haven't broken anything.

Like most other learning endeavours, I found that the best approach was to start small. Try something simple like a fizz-buzz test. You'll probably have more trouble setting up and writing the tests than writing the code under test. That's okay. Like any other learning process, it takes time to get used to the new language and behaviour that is required to become fluent in writing testable code. Make sure that every time you save your working code, your tests run and you can see the result so that you get immediate feedback. And make sure to always work in as small a unit of work as seems comfortable.

Here are some example test function names for fizzbuzz

1\. itPrintsFizzForMultiplesOfThree() 2\. itPrintsBuzzForMultiplesOfFive()

These tests might be too broad in scope. Where is it getting the numbers that it's checking for multiples? What does "print" mean? How are the tests going to confirm what was printed?

1\. itReturnsTrueForMultiplesOfThree() 2\. itReturnsTrueForMultiplesOfFive() 3\. itReturnsEitherFizzOrBuzzOrTheNumber() 4\. itSendsTheResultToOutput()

These tests are against simpler methods and are easier to write but the tradeoff is that they make the code under test too fine grained at times. Can you have too many tests? I don't think that's likely in practice, not if they're true unit tests and extremely quick to execute. But some would disagree when they see a five method fizzbuzz class rather than a class with one "doTheWholeThing" method. You have to find what works for you. When you return to your code a day or two later, do the tests immediately make sense? If not, they're probably too complicated. Start small, get a feel for the shift in mindset, grow from there.

</comment><comment><USER45> Here's the thing with TDD: until you work on a project that's either

a) contributed to by a lot of developers that aren't familiar with the source code,

b) so large that you're scared of making any substantial changes because the last time you did that another piece broke and it took forever to figure out it was actually broken and another forever to figure out how to get both pieces working together and in the process you half-broke this other piece and GAH maybe I should just rewrite the entire thing, or:

c) mission-critical, where a piece not doing what it's supposed to means lost lives or money,

then TDD is a net waste of time. Much like learning git, you'll be fighting an uphill battle with your mind at every stumbling block ("ugh this is so complicated - why am I learning this again? Doesn't putting my source code in Dropbox solve all of these problems already?") until you have an actual, real, legitimate use for the solution ("oh right, I'm learning git because using Dropbox to collaborate means 'conflicted copy' city").

Tests don't have to be complicated. They don't have to use the next new shiny framework, they don't have to have a smart lookup system that auto-runs files that are checked in and sends you an email if you push bad code; tests are just if statements, and they're mostly the if statements that _you 're already running through your mind when you program_. Here's a hopefully not too contrived example:

When you wrote commit 4a069[1], how did you know the code you wrote actually _did_ anything? From my quick understanding of reading this over, it looks like you changed `padding` and `size` from constants (5 and 30 respectively) to variables set somewhere else (in `utils.go`). If you made all these changes at once, then re-ran whatever code you use to make a penticon, the expected behavior is that you'd see the exact same thing as before (test#1).

But wait, were you even editing the same file you ran? Let's double `Padding` and `Size` in `utils.go` and make sure it changes the image (test#2). Alright cool, it does. But wait, the padding looks way too big - is it twice what it needs to be? Let's try `Padding = 1` and `Padding = 0` and make sure that looks how I expect it to (test#3, test#4). Awesome - that's perfect.

Does the size work too? I wonder if this would break if the `Size=0` (test#5). Oh shoot, what if _both_ the size and padding were 0 (test#6). OH SHOOT WHAT IF THEY WERE NEGATIVE? (test#7).

\---

All of that to illustrate: the difference between what you're (probably) doing right now and TDD is that in TDD you write down each test as you're testing it. At the end of adding those two variables you'd have a second file of 7 if statements that make sure that changing the size and padding works like it's supposed to.

Unfortunately, `penticons.go` is a horrible project to bring TDD into your workflow because 1) it's tiny and can probably fit in your head all at once so you'll know immediately anyway if something breaks, and 2) testing images is hard. It looks like a lot of your other public projects are equally as TDD- unnecessary.

What you _could_ do is generate a bunch of references images (like a 1x1px empty image for when the padding=1 and Size=0), then write a script that runs the code that should generate the same image and make sure they match bit-for- bit. Again, though: until you're feeling the pain that having the piece of mind that no other part of your program was just broken by what you did, you don't need to add TDD to your workflow.

1\. [https://github.com/penticons/penticons.go/commit/4a069619545...](https://github.com/penticons/penticons.go/commit/4a06961954530ece6a8c451feee7b1027a3f5e30)

<comment><USER46> This is almost like saying until you've been injured in a car accident there's no reason to wear your seat belt.

<comment><USER45> I'd argue that it's closer analogous to wearing a regular seat belt until you start driving in situations where the benefits of wearing a five-point harness outweigh the cons of reduced driving mobility.

</comment></comment></comment><comment><USER47> isnt TDD dead already ?

Just write unit and integration tests

<comment><USER48> Still feeds the trainers and book-writes and as such is "the-only-correct-way- to-write-correct-software".

</comment></comment><comment><USER49> Have you tried Typemock? It helps you get started with unit testing and offers a free version

</comment><comment><USER50> I'd recommend learning a new language that has a strong TDD community. I started testing and TDD by adding unit tests to an existing C++ project and didn't really get the point. I recently picked up Ruby and the course I took taught RSpec alongside Ruby. It made so much more sense. Plus, learn another language.

</comment><comment><USER51> You start with a test (that fails).

</comment><comment><USER52> TDD requires you write the test first, then the code later. At an extreme you would write a test for a minimal piece of functionality, then do the minimal amount of coding to get the test to pass and then repeat. I.e. you would write no production code that is not covered by a test.

This takes a lot of discipline and I have never done it a t work but it is fun to try at home to see what the extreme case is like. I don't do this at work because I have no control over 99.99% of the production code and how loosely coupled it is for testing. (In C#, but in Ruby you can get away with it due to duck typing).

TDD forces you to write code that is testable. So you never should end up thinking 'oh shit I need to expose that private member variable to make this class testable'.

Anyway just try it and then as you get stuck read up on how to do TDD. I am always an advocate of try before you learn (makes the learning easier).</comment>


Vodafone 236 (zte) - <AUTHOR> http://forum.vodafone.co.uk/t5/Other-Manufacturers/Vodafone-236-zte/td-p/331671 <comment><USER2> simple, ring vodafone, ask for unlock code, input code, win!

you could also read the FAQ posted to you on the forum you linked.

</comment><comment><AUTHOR> Aparatus to unlock vodafone 236</comment>


The Open-Closed Principle, in review (2013) - <AUTHOR> https://codeblog.jonskeet.uk/2013/03/15/the-open-closed-principle-in-review/ <comment><AUTHOR> Another modernised statement of the OCP:

[https://softwareengineering.stackexchange.com/a/348114](https://softwareengineering.stackexchange.com/a/348114)

 _> Derek Elkins: A more abstract and relevant statement of the OCP is: "a component should allow for extension without need of violating its abstraction boundaries". I would go further and say a more modern rendition is: "a component should enforce its abstraction boundaries but allow for extension"._</comment>


How and where do you get beta testers ? - <AUTHOR>

What are the ways for recruiting some beta testers for your product ? (Besides asking friends to do beta testing) <comment><USER2> Find an online community relevant to your product and just ask.

Find a local university or college and offer free beer or munchies for some students to test your product.

If you already have a community (mailing list, forum, twitter followers), relevant or not, ask them.</comment>


Apache Flink 1.9.0 Release Announcement - <AUTHOR> https://flink.apache.org/news/2019/08/22/release-1.9.0.html <comment><USER2> Apache has a large number of stream processing frameworks:

Flink vs Spark vs Storm vs Kafka vs Samza vs Apex

How do they compare? How would you choose which one to use?

<comment><USER3> I don't have experience with Samza or Apex, but as for the first three:

1\. Flink - Focused on stateful stream processing.

2\. Spark - Focused on batch processing. Can be used for continuous streams, but approaches them as "micro-batches".

3\. Kafka - A message queue system (for all practical purposes). Has an optional stream processing add-on for basic needs.

Separate use cases and strengths aside, it's worth calling out that all of these products are primarily backed by completely different companies. Apache is a consortium made of many companies, and serves as common branding for "community editions" of their "enterprise edition" products. There can quite a lot of overlap between sponsored products in this consortium.

<comment><USER4> Spark supports both microbatch and continuous stream processing.

Apache Software Foundation is not a consortium made of many companies but a single non-profit that provides organizational support for open source projects, some of which have contributors employed as such by other companies and some of which have only volunteer contributors.

</comment></comment></comment><comment><USER5> This is exciting! I've been using Flink a lot lately, and fine-grained recovery is going to be very useful for [work stuff]!

</comment><comment><USER6> From a WeChat posting I heard 1.5M LOC is changed. Wow</comment>


Inside An 'E-Meter' - <AUTHOR> http://www.reddit.com/r/pics/comments/esf3s/hey_church_of_scientology_guess_what_i_have/c1ak1q9

<comment><USER2> If I remember rightly this is nothing more than a Wheatstone bridge connected up to a meter. Nothing more than a few bucks in value I guess.</comment>


Show HN: I Implemented Shadow Volumes in WebGL - <AUTHOR> https://mikolalysenko.github.io/regl/www/gallery/shadow-volume.js.html <comment><AUTHOR> Hi guys. This is a reference implementation of shadow volumes that I implemented with the help of Mikola Lysenko. This demo was implemented to demonstrate the stencil buffer manipulation features of our WebGL Framework regl: [https://github.com/mikolalysenko/regl](https://github.com/mikolalysenko/regl)

I provide a video here: [https://www.youtube.com/watch?v=oO0LJWy5COg](https://www.youtube.com/watch?v=oO0LJWy5COg) in case the demo won't run.

Since these shadows are shadow volumes, there are no jaggies whatsoever. Even if you zoom them in, they remain crisp and clear. That is one advantage of shadow volumes compared with shadow maps, but it is also the only real advantage of the method I can come up; I personally think shadow volumes is a pretty terrible technique. Drawing the shadow silhouette eats fill-rate, constructing the silhouette can be very CPU-intensive, and the technique in general is quite tricky to implement, compared with shadow mapping. Personally, I can't find a single reason that a sane person would use this technique nowadays. But some may disagree with me, I suppose...

I mainly implemented this demo to provide a reference implementation of shadow volumes. In particular, this is an implementation of Carmack's Reverse([https://en.wikipedia.org/wiki/Shadow_volume#Depth_fail](https://en.wikipedia.org/wiki/Shadow_volume#Depth_fail)), or depth fail, as some people like to call it. My implementation follows the description on Wikipedia pretty closely. I provide the source code here: [https://github.com/mikolalysenko/regl/blob/gh- pages/example/...](https://github.com/mikolalysenko/regl/blob/gh- pages/example/shadow-volume.js)

I want others to be able to learn from this code how shadow volumes can be implemented, so I have littered the code with comments. I hope that at least someone will find it interesting.</comment>


Amazon commences fire sale of Fire Phone at $199 off-contract - <AUTHOR> http://www.amazon.com/gp/product/B00OC0USA6/ref=as_li_tl?ie=UTF8&camp=1789&creative=390957&creativeASIN=B00OC0USA6&linkCode=as2&tag=cybe0cf-20&linkId=UXSMUHY4MK4ULHPC

<comment><USER2> still too expensive in my opinion.

should be free for all prime subscribers.</comment>


The life and views of Ayn Rand: Capitalism's martyred hero - <AUTHOR> http://www.economist.com/books/displaystory.cfm?story_id=14698215

<comment><USER2> "She lived to see laissez-faire triumph over collectivism and one of her leading acolytes, Alan Greenspan, appointed to the president's Council of Economic Advisers."

I would never count the chairman of a central planning entity on the side of laissez-faire economics.

I don't know much about him before the fed though, maybe he changed in the 10 years between the Council of Economic Advisers and the Federal Reserve.

</comment><comment><USER3> Martyred?

<comment><USER4> right? a bit of link-bait isn't it?</comment></comment>


Let's Build a Can Stirling Engine (2000) - <AUTHOR> http://www.bekkoame.ne.jp/~khirata/english/mk_can.htm <comment><USER2> One of the things which really, really rustles my jimmies is computer nerds talking about matter the way they talk about Stirling engines. Someone once upon a time told them that Stirling engines were efficient heat engines which work on diffuse heat sources, and suddenly, Mr nerd wants to stick them everywhere. No. Unlike using some sorting or hashing algorithm, there are tradeoffs and complexities in technologies involving matter beyond anything you do in your day to day work. "Stirling engine" isn't some kind of algorithm you can put everywhere like your favorite red-black tree implementation.

Stirling engines, like all heat engines, work more efficiently with large temperature differentials: this means advanced materials. External combustion immediately puts you in a weird and unfamiliar engineering place where you have the firey bits outside the piston where you can do the usual things to keep it under control. Cooling is also different from just farting out exhaust and pumping water through the block in a normal engine. If you don't have a large temperature differential you have shitty efficiency and it's not worth doing. Practical Stirling engines which do useful work, whether for heating or cooling, are usually large, have sealed, pressurized helium as working fluids (oh? you don't know about working fluids in Stirling engines?), complicated gearing mechanisms and sometimes even magnetic coupling to the outside world, and have extremely complex and precision machine parts compared to the slop you see in consumer grade items like a Porsche Engine. Ratios in the engine are often tailored to a very specific use case; and will work for shit if your heat spec is outside that very, very narrow use case. Go have a look at what goes into designing a real world Stirling engine for example in [0].

People don't use Otto/Rankine/Brayton/whatever because of some live-steam or anti-Stirling conspiracy: they use it because Stirling engines, outside of a few mostly unimportant use cases, are usually expensive _and_ shit. The two most widespread industrial uses of the things I can think of were a Chrysler air conditioner[1] and a coleman beer cooler[2], both using the same Japanese built Stirling cooler. Even in these use cases, which, mind you are using a Stirling engine in reverse from what HN weebs want them for, they didn't exactly cover themselves in glory. They were expensive, heavy, fragile and not as efficient as would justify their bad qualities over a more standard cooling unit.

[0][https://ntrs.nasa.gov/citations/19830022057](https://ntrs.nasa.gov/citations/19830022057)

[1] [https://docplayer.net/40169613-The-reliability- development-o...](https://docplayer.net/40169613-The-reliability-development- of-miniature-stirling-cryocoolers.html) (I think)

[2][https://kk.org/cooltools/coleman- stirlin/](https://kk.org/cooltools/coleman-stirlin/)

<comment><USER3> I cannot see the relation between your rant and the article which is about a didactic implementation by some teacher.

<comment><USER2> scroll down

</comment></comment></comment><comment><USER4> > The Gotland-class submarines of the Swedish Navy [...] are the first > submarines in the world to feature a Stirling engine air-independent > propulsion (AIP) system [...]

[https://en.wikipedia.org/wiki/Gotland- class_submarine](https://en.wikipedia.org/wiki/Gotland-class_submarine)

<comment><USER5> The manufacturer of the Stirling engine for those submarines, Kokums, is the source of the engines used for a dish-Stirling solar energy system I worked on for a licensee of Stirling Energy Systems[1]. It was a concentrating solar energy system consisting of a parabolic mirror focusing sunlight onto a heater head atop the Stirling engine. Quite efficient at around 30% conversion of direct sunlight to electricity - each unit generated about 25kW under clear skies. Quite a simple system - just a big mirror, sun tracker, Stirling engine and generator. Super reliable - no nasty combustion products. And not very expensive - BOM cost about the same as a mid-size car. But dropping PV prices ended up killing it.

[1][https://en.wikipedia.org/wiki/Stirling_Energy_Systems](https://en.wikipedia.org/wiki/Stirling_Energy_Systems)

<comment><USER6> I've come across those Stirling engine parabolic dish systems before and always thought they looked really impressive. Definitely installed in my dream off grid retirement place somewhere sunny.

<comment><USER5> Although quieter than ICEs, those engines are not silent. Too noisy to be close to homes. You would need to keep that in mind in your off grid dream.

</comment></comment></comment></comment><comment><USER7> In a similar vein, if you haven't watched a pop-pop boat circumnavigate your bathtub, you haven't lived.

[https://en.wikipedia.org/wiki/Pop_pop_boat](https://en.wikipedia.org/wiki/Pop_pop_boat)

</comment><comment><USER8> Can anyone point to the reason(s) why Stirling Engines appear to be unobtainable for stationary power generation? I've been wanting a reasonably sized one (say 2-5kW) for quite some time to run off of woodgas, or other high temp heat sources. Size doesn't really matter, I just want something relatively quiet, that needs much less maintenance than an internal combustion engine.

<comment><USER9> Heh, I actually came here to take advantage of this post to ask something similar: Could a Stirling engine be used to, say, charge a battery using the exhaust heat from an AC unit?

<comment><USER10> The energy generated is related to the difference in temperature. So if you're using AC out as hot and ambient as cold, the generation will be small, and it's necessarily much less than the energy spent to run the AC.

<comment><USER11> Now you've got me wondering if you could design a reverse-stirling engine that runs off an intensely endothermic reaction of some sort.

<comment><USER10> The engine only requires a "hot" side and a "cold" side, so there's no reason why the cold side can't be way below ambient temperature, such as an endothermic reaction or a tank of liquid nitrogen. Here's a video of a guy running one of those coffee-cup-top toy engines off liquid nitrogen: [https://www.youtube.com/watch?v=O6eEvU5piQg](https://www.youtube.com/watch?v=O6eEvU5piQg)

Some people have proposed this as yet another bulk energy storage system for the grid; giant underground cryotanks of liquid nitrogen. With careful design the same gear could be used in "forwards" or "reverse" mode. The limit is that the Carnot efficiency isn't great.

</comment></comment></comment></comment></comment><comment><USER12> A stirling engine might be a perfect part for a bare bones open hardware hybrid car.

A stirling engine might not produce enough power to power the wheels directly, but it could produce electricity quite efficiently at constant power output. It's fairly efficient, compact, relatively quiet and simple to build.

The electricity could be stored in fewer batteries and/or supercapacitors. The electricity from these would then power the wheels.

<comment><USER12> A stirling powered hybrid car seems to be a popular idea, but not taking off:

\- [https://www.digitaltrends.com/cars/stirling-hybrid- engine/](https://www.digitaltrends.com/cars/stirling-hybrid-engine/) \- [https://www.youtube.com/watch?v=ehWbFoMfmMo](https://www.youtube.com/watch?v=ehWbFoMfmMo) \- [https://hackaday.com/2008/11/09/dean-kamens-stirling- engine-...](https://hackaday.com/2008/11/09/dean-kamens-stirling-engine-car/)</comment></comment>