The Graphing Calculator Story - <AUTHOR> http://www.pacifict.com/Story/ <comment><USER2> Reading this old story again it's interesting to recontextualize it into 2011. Would this have still happened they same way today, when tools are cheap (or free!) and online distribution gives everyone a large enough audience? (Obviously the PPC being a prototype and not available commercially throws a wrench in my hypothesis but bear with me)

</comment><comment><USER3> This story is, in one sense, the antidote to the "Don't Call Yourself a Programmer" article. These guys were programmers. They programmed because they liked to program, not to add business value.

</comment><comment><AUTHOR> And a Google Tech Talk about the same: <http://video.google.com/videoplay?docid=-7497796873809571567>

</comment><comment><USER4> A quick search on HN revealed this very page has been posted 5 times before.

All the recent discussion about improving the "quality" of the HN front page seems more relevant with so many repeat-posts popping up quite often.

<comment><USER5> However HN gets new visitors all the time, something old could be new to me, and something old to me could be new to you.

<comment><USER4> So, would it be okay to keep re-posting (high quality) stuff because it is new to me? btw, the most recent post of the Graphing Calculator Story was 4 weeks ago.

NB: My comment was not about the quality of this particular post. The story is inspiring, of course.</comment></comment></comment>


I bet you over-engineered your startup - <AUTHOR> http://www.zemanta.com/fruitblog/i-bet-you-over-engineered-your-startup/ <comment><USER4> Of the three startups I've worked with, two of the three were ridiculously over-engineered monstrosities that were way over time budget. It was clear that the CIO/CTO wanted to do cool fun stuff and not build a marketable product.

The other was cobbled together with completely shit code, was constantly breaking on releases, and was glued together with perl scripts. They're now publicly traded.

<comment><USER5> Can you name names? Specifically the publically traded one ?

<comment><USER6> Here's my guess: Synacor. Took me only a few minutes of googling.

<comment><USER7> Can we refrain from punishing people for sharing their insights, especially when they explicitly opt to not share those details?

<comment><USER6> You're right. I tried to remove it, but I can't edit the comment anymore.

</comment></comment></comment></comment></comment><comment><USER8> From my own experience, developers, particularly inexperienced developers, when learning something new have an insatiable need to implement their new found knowledge .. no matter if it's a good fit or not for the problem at hand (myself included .. I remember abusing the hell out of recursion for example).

One of the worst examples I've seen is the functional programming paradigm being crowbarred out of PHP .. why.

<comment><USER9> _One of the worst examples I've seen is the functional programming paradigm being crowbarred out of PHP .. why._

Most likely related to the Innter-platform effect: _...the tendency of software architects to create a system so customizable as to become a replica, and often a poor replica, of the software development platform they are using._

<http://en.wikipedia.org/wiki/Inner-platform_effect>

One of the classic PHP examples being the Smarty templating system:

 _Smarty has been criticized for replicating features that PHP does natively very well, which leads to inefficiency_ :

<http://en.wikipedia.org/wiki/Smarty>

<comment><USER10> Hey bill - looks like you've been hellbanned. Something that you said on <http://news.ycombinator.com/item?id=4213223> ticked someone off. Maybe talk to email@example.com and get it sorted out.

PHP still sucks though ;)

<comment><USER11> Wow, I've seen much worse snark on HN get all the upvotes.

<comment><USER10> Yep. Evaporation in action... :(

</comment></comment></comment></comment></comment><comment><USER12> Many devs tend to over-engineer things whether they are at a startup or not simply because they like building things, that's why they are software developers. I don't think this phenomenon is much more complicated than that.

<comment><USER13> 'Over-engineering' is a term I'm starting to pay a lot more attention to :)

<comment><USER14> 'Over-architected' and 'over-optimized' are the terms I prefer. Whatever term(s) is(are) used, criticism should emphasize 'non-pragmatically-built', instead of emphasizing 'startups don't need any design, engineering, or optimization, whatsoever'.

<comment><USER13> > _over-optimized_

That does seem like a better term for it. Or at least an equal term for it :)

</comment></comment></comment></comment><comment><USER15> Sorry, but I think this is really bad advice, it goes about it from the wrong direction. Saying "monolithic" or "services" like one is good and one is bad, or one is complicated and one is simple, is kind of silly.

For example... which is simpler, writing your own search indexing tool in ruby on rails, or installing solr as a service? MySQL is also service, for some reason people tend to forget that. Conversely, if your processes aren't yet resource hogs, why not just let them remain general purpose workers? If you are constantly fiddling with multiple services to make any changes to your app, then yes, you have probably made a bad choice somewhere. But a HAproxy/nginx/rails/memcache/mysql/solr stack is already six services, and not really so complicated to work with. When you write your own services, you should aspire to that level of simplicity.

At the end of the day, the shortest path will be wherever it will be. It's your job as a developer to weigh the pro's and cons on a case by case basis. The hard part is to test drive everything so that you can change it later, and constantly evaluate what choices each decision you make is removing from the table (painting yourself into a corner if you are not careful).

Another way of putting it: if you are picking your architecture before you begin, based on some kind of generalized principle, you are already over- engineering.

</comment><comment><USER16> This is a really weird article.

The solution is not to say "Services Suck" or "Monolithic yay!", it's to realise that you should start with a monolithic app built in a good framework, then see how your app's internals are used/accessed as you grow THEN split out to logical well designed services.

Or in other words: Premature optimisation is the root of all evil.

<comment><USER17> More or less what the article said:

> Start merging services until you come to the bare essentials that have to be > discrete.

He's giving an heuristic for finding the right granularity of services - <USER2> is what is up for criticism, IIUC.

I totally agree with you, start "monolithic", SQL + a lightweight Python web framework for most simple apps.

<comment><USER18> > Start merging services until you come to the bare essentials that have to be > discrete.

I thing GP advised to: start with a monolithic system and then split up the services as your system grows and as you feel the need.

That sounds more solid advice.

</comment></comment></comment><comment><USER19> After reading the "What Happens" section of the OP's article I can see that he's made the classical mistake of making many things do one small thing, but they're not independent.

The message queue to notify component X of changes to data in Y is endemic of badly designed systems; if system X cares about changes to data in Y it should be designed that (at scale) it caches the data for a suitably short time, otherwise reads-through to the canonical source.

This is a common anti-pattern, and I've seen it built by smart teams at epic scale (millions of uniques per day) and it is still un-manageable.

Feature toggles, hard and soft-failing, together with a baked-in assumption that APIs are asynchronous (that is, unreliable) at as many levels as is feasible is a good architectural move. (And does not necessitate an abundance of architecture over feature code)

Loosely coupled components that expect their counterparts to respond slowly, or not at all are easy to implement and even easier to test. (HTTP, if one wants to use HTTP as the transport medium, learned this, and offers 201 and 202 for CREATED and ACCEPTED).

In my own projects (and I work mostly on near-realtime billing APIs) we bake this assumption (and others) into every transaction, as try to be restful, and transmit the state, and a URL which can be used to get the canonical representation of any resource, at any given moment, and objects in all parts of the system are stateful, relying on the handshakes (accepted/created) (404, 406, 409) to avoid race conditions and to make sure our systems can handle downtime of any component (internal or external)

As a result, we have lightning quick tests, we are very confident in the system's ability to perform, and we have read-through caches which respect the transport medium's headers.

I suspect the OP is right, many do over-engineer the startup, but remember many startups appear to have an abundance of developer potential, until they don't. (Usually through bad design, not over engineering, the two ought not to be confused)

Perhaps I am biased by having seen it happening in a large company, completely unscalable architecture, and at a point as many "architects" as they had developers, desperately trying to keep the wheels turning.

<comment><USER20> You sound like you'd be interested in CQRS.

</comment></comment><comment><USER21> Scalability is about more than operations/second or any single metric, it's about making a service/system that can survive at scale, both technically and logistically. A server that goes 10x faster than it's competitor but cannot work with other servers to go to 100x is not a scalable solution, whether that reason is because of some low level networking limitation or a high level programming or administration limitation.

More semantics, but over-engineering is about more than making things complicated. If a tool doesn't do what it was intended to do, or if you've ignored the proper level of complexity, it's because it was _badly_ engineered, not over-engineered. _Good_ engineering will "over-engineer" things as much as possible within the constraints of the solution.

And if you keep that in mind, then you really can't over-engineer things or make them too scalable.

<comment><USER22> You're sorta kinda conflating two distinct axes of scalability: vertical and horizontal.

A system which is vertically scalable is one which will run faster (for a given definition of "faster") on chunkier hardware.

A system which is horizontally scalable in theory becomes faster by adding more independent hardware. In this age of spinning up anonymous VPSes by the handful that's an attractive quality.

However, horizontal scalability levies a very heavy architectural tax. Nobody has produced a convincing platform that successfully abstracts away the many, _many_ moving parts and oversight that horizontal scaling requires in the same way that an operating system can abstract away a lot of the complexities of vertical scaling.

So what happens is that you spend less time thinking about the _problem domain_ and more thinking about the _solution domain_.

And which one does the user care about, again?

<comment><USER21> My point was not clearly made.

I'm not talking about vertical or horizontal, I would put them both in the "technical" category of scaling. I meant to say that scalability is not something that can simply grow to meet a certain load, it is a concept that your system "can survive at scale" in whatever form that scale takes. It encompasses many things like having more servers, bigger servers, more people working on the servers, more users, longer sessions, more activity per user, supports more features, and so on.

It's a semantic point, but it seemed like the author had a very narrow idea of the terms he was using, and was complaining more about his own definitions than the concepts themselves.

And the user cares about all of them, indirectly. They all matter because failing at any one of them are reasons to use something else, whether it's simply slow performance or because your high performance system is so brittle you can't evolve, or downtimes because your high performance, quickly evolving system requires more admins than you can afford, and so on.

<comment><USER22> All well and good.

But you can go a long way -- a _very_ long way these days -- with vertical scaling alone. As Stack Overflow have pretty convincingly demonstrated.

</comment></comment></comment></comment><comment><USER23> You can do it Microsoft way: build Windows as a GUI for DOS, capture many users, earn a lot of money, then pay best developers to develop Windows NT and merge it into a new OS. (user experience first, architecture later).

But you can do it the Apple way: make it good from inside out - <USER3> architecture, wait loooooooong looooooooong until users recognize all this, then get maaaany users and earn lot of money. (Hopefully you have survived until then.)

If you have luck, you can have both: good architecture inside and very good user experience...

But anyway I agree with the author, that many many solutions are over- engineered instead of just simple...

<comment><USER24> what was good about OS9 :-)OK it gave Amiga users a good laugh back in the day.

NT was developed by ex VAX Guys from DEC

<comment><USER25> I believe you was talking about OS X.

<comment><USER24> Nope the poster was comparing Apple Developing Macs with Ms developing NT when MS started with NT Apple was on OS9 and stayed that way for years.

<comment><USER26> > _Nope the poster was comparing Apple Developing Macs with Ms developing NT > when MS started with NT Apple was on OS9 and stayed that way for years._

Nope, the poster was comparing MS from _one era_ (when they developed NT) to Apple from _another era_ (when they developed OS X).

That is, contrasting those two transitions as different ways of building something.

<comment><USER24> oh so comapring two totaly diferent era's then?

<comment><USER26> Yes, the comparison is not about some era (what each company did at the same specified time) but about the methodology (how each company handled a specific transition to a different OS).

</comment></comment></comment></comment></comment></comment></comment><comment><USER27> Here is my simpler version: function calls are the fastest RPCs. They are faster to run, faster to write, and faster to debug if something goes wrong.

By all means conceive of your application as a bunch of well-engineered little pieces. But for now, write them all as modules that you're making method calls to. Should you some day want to, you're free to replace one by a facade around a remote service. But for now it works and you can move on.

<comment><USER28> _you're free to replace one by a facade around a remote service._

RPC rarely lives up to this promise. Starting simple is certainly a good approach, but don't fool yourself about how hard it's going to be when you need to deal with latency and partial failure later.

<comment><USER27> Trust me, I'm fully aware of all of the trouble with getting RPCs to work properly. I still think that it is easier to do that work after you have the original non-rpc version as a reference.

<comment><USER20> Yes, but making those module boundaries loosely coupled and sharing information only through their interfaces will go a LONG way towards enabling you to remote the call at a later date. The biggest mistakes that prevent remoting a module have to do with requiring context that is not part of the interface of the method call (or having a very chatty back-and-forth, but that is less common.)

</comment></comment></comment></comment><comment><USER29> And all that matters is the end user experience. Users don't care how it works as long as it works(according to their expectations).

<comment><USER30> I'm sorry, but that's a platitude.

<comment><USER31> It's also true.

</comment></comment></comment><comment><USER32> My biggest grief is that most of the engineering meetings consist of discussions of how to get a piece of data from one system to another.

Instead of working on things that matter to the user.

<comment><USER33> If you could solve that problem (hint: it is _far_ from being only a technical problem) in the general case, you could be a rich man!

Data always being somewhere else or where it is wanted but not in the right structure to allow practical use, is something we are exposed to a lot by our clients.

</comment></comment><comment><USER34> This isn't so much the symptom of a distributed architecture as it is one of a badly designed distributed architecture.

Distributed architectures are the only way to go once you reach a certain size both in terms of scale and in terms of team size. You can certainly make do without it (Wikipedia) but you'll have a much more robust product with it (Netflix).

The trick is always using the design appropriate for the current needs. It's good to think ahead, but it mustn't come at the expense of the present.

At the beginning—which is the case for most startups, since few make it to the later stages—it's often a good idea to go with a monolithic codebase based on a lean framework. As you grow, you're going to want to start adding components like a message queue for async work, rethinking your data store for scale, etc. As you grow even further, you're going to want to transition to a distributed architecture. I don't know what comes next… I haven't gotten there yet. But I'm sure as you grow even further, your needs are going to change yet again.

</comment><comment><USER35> Joke's on you, I don't even _have_ a startup.

</comment><comment><USER36> Yes. We spent ages before product launch devicing a really solid service that nobody wants, and now make a stream of money from a side-shoot of our main product. Oh well.

</comment><comment><USER37> I'm all for simplifying, but what exactly does he mean by "monolithic architecture" ? Not even sure I get his overall point, the rant seems to go in many different directions.

That phrase "monolithic architecture" makes me think of _one-huge-Java- project_ and that's not exactly "simple" in my mind. Probably not what he meant though..

Generally, I guess separating things is more work and can actually lead to less flexibility when situations arise that you didn't plan for ( _"maybe bloggers should be able to advertise too"_ ). OTOH, _not_ separating can lead to entanglement, where you can't really change anything because other things depend on this or obvious and subtle ways.

(edit: removed dumb example ;)

<comment><USER38> I think this is basically the context for this article: <https://speakerdeck.com/u/kennethreitz/p/flasky-goodness>

</comment></comment><comment><USER39> This seems a bit straw man. "Distributed systems suck because Developer B has to wait for Developer A to add stuff to System A so System B can have a new feature". What you have there is a totally different problem that is unrelated to being distributed or not. Replace the word System with Module and imagine they are in the same codebase, still have the same problem. This post smacks, distributed system are hard and gave us a new set of problems that seem hard, runaway!

</comment><comment><USER40> Side note: I _love_ the fact that there is a COBOL manual in the top graphic in this article talking about over-engineering a software business.

<comment><USER31> You are saying COBOL software tends to be over-engineered? Compared to what?

<comment><USER40> I'm just saying that I love the photo ;)

</comment></comment></comment><comment><USER41> Some counterpoints and cases, anyone? I'm sure many of us would like to hear them. (I'm not at all qualified, just starting out myself.)

<comment><USER42> The article says you should merge all your databases into one, to avoid setting up a service-api-notification-message-queue mess.

While sharing a database lets you develop the initial system quickly, you'll have problems later on because you've made no distinction between your interface (which other people code against and you commit to not changing too often) and your internals (which you may want to refactor from time to time).

So either you make schema changes at will - in which case other developers do too, and you're spending all your time fixing that instead of developing new stuff - or you rarely make schema changes and do it with advanced warning and approval, in which case the pace of development slows to a crawl because other people are too busy to support the changes you want to make.

With well defined interfaces, only the interfaces have to evolve at a snail's pace; the internals can change as fast as you like, as long as you do it without breaking your interfaces.

Example: If you run a amazon style computerized warehouse and an amazon style shopping website; you want to know if an item is in stock. If the website just goes directly to the warehouse's database tables, the warehouse schema can't change without worrying about breaking the website. A nice simple how-many-in- stock web service would be a lot easier to maintain.

<comment><USER32> > A nice simple how-many-in-stock web service would be a lot easier to > maintain.

... yes, _after_ you are doing millions of transactions per month. But until you've actually built a business, there's no point in setting up a web service.

If there's a web service, there has to be a team to maintain it. This means you need to be big enough to have one team per web service.

<comment><USER42> Absolutely - I'm sure you've heard of the idea of technical debt [1,2] and sometimes it makes sense to build up technical debt to get a system off the ground, then worry about maintainability, documentation and whatnot in your copious free time later on.

[1] [http://www.codinghorror.com/blog/2009/02/paying-down-your- te...](http://www.codinghorror.com/blog/2009/02/paying-down-your-technical- debt.html) [2] <http://en.wikipedia.org/wiki/Technical_debt>

</comment></comment></comment></comment><comment><USER43> Agree, but trotting out Google and Twitter's most painful and unattended-to shortcomings, while touchstones, does not support your original thesis.

Furthermore, Google and Twitter aren't startups.

<comment><USER44> Furthermore read onward for some examples from Zemanta itself, which afaik is a startup.

I could also get into the experience I had when using Google App Engine for my startup a few years ago. Horribly over-engineered architecture, nothing worked, had a whole bunch of trouble and everything went all manner of bad to worse very quickly.

But hey, we had awesome scalability! Until we got 200 users and everything started falling apart because of the overhead of keeping all the different parts of the system communicating.

PS: the "saving is taking too long" example is actually aimed at Buffer not Twitter or Google :)

</comment></comment><comment><USER45> Isn't a philosophy like 37signals the answer to this? Simplify the software, reduce the number of "features", resist adding and adding and adding to the application?

Simplifying the software will allow you to simplify the architecture, no?

The stand still and dilemma for Developer A and B stems from a failure to plan and having a road map. I, of course, am assuming both devs work internally at the company.

</comment><comment><USER46> This is bad advice for people who care. Granted, for businessmen it is most import to cash check, but even quick and dirty project slapped together will require rewrite eventually if it take off. And it most likely will be painful and have all kind of subtle bugs.

<comment><USER18> > will require rewrite eventually if it take off

The general advice is that once it takes off, you will have the money and can hire the resources to rewrite it.

And if it doesn't take off, which is most frequently the case, you lose less.

</comment></comment><comment><USER13> Exactly what I needed to read this morning. Thank you.

</comment><comment><USER47> cogs bad...

</comment><comment><USER24> Thats not over engineering just crap design and using the latest toys for the sake of it.

Overengineering is the Victorian egineers way of desiging as they did not have the indepth knowledge we have and so have massive margins of safety.

Of course that means that some of the pre WW2 London Underground tains lasted longer than the ones bought in the 70's.</comment>


Why is Cybersecurity more difficult today than 2 years ago? - <AUTHOR> https://www.recordedfuture.com/cybersecurity-issues-challenges/ <comment><AUTHOR> As an owner of a cybersecurity company, I'll give some thoughts why it seems more difficult.

1) Heightened awareness of threats and insecurity 2) Increasing sophistication of attacks 3) Solution overload without interconnectivity 4) Public access to large data breaches

...</comment>


The paper behind Elon Musk's simulation argument explained - <AUTHOR> http://fermatslibrary.com/s/are-you-living-in-a-computer-simulation <comment><USER2> Direct link to Bostrom's paper: [http://www.simulation- argument.com/simulation.html](http://www.simulation- argument.com/simulation.html)</comment>


Ask HN: What to do if you can't find programmers better than you? - <AUTHOR> So you see all the time people saying you should work with teams that make you feel stupid, have better programmers than you, etc. With people saying once they don't feel like that they move to somewhere better. This sounds like something I want.
However I seem to move from company to company and never experiencing this. I've ended up in charge of all things technical twice. (Out of 4 jobs) I've just moved to one company that is well respected in the community, so much so when people hear I joined they often say congratulations. Yet still, I'm not getting that feeling that I'm surrounded by better developers.
So can you do if you want the challenge of working with really smart developers but seem to have bad luck in finding companies? <comment><USER2> Teach them to be better than you. That may seem counterproductive. I have a type A personality, and I have decent coding skills. I've been in your situation a number of times. I also know there's these mythical expert developers out there that I can't seem to find (or afford). So, what to do? A few years ago I realized that if I continue down this path, I'll end up with some serious health issues due to the stresses that come along with having a reputation for being a really good developer.

So, I decided that instead of searching for developers better than me, I would teach developers I work with how to BE better. It's taken a lot of patience. And it's taken me quite a bit to LET GO of my way of doing things. I had to take my ego out of the picture. (VERY hard to do.)

Nowadays, I realize that developers don't have to BE better than me. I simply have to ALLOW them to do what they do without being so obsessive about it. Turns out, even junior developers really CAN do good work. They just need a little guidance that only comes with experience, and then they need me to get out of their way.

</comment><comment><USER3> Double-check yourself first to be absolutely sure that your perceived level of expertise matches the reality. Sure, it's possible you're the best programmer you've ever met, but double-check.

</comment><comment><USER4> Well there are a lot of companies that currently hire only the best of the best. Try working at companies that have notoriously difficult interviews. I've heard MemSQL, Dropbox, Jane street capital, D.E.Shaw and Palantir are a few of them. These companies tend to hire more competitive programmers (top coder, ICPC etc), who usually have very high IQ. Now, these may not be the best all-round developers but they'll definitely be among the smartest.

</comment><comment><USER5> Find harder problems to solve. I'd expect you'd then be surrounded by smarter people.

</comment><comment><USER6> Venkatesh Rao wrote a good article on this recently.

[http://www.ribbonfarm.com/2014/11/05/dont-surround- yourself-...](http://www.ribbonfarm.com/2014/11/05/dont-surround-yourself- with-smarter-people/)

</comment><comment><USER7> I thnk it's to better to join big companies like google, ibm, oracle, etc.

<comment><USER8> I'd be wary about that advice. Sure, the companies you mention have elite teams of super smart people, but they have lots of programmers as well, so many must be average. End up in the wrong team and nothing changes (except, you get a good pay and a good name to put on your cv).</comment></comment>


Ask HN: Does anyone here actually want to get an MBA? - <AUTHOR>

Or, if you already went to business school, why? Do you think your degree helped you run your business/startup/company more effectively? Do you believe you could have acquired the skills you got in B-school that you couldn't have acquired "in the wild"? <comment><USER2> HN is very anti-MBA. Frankly, that's because the anti-MBA set don't have MBA's and lack an understanding of what an MBA is all about.

An MBA will:

...introduce you to many, many smart, helpful, agressive, motivated people. Hundreds of them. And you will have two years to go drinking with them, travel the world with them, and get to know them. That alone is extremely valuable. There is a bond of shared experience that is unobtainable by "reading books".

...make you smarter about the worlds of big business and finance. This classroom stuff is _mostly_ available in books. Mostly. But are you really going to read them? Finance is not the hardest thing I've ever learned, but having a few classmates and professors who had been investment bankers and money managers is a good thing.

...be really, really fun and educational, just not in the way you're thinking.

An MBA will not:

...prepare you for a startup. The tech business has a lot to it that just isn't taught in B-School. You'll have to learn that on your own like everyone else.

...prepare your for a career in big business. EVERY business has a lot to it that just isn't taught in B-School. You'll have to learn that on your own like everyone else.

...fast track you to wealth. Business school is expensive these days. You'll be broke for a while as you recover unless you're really, really lucky.

...turn you into an asshole. Assholedom takes root at a much younger age.

Is it worth it? For me, it's an unambiguous "HELL YES".

In perhaps the funnest two years of my life I managed to:

travel to 7 countries

play rugby with schools from around the world

learn more than I ever imagined about finance.

learn less than I would have thought about marketing.

meet many of my best friends, including several startup CEOs.

meet my wife.

watch my school win a national championship in football.

drink more than is healthy.

see some _really_ smart people do some _amazingly_ dumb and wonderful things, sometimes simultaneously.

and that's just the stuff that comes to mind now. A fantastic experience overall.

</comment><comment><USER3> I think for a lot of people Business school tends to serve the same as a startup incubator serves for small companies. You do not go to business school because you cannot learn it unless you go, you attend so you can learn it in a controlled environment without making too many mistakes along the way.

In many ways this is similar to incubator programs for these companies, lots of these companies were going to succeed or fail whether or not they went through these programs, others were probably on the cusp without it and with it they will flourish because of the impact of being around bright people with good ideas and lots of feedback.

Business school helps lots of people. But it is not for everyone. Some will benefit more than others because they need structure. Those types of people likely will not be the ones running a company some day. If you need structure being an entrepreneur simply put, probably is not for you. It's a scary ride full of ups and downs, twists and turns and lots of bumps along the way, but it can be one of the most rewarding things you'll ever do if you stick with it.

There is a lot to be said for those people who go through business school then go on to become great business people and entrepreneurs ... first of all they have patience and vision. They are usually working toward a goal and they have carefully planned out how to reach it. Sometimes those plans work and other times they do not, but either way in most of those cases those were the people who were already destined to become great.

To be an entrepreneur is in your blood ... for the people who have started a company and one day said to themselves "Why would I ever work for anyone other than myself" they know exactly what I am talking about. You have to be able to be stubborn enough to know when to not give up but realistic enough to know when to cut your losses and move another direction.

The only difference between a successful business man and a failing one is time ... the more time you put into something the more likely you are to succeed. Being wise helps, being conservative with spending is even better, but being willing to go without is what truly makes good business people great, while they do not teach that in business school if you read about the great entrepreneurs of all time that is one thing they almost all have in common, and that, is one thing that can never be either learned nor taught.

</comment><comment><USER4> The company where I currently work, which is highly successful (ranked 9th fastest growing software company by Inc 500 last year) has a management team filled with PhD's, MBA's, and Management Consultants.

Some ways in which the MBA/Management Consulting mentality has really helped the company:

-Extreme customer focus. HN talks a lot about knowing your customer, but the management here takes it to a much higher level. The exacting level of detail of how well they understand users, as well as the amount of time/money they're willing to invest in training their employees to understand their customers is astounding, and pays in spades.

-Really good Sales/Marketing

-Since we started out with consulting, the company has always been profitable, and always had a very clear line of sight as to what brings in the money

-Very well thought out, long term strategy. The company has the next several years planned out, yet the strategy is flexible enough to take into account new technological innovations, data from customer responses, and even new exceptional employees

-Very well done hiring. I haven't met anyone at the company I would consider stupid-in fact, I haven't met anyone I wouldn't consider smart

-Excellent resource management...even as the company has grown money and people are assigned to the projects that consistently provide the most leverage, rather than being tacked onto the emergency of the day

Now the MBA/Management Consulting strength is not the only thing that has allowed the company to succeed-we are roughly 60% hackers and our CTO is absolutely phenomenal. But having management with such strong business skills is a MASSIVE force multiplier.

<comment><USER5> _-Very well thought out, long term strategy._

Probably HN unrelated but: I would love to hear more about that and how this is actually turning out. From my perspective the whole Strategic Planning thing has come under severe attack at least since Mintzberg's Rise & Fall of Strategic Planning. And if I remember correctly from reading the Lords of Strategy even Porter has grown more skeptical on Strategic planning in the long term. Would love to see how this is turning out in practice/is implemented/realized at your company.

</comment></comment><comment><USER6> My wife has an MBA from a top university so I can speak to this from some experience.

I think an MBA still provides value for those looking to take established startups and turn them into viable, Fortune 500 businesses. These are the folks that become the "adult supervision" during the later stages of a company as it approaches that mid-market sweet spot and starts trying to become a large cap public company. There are areas around finance, operations, and strategy where the MBA still provides a lot of value.

You can certainly learn those things on the job if you decide to stay at a startup beyond the early stages. But it carries a bit more risk and mistakes can be a lot more costly.

I don't think most of the crowd here is all that interested in working at companies during these later stages, hence the strong anti-MBA sentiment you see in a lot of HN posts.

The biggest problem, I think, is that there are now too many folks with MBAs that are skilled only for the later stages of the company. These folks often lack the raw talent needed to succeed in the early stages and get a company off the ground.

</comment><comment><USER7> Yes, I do.

I have multiple startups with varying levels of success since I was 16, and its extremely evident to me thats its not just what you know, but who you know as well. I think an mba from a top-tier university will help me open some of the doors I want to open in my career.

</comment><comment><USER8> Half of our company is made of MBA's. Getting an MBA is very different from doing a startup. If you want to do a startup, do a startup. However, there are useful things you can learn from an MBA. Here's why we like them: [http://feefighters.com/blog/should-you-hire-mbas-at-your- sta...](http://feefighters.com/blog/should-you-hire-mbas-at-your-startup-and- why-we-love-them/)

<comment><USER9> MBAs have a place in businesses, but most of the good points argued are just as easily (if not better) argued for engineers. Good engineers are way more analytical than MBAs (that's what they do!), and good engineers are often more ambitious and driven than the average MBAer.

Most of the successful MBAers I have met are actually engineers who have had a company pay for them to get their MBA to 'traditionally promote' them to a higher position in said company.

In my opinion MBAs are like glue that hold a company together, the glue is absolutely critical for the company but you also don't require an army of it.</comment></comment>


Dorothea Lange's Censored Photos of Japanese American Internment Camps (2017) - <AUTHOR> https://anchoreditions.com/blog/dorothea-lange-censored-photographs <comment><USER2> "The very fact that no sabotage has taken place to date is a disturbing and confirming indication that such action will be taken."

— General John L. DeWitt, head of the U.S. Army's Western Defense Command"

Could be straight out of Catch-22

<comment><USER3> Reading that statement horrified me and sent me back here to comment on it.

There was literally nothing these people could've done to prove themselves. If authorization were granted to fully exterminate them, this person would've gladly run with the order.

As terrible as this whole time period in American history was, it's even more terrifying to think of just how close it came to being even worse. And it all would've been justified and swept under the rug, and instead of being given a half day of US history class as a passing mention of "yeah bad things happened but it won't happen again", maybe given 2 days of study and a "we definitely learned to not do that again".

<comment><USER4> Your speculation of what America was close to doing to Japanese Americans sounds much like the quote you are commenting on.

</comment></comment></comment><comment><USER5> What do US schoolteachers assigning _The Diary of Anne Frank_ say about it, these days? When I was in middle school you could say things like "concentration camps are bad" and "hiding persecuted people in your attic is good" without much fear of controversy, and also without much fear of applicability to the present day. Are they still saying that?

<comment><USER6> >"What do US schoolteachers assigning The Diary of Anne Frank say about it, these days?"

As a depressing guess, unless they are still working off the censored edition, it may well be something along the lines of; _' This reading material is unsuitable due to lesbianism, we must remove all editions from the school library immediately!'_

</comment></comment><comment><USER7> Were ethnically German Americans put in concentration camps too? There far more people of German heritage in the US, Col Schisskopf from Catch 22 for example

<comment><USER8> Race is a factor. After the camps were initially liberated prisoners became "displaced persons". Obviously, they were treated better than under the Nazis but many were held in the same camps for years after the war.

This is from Patton's journal...

"Harrison and his ilk believe that the Displaced Person is a human being, which he is not, and this applies particularly to the Jews who are lower than animals,"

We have so mythologized our victory in WWII that's our mistakes and failures don't really exist for most people. We were only noble. We were only brave. We were only just. It's way more complicated.

<comment><USER5> I'm reminded of this story of a man who was sent to the concentration camps for homosexuality, only to be imprisoned after the war for the same offense by the same judge: [https://twitter.com/holocaustmuseum/status/11371006966066954...](https://twitter.com/holocaustmuseum/status/1137100696606695424)

</comment></comment></comment><comment><USER9> It's genuinely horrifying to see examples of this sort of thought emerging again into the public sphere in the West.

</comment><comment><USER10> David Suzuki [1] the Canadian environmentalist talks about his time in concentration camps.

[https://www.youtube.com/watch?v=Y2FD0DoHiK0](https://www.youtube.com/watch?v=Y2FD0DoHiK0)

DS: I don't like to look in the mirror at myself.

BM: Why?

DS: When I look at myself I see the slit eyes, the face that was for four years during WW2 depicted as the enemy.

DS: And it was my enemy too! That face was my enemy because I was a Canadian. And we wanted to go out and kill Japs.

...

BM: Were you bitter or your parents bitter? [3]

DS: I think if one broods on this and becomes bitter and hateful, then ultimately the bigots win, you become them.

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

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

[3] [https://youtu.be/Y2FD0DoHiK0?t=117](https://youtu.be/Y2FD0DoHiK0?t=117)

</comment><comment><USER11> The real reminder is to be aware that under the "right" conditions most people would actively or passively support such things being done to their fellow human beings. The reminder is to be wary of setting the stage for those conditions to materialize.

</comment><comment><USER12> A reminder of how Freedom is often a very flimsy thing in even in First world democratic countries.

</comment><comment><USER13> If you are habitually detaining large numbers of civilians, including children, then you are on the wrong side of history.

Somehow this point never seems to be learned

</comment><comment><USER14> > This government can never repay all the people who suffered. But, this > should not be an excuse for token apologies. I hope this country will never > forget what happened, and do what it can to make sure that future > generations will never forget.

Every school system has succeeded in whitewashing the history. Almost no one in America now knows about the camps

<comment><USER15> >Every school system has succeeded in whitewashing the history. Almost no one in America now knows about the camps

That's not true. The internment of Japanese Americans in WW2 is taught about in school, and almost everyone knows about it, although not everyone necessarily cares, and some Americans will defend it (and even suggest that maybe doing it to Muslims would be a good idea.)

The US doesn't really "whitewash" its history, nor practice mass indoctrination or nationalist brainwashing through its educational system, to the degree some believe. Learning _about_ our history, and learning _from_ our history, are two different things, though.

<comment><USER3> I think part of this depends on the school. The ones I attended would completely skip sections regarding the ~1,000,000 civilian deaths during the Philippine American War, the blunders in Korea and Vietnam (my classes basically said "they happened" and then the rest of the year was Civil War and WW2 movies), and there was absolutely zero discussion of American affairs in Central/South America and events leading to the Middle Eastern situation today.

Schools and teachers aren't 100% standardized in America. Some have thorough history programs. Some absolutely do brush over a lot of bad parts in history, and my high school in the South was one of the types to say "The Civil War had nothing to do with slavery." Our biology class also had a huge disclaimer about evolution and how nobody had to, or really should, believe it, but they were just required to teach it.

So I think when some people talk about how ridiculous/amazing the school system is, it's because that's just their experience. Schools are completely different depending on what state or even what part of town you live in.

</comment></comment></comment><comment><USER6> Here's the conditions of the current ones;

> _The Trump administration argued in front of a Ninth Circuit panel Tuesday > that the government is not required to give soap or toothbrushes to children > apprehended at the U.S.-Mexico border and can have them sleep on concrete > floors in frigid, overcrowded cells, despite a settlement agreement that > requires detainees be kept in "safe and sanitary" facilities.

>All three judges appeared incredulous during the hearing in San Francisco, in which the Trump administration challenged previous legal findings that it is violating a landmark class action settlement by mistreating undocumented immigrant children at U.S. detention facilities.

>"You're really going to stand up and tell us that being able to sleep isn't a question of safe and sanitary conditions?'" U.S. Circuit Judge Marsha Berzon asked the Justice Department's Sarah Fabian Tuesday.

>U.S. Circuit Judge William Fletcher also questioned the government's interpretation of the settlement agreement.

>"Are you arguing seriously that you do not read the agreement as requiring you to do anything other than what I just described: cold all night long, lights on all night long, sleeping on concrete and you've got an aluminum foil blanket?" Fletcher asked Fabian. "I find that inconceivable that the government would say that that is safe and sanitary."

>The settlement at issue came out of Jenny Lisette Flores v. Edwin Meese, filed in 1985 on behalf of a class of unaccompanied minors fleeing torture and abuse in Central America.

>Finally agreed upon in 1997, the settlement established guidelines for the humane detention, treatment and release of minors taken into federal immigration custody. The guidelines include the right to a bond hearing and requirements that immigration authorities timely release children to parents or guardians and place those not released in facilities that meet certain standards. The facilities are supposed to be "safe and sanitary."

>The settlement landed back in court in 2015, when class members moved to enforce it following the Obama administration's announcement that it would scrap bond hearings because they conflicted with newer immigration laws. In legal filings, the class contended the elimination of bond hearings and dirty and dangerous conditions at short-term holding facilities operated by the Border Patrol violated the agreement.

>U.S. District Judge Dolly Gee in Los Angeles granted the class' motion and ordered the appointment of an independent monitor to ensure government compliance with Flores.

>Gee said the administration had breached Flores by failing to provide detainees with adequate food and clean drinking water, or with hygiene items like soap, toothbrushes and towels. She also concluded that the children were being deprived of sleep and access to bathrooms, and were subjected to near- freezing temperatures.

>The Ninth Circuit affirmed much of Gee's ruling in July 2017, finding that detainees were still entitled to bond hearings.

>On Tuesday, Fabian asked the Ninth Circuit to reverse Gee's findings because they added new requirements – such as giving detainees soap and toothbrushes – that were not specifically included in Flores.

>"One has to assume it was left that way and not enumerated by the parties because either the parties couldn't reach agreement on how to enumerate that or it was left to the agencies to determine," Fabian said.

>"Or it was relatively obvious," Fletcher shot back. "And at least obvious enough so that if you're putting people into a crowded room to sleep on a concrete floor with an aluminum-foil blanket on top of them that it doesn't comply with the agreement."

>"It wasn't perfumed soap, it was soap. That's part of 'safe and sanitary.' Are you disagreeing with that?" he added.

>Class counsel Peter Schey said that, although Gee had listed specific items such as toothbrushes in her order, which were not listed in the settlement, settlement compliance must be analyzed in terms of California contract law, under which the general terms in an agreement must be "reasonably interpreted."

>"The first thing you do is honor the plain meaning" of words like "safe" and "sanitary," Schey said.

>"Today we have a situation where once a month a child is dying in [federal] custody," he added. "Certainly the Border Patrol facilities are secure, but they're not safe and they're not sanitary."_

[https://www.courthousenews.com/feds-tell-9th-circuit- detaine...](https://www.courthousenews.com/feds-tell-9th-circuit-detained- kids-safe-and-sanitary-without-soap/)

<comment><USER16> In fairness, it should be noted that all four of the referenced judges are Democrat nominees (Gee:Obama, while all three judges on the panel were Clinton nominees).

<comment><USER6> In fairness, this is about access to things like soap. Party really shouldn't matter here. Unless you are saying that if they were Republican nominees, they would have no problem with child detainees not having soap?

</comment></comment></comment><comment><USER17> Before you all jump to the condemnation of Americans, Think. It was warfare. I'm Australian and one of my ancestors spent some time as a prisoner of Japan on the burma railway. I might add Japan had no Americans on it's soil during ww2.

<comment><USER18> Well, if your country is much stronger, has no real possibility of being invaded, no real possibility of being bombed, and interns 2nd and 3rd generations of immigrants, maybe your country is just paranoid and racist.

<comment><USER19> The entire American condition is held together by paranoia. If there isn't a credible external threat then it turns on itself:

The idea of a soviet expansionist theory that actually impacts the US is laughable to enough of the population

Nobody powerful actually believes the teachings of Karl Marx except to placate their internal public

People kind of seem to understand that interference in the middle east creates danger from very specific people who dont represent everyone, not really protecting us from anything

so now that paranoia leads us to ideological introspection, in the absence of a common enemy</comment></comment></comment>


Fighting to Keep Linux on PS3 - <AUTHOR> http://arstechnica.com/gaming/news/2010/03/hacker-vows-to-fight-sony-ps3-update-restore-linux-support.ars

<comment><USER2> This is definitely in response to the geohot hypervisor exploit. When they say "security update", they mean they're addressing a threat to their profit model. Pirated games and cheat modes for network play will be coming out in the future. The more Sony slows that down, the more revenue for both them and game developers.

What's interesting about this is that there is a good argument to be made for the availibility of Linux keeping hackers from showing much interest in the PS3 for a while. They may have bought their ~3 years of no piracy by providing Linux support. The other thing they did well was closely integrating the drive firmware with the core OS security, something Microsoft did not do with the Xbox360.

I previously wrote up a technical description of the exploit below. The comments section is pretty interesting as well.

[http://rdist.root.org/2010/01/27/how-the-ps3-hypervisor- was-...](http://rdist.root.org/2010/01/27/how-the-ps3-hypervisor-was-hacked/)

<comment><USER3> Why is it "definitely", besides the curious timing?

<comment><USER4> Because in an interview late last year (no link handy, sorry), Sony reiterated its commitment to Linux on PS3. Why would they pull a 180 within months of making that announcement?

</comment></comment></comment><comment><USER5> I think the geohot hack is just a red herring given that the PS3 Slim was released months before this hack happened and that it had no provision for Other OS installs. It is still terrible that this happening though.

<comment><USER6> I wouldn't be surprised if removal of Other OS support was purely a cost- cutting device. There could easily have been some component they removed, or some part they downgraded, that allowed Linux to run on the PS3 Fat. Alternatively, it could be the Slim would have needed new drivers, and they didn't want to deal with that.

</comment></comment><comment><USER3> It's interesting that Linux support is being withdrawn months after Linux was used as part of a memory exploit to break the PS3 security. PS3 machine owners could ask who owns the machine in their front room.

<comment><USER7> _PS3 machine owners could ask who owns the machine in their front room._

They own the machine. They do not own Sony's firmware.

<comment><USER3> Today, it seems, that others don't really see it that way either: <http://techdirt.com/articles/20100331/0128358800.shtml></comment></comment></comment>


Chika's Test (For Divisibility by 7) - <AUTHOR> https://www.westminsterunder.org.uk/chikas-test/ <comment><USER2> The link to the proof is [https://www.simonellismaths.com/blog/new- maths](https://www.simonellismaths.com/blog/new-maths) (the link in he article says "post" instead of "blog"). It's standard modulo arithmetic, but it's nice to see a rediscovery by a kid.

</comment><comment><USER3> Fun story showing how it's more fun to find things in math than just be told them. I think if more people had this kind of experience there would be a lot less hate on math! I have to say I like the subtraction method mentioned more though, both sides of the number end up staying smaller making it quicker to converge and calculate.</comment>


Tilt – Local Kubernetes development with no stress - <AUTHOR> https://github.com/windmilleng/tilt <comment><USER2> I think the docs kind of misses what problem it solves and how it solves it. I do all the local stuff with docker-compose while using the same images for k8s deployments, how does this help me? Does this aim to replace docker-compose with k8s, or is this just for testing k8s resource changes in realtime, or is it testing your local k8s resource definitions against a remote cluster? Obviously this is useful for some people, I would like to understand what problems this project adresses and how it adresses them.

Also, doesn't not reusing the k8s definitions and re-defining them in a tiltfile cause yet-another-config-to-manage, which can quite easily digress from the production resource definitions, which is one of the problems using docker-compose for local development and k8s for deployment? I would really like to read the problem and proposed solutions in a detailed documentation page. I might have missed it if there is already one, please correct me if so.

<comment><USER3> Hey, I'm CEO of Tilt. Thanks for the feedback.

The problem this solves is that distsys devs don't get enough feedback. You say you use docker-compose. Compared to docker-compose, Tilt has two advantages: 1) It updates the services as you edit them 2) Its UI makes it easy to see where errors are occurring, without you having to play 20 questions on the command-line or worry about things scrolling off-screen.

The Tiltfile doesn't redefine your k8s definitions; it reuses your existing k8s definitions. The Tiltfile just tells Tilt how to get them. (Many teams don't just use yaml files, but generate them, so Tilt has to be able to do that, too.)

There is a landing page at [https://tilt.build](https://tilt.build) which has more of the "why Tilt". Also, we're adding native support for docker-compose next week. I'd love to understand your case more, because at a high level you sound like exactly the kind of dev we want to help.

<comment><USER4> > _There is a landing page at[https://tilt.build](https://tilt.build) which > has more of the "why Tilt"._

As a tangential by-the-way, I notice you're based in NYC. Of interest, Googlers working on Knative Build (hi Jason!) and Pivots working on Cloud Native Buildpacks (including me) are based in NYC also.

<comment><USER5> Dan himself used to work at Google NYC...

</comment></comment></comment></comment><comment><USER6> Hey, awesome!

I met the Windmill Eng team a few weeks ago at Kubecon in Seattle, awesome to see tilt here. It's definitely a young product, but it's a good start to exactly the experience I want.

By experience I mean that when I do local dev and edit code live while reloading or restarting the service, I see changes reflected immediately in 2-3 commands that take seconds.

In moving software towards Kubernetes, I come to rely on the service abstractions available therein. So it's sensical to develop in the same kind of environment. Tilt gives me the ability to get the save => build => package => push => reload loop into Kubernetes and without the manual hassle thereof.

I've used it in minikube, on-prem, and GKE. Running a dev box in a GCE instance and running tilt against GKE is a super nice environment.

(Fair notice: I'm a Googler who focuses on GKE, so bias and all, my opinions are not Google's, etc.)

<comment><USER3> Thanks Frank! It was great to chat at Kubecon. (I'm Dan, the Windmill CEO, goofy big-haired guy)

</comment></comment><comment><USER7> Uuuuh not using YAML. Controversial. (in the docker/k8s ecosphere, where YAML seems ubiquitous)

I don't love YAML though I am not sure Starlark looks any more readable.

YACL => Yet another config language...?

<comment><USER8> YAML, especially how it's used in k8s, is terrible. Writing it by hand is mind-numbingly toilful and extremely error prone, and templating YAML with Go (like Helm does) is a travesty.

The most sensible approach I've seen is to use jsonnet+kubecfg. This lets me use a somewhat sane, composable, turing complete language that spits out a tree of k8s objects. I can use as much or little repeated definitions (or abstractions) as I like. Then kubecfg performs all the kubectl invocations to actually make the cluster state match my calculated definitions.

<comment><USER9> I don't see how Starlark is better... Does it validate what you write somehow - in a way that couldn't be done by validating a YAML?

<comment><USER8> I don't understand, I'm not talking about Starlark..?

<comment><USER9> Meant to reply to the comment, sorry :)

</comment></comment></comment></comment></comment><comment><USER10> It actually uses your existing Dockerfile and existing k8s yaml definitions contrary to what some people are saying in the comments,the Tiltfile seems to be just a handful of glue logic. The logs ui is pretty nice too, I've definitely looked for an easier way to check logs from multiple running pods.

</comment><comment><USER11> Seems like this is the main product of a full-time startup. In that case, I am curious how are you thinking about the future and business model considering it is 1) open source and 2) many competitors.

</comment><comment><USER12> How does this compare with garden.io, skaffold, draft, microk8S etc???

<comment><USER3> Hey, Tilt CEO here, so I'm certainly biased, but also semi-informed.

We think you deserve three properties: 1) it's easy to start your whole app 2) it's fast to update your app as you edit 3) common problems can't be missed.

docker-compose gives you 1. (some people hack in mount points and file watching to get 2, but it's hacky)

skaffold and garden.io give you 1 and some of 2. (Tilt has fast_build, which can update pods in-place, without rebuilding the whole image, which I don't believe either skaffold or garden.io do)

Our big value-add is the UI. Which may sound weird for a Terminal UI, but if you look at the demo video on [https://tilt.build](https://tilt.build) , I think you'll get a sense for how Tilt is working to keep _the_ problem that's blocking you in your face, so you don't waste time playing 20 questions with kubectl.

<comment><USER13> Hi all, Garden CTO here. First of all, great job on Tilt! A lot of interesting stuff happening in terms of DevEx in the multi-service realm.

I just wanted to chime in on the points above. Regarding 2), Garden does indeed support updating pods without re-building and re-deploying via our hot- reload feature ([https://docs.garden.io/using-garden/hot- reload](https://docs.garden.io/using-garden/hot-reload)) which essentially copies source files into the running container on file save (works best for dynamic languages).

Regarding 3), Garden has a terminal UI that shows the status of individual services and updates as changes are made to the codebase. It will for example print error messages for failed container builds and failed deployments. If configured so, Garden can also run tests on code changes and will print the error output if tests fail. Our next release will also contain the first version of a dashboard which displays service statuses and dependency graphs and updates in real time. However, our terminal UI is not interactive like Tilt's—which looks really nice!

</comment></comment></comment><comment><USER14> I love the name, especially considering that the GitHub username is 'windmilleng'.

(if you don't get it, look up Dom Quixote)

</comment><comment><USER15> How does it compare with Telepresence + skaffold ?

I like the console UI idea.

I dislike the server components (the same way I dislike draft and tiller).

</comment><comment><USER16> In the readme there's a link to kubernetes slack. Anyone know how can I get an invite to join the workspace?

<comment><USER3> [http://slack.k8s.io/](http://slack.k8s.io/)

</comment></comment><comment><USER17> is there anything working with helm in the similar way ?

<comment><USER12> there is also garden.io

<comment><USER18> Tell me you don't work for them...

</comment></comment></comment><comment><USER19> My biggest problem with local k8s dev is building containers. I'm on macOS. Does this solution address that?

<comment><USER20> Is the problem with building containers that you don't have a Dockerfile and you don't want to spend time making one?

Draft does that pretty well with Draftpacks, in my experience if there is a Draftpack for what you're using then the Dockerfile that draft spits out will get you pretty close to a workable container image with basically no effort, or sometimes even all the way there.

I'm trying to understand what you mean that building containers is a problem. Is it the procedural act of actually building and rebuilding the container that is the problem? (Draft handles that too...)

Edit: According to the Tilt tutorial, yes, tilt will build your containers. Eg: [https://docs.tilt.build/first_config.html](https://docs.tilt.build/first_config.html)

<comment><USER19> I'm all aboard Docker, but I don't use Linux natively, so I'd need to run a VM inside macOS, or have another box to build containers. Even if I did, I use GCR in production, so I'd need to template my container images in helm to use GCR only in production versus whatever I use locally for development. And what would that even be? I haven't explored minikube to know what it does for local dev container registry.

Anyway, thanks for the link. Missed that.

EDIT: Looks like tilt is using GCR in those examples. I'm not trying to traffic container images off of google cloud for local development. That requires (fast) internet just for local development, and outgoing traffic really adds up quickly in terms of cost.

PSS: never heard of Draft. Checking it out now. Not using azure though, maybe that's not relevant.

<comment><USER21> Sounds like you should try skaffold, it has a workflow for local builds, with fast hotloading to auto-rebuild your image. It also redeploys automatically too. If you're using Minikube it'll share the docker daemon so that you don't have to push anything anywhere.

I find Docker for Mac to be completely fine, and Minikube can be a resource hog, but still workable if you make your resource allocations configurable (i.e. don't request 1G for each pod in your local env, even if you need to do so in prod). There is an xhyve driver for Minikube that should reduce the footprint by not requiring you to run virtualbox.</comment></comment></comment></comment>


Dwarf Fortress has a Patreon - <AUTHOR> https://www.patreon.com/bay12games

<comment><USER2> What are the top patron sits out there at the moment? Are there any focussed on people doing good in the community as opposed to just for the "arts"?

</comment><comment><USER2> What are the top micro-patronage sites out there at the moment?

Are there any focussed on people doing good in the community as opposed to just for the "arts"?</comment>


Ask HN: Why is academic language so redundant? - <AUTHOR> I've recently started reading a number of papers in the field of cognitive psychology, and I'm fairly new to reading things written in academic language.
One thing strikes me as odd is how much redundancy and complexity is in those statements. Qualifiers that cancel each other, sentences that mean little (e.g., "We may have to consider all important aspects"...why wouldn't you?), nested layers of negation ('Most unlikely not  un-important'), and statements rephrasing the statement before it just slightly.
Since I'm not an academic, and I don't write papers, I'm wondering, is there a purpose for this (e.g., "papers must be written defensively to be published, ergo they must make everything explicit"), or is it just authors' linguistic tomfoolery?
Another thing that interests me is whether this is true for all fields, or whether there's differences in clarity of writing between them? <comment><USER2> There are multiple reasons.

It's hard to write up a scientific report, and condense all the thing you want to say, and get the details and nuances correct.

It's also hard to write well. Look at all the people who go to classes and workshops to become better authors, and that's for a field where you might get paid if you write well. But "able to write well" isn't one of the things likely to give tenure or a promotion.

There are innumerable papers urging scientists to become better writers. But why should they? Where's the real pressure to also include the writing quality as a way to judge a paper.

"Oh, I'm sorry Herr Turing, but your paper on computability isn't up to our literary qualities. We recommend you work with a ghostwriter or writing coach."?

And yes, some papers do get that response, but it's rare, and mostly for non- native speakers who don't know the journal's language that well.

Then, yes, there are people who write that way because they believe that stilted and opaque language is the correct style.

Or there's the Sokal affair, where a journal accepted "an article liberally salted with nonsense".

On the other hand, you are also not the expected audience. While this isn't related to the quotes you gave, in general it takes time to know what everyone in the field is expected to know. Many of the dense or complex parts might be built on ideas that the expected reader will understand, but you might not. Or from the other perspective, I've read papers where the author goes on and on about some basic idea, and I'm mentally yelling "get on with it!"

You might try reading papers from Science or Nature, often available in print form at a good city library or local college library. Those are both cutting- edge and often clearly written.

<comment><AUTHOR> > Where's the real pressure to also include the writing quality as a way to > judge a paper.

I think it's really a thing between necessary complexity and unnecessary complexity. Unnecessary complexity makes papers harder to read. I'll hypothesize being harder to read makes you harder to cite. A final, due- diligence editing pass to simplify statements and catch errors should not take very long.

> Then, yes, there are people who write that way because they believe that > stilted and opaque language is the correct style.

That is what I'm getting at. Some of the papers sounded like they were written to hit a page-count (well, i assume college does train that style). They were organized well, but the writing seemed like there was actual effort put in to jumble things up. Lists of similar statements ("A1 does A2, B1 does B2, C1 does C2") jumbled up to provide variety ("It is shown that A1 does A2, B2 is done by B1, C1 does C2"). It is harder to write and read.

Redundant statements are like unsimplified fractions. They bother me.

> It's also hard to write well.

It is. Not asking for a gripping paper.

Thing is, imagining the paper to be a hierarchy, the top level structure is usually fine, but at the sentence level, things break down. There are needless permutations and additions. Unnecessary permutations can be resolved by looking at statement relations (similar things should look similar). Unnecessary additions can be removed by examining whether words are necessary, once their context is known.

It's just rubbing my min-maxer heart the wrong way. It makes taking notes harder due to parsing difficulties.

<comment><USER2> You have little to no experience in writing a scientific paper, little experience in reading papers, and I don't know your field or if you're reading bottom-tier papers or high quality papers.

I'm therefore not sure what to make of your response. Is it just a complaint to the universe or do you want something specific?

Because I can complain about crappy papers until the cows come home. But that's a well-worn story that doesn't interest anyone. Even me. _Everyone_ complains about it. Here's a 1962 paper in my field on the very topic: [http://pubs.acs.org/doi/abs/10.1021/c160006a001](http://pubs.acs.org/doi/abs/10.1021/c160006a001) . Here's a book on the topic: [https://www.amazon.com/Writing-Science-Robert- Goldbort/dp/03...](https://www.amazon.com/Writing-Science-Robert- Goldbort/dp/0300117930) . Here's a cartoon from PhD Comics: [http://www.nature.com/scitable/ebooks/english- communication-...](http://www.nature.com/scitable/ebooks/english- communication-for-scientists-14053993/writing-scientific-papers-14239285) (or see [http://www.phdcomics.com/comics/archive.php?comicid=405](http://www.phdcomics.com/comics/archive.php?comicid=405) for a translation guide; PhD comics touches on this topic often).

<comment><AUTHOR> Complaint to the universe mostly.

I do have very little domain knowledge. The thing that vexes me is that the "errors" made are consistent across the papers I've been reading. Most of them are in the Cambridge Handbook of Expertise and Expert Performance, which is a collection of 40 odd papers trying to lay down the foundations of the field, so I'll go out on a hunch to say that these are decent papers from a reasonable subset of authors across fields (sociology, ethnography, expert systems, cognitive psychology, etc.).

Now if the issues are consistent, there must be reasons they crop up again and again. It could be that there's a good underlying reason I'm missing. It could be that the academic environment trains people to write papers in this way. It could be that it's just the papers I've been reading that exhibit these issues. It could be that the difficulty of writing academically causes people to write in this manner. Without domain knowledge, I just cannot tell, but I would like to know.

For example, as a specific issue which is understandable to me, putting clear statements in question ("the sky may be blue"). Statements need to be defensible, strong statements are hard to defend, ergo authors resort to qualifying everything as 'potentially'.

A specific issue that is hard to understand for me is obfuscating similar statements. Semantic meaning is retained, but the parse tree looks different. The statements have clear relation (A->B B->C, or A->B, C->D,...), and obfuscation is more work than just writing out their relation. Why then, do authors do that?

My questions were roughly, "Are there writing issues in most academic papers?" (Seems like yes), "are these specific recurrent items issues, or conscious decisions? If they are issues, why do they arise? Is they are conscious decisions, what motivates them?".

Sorry if it's bothersome, but since I'm a relative novice, my questions aren't necessarily clear. Maybe I'll have a chance to get an answer for some of the other questions later on as I'm more experienced. Thank you by the way.</comment></comment></comment></comment>


How our SaaS startup got 1000+ signups in just 7 days, without getting Crunched. - <AUTHOR> http://blog.groovehq.com/post/8471578393/how-our-saas-startup-got-1000-private-beta-signups-in <comment><USER2> Since the design and consistent integration of design components throughout the app,site,etc was so important. I hope future posts will include screenshots and some examples.

Also, I admire the way you guys use twitter and other social media to leverage your userbase. Indirectly causing your users to vote up you HN story for example. sort of win-win in that you get more exposure (and maybe more signups); I learn about an interesting new company; and your users feel like they're helping you out. (With the ongoing cascade that now they are more likely to do you favors, they feel more like a distinct community, etc)

</comment><comment><USER3> I see no _evidence_ that those 1000 signups can be attributed to your pretty design. In fact, I dare say you held the belief that design was important long before the product release, which is why you invested your time in it. Perhaps it was the particular domain or the viral marketing.

Conclusions without evidence is just conjecture and supposition.

</comment><comment><USER4> Loved the post, but as a programming single-founder with next to no design sense (I would design something like HN) this article makes my checkbook cry blood.

I suppose it makes sense that your design suggests to people if they should invest time in your idea because _you_ invested time into it.

Seeing it in writing helps drive the point home.

Also, big congrats to the Grove team, the site and product really do look beautiful.

<comment><USER5> We are in an age where even ramen-lovin' back-end programmers with no design talent (like myself) have no excuse for ugly web designs.

Thomas and I chat about this periodically. For about $15, an hour of browsing ThemeForest, and half a morning with 960.gs and Compass/Sass/whathaveyou, you can make any throwaway app look like it had someone with actual design talent touch it.

[http://themeforest.net/item/simplpan-admin-panel- template/fu...](http://themeforest.net/item/simplpan-admin-panel- template/full_screen_preview/299692)

That's one I just happened to grab out of a search for "admin". Does it look like something that got Jediguruninja handling from a team of bespoke design consultants? No, but it sure craters the approach to that bridge, for three to four orders of magnitude cheaper.

<comment><USER6> Patio11- Design is not just about pretty colors and interface... its more about understanding the audience and their interaction before delving into creating the best user experience. Therefore, what you suggest could be a temporary quick fix that will not give you the results for a sustaining business.

You can never expect a kickass programmer to also have the best design chops. They require different forms of thinking. So stop giving false advise to programmers on enlisting design skills and instead partner with the best designers!

<comment><USER7> Don't think of the $15 theme as permanently defining the look and feel of your site. It needs to be just good enough when you're starting to look like you have some legitimacy. If you're startup is going to be generating any amount of significant revenue for you, after some amount of time, you'll be able to go back and revisit the design.

If you're a programer and not a designer, just think of your design as another optimization point.

Whenever I worry about the design/branding of my current startup, I visit the historical timeline of amazon's logo as a reminder that we'll be able to make it better eventually, but there's more important things to work on now: [http://www.kokogiak.com/gedankengang/2004/07/amazoncom- logo-...](http://www.kokogiak.com/gedankengang/2004/07/amazoncom-logo- timeline.html)

<comment><USER6> Thanks for sharing the Amazon logo timeline. I have never seen that before and am surprised to see how much it has evolved...

</comment></comment></comment></comment></comment><comment><USER8> Just for what it's worth; the first thing I noticed when I saw your logo was how much it resembles a breast (including nipple!)

Also, you should have a link to your "marketing site" somewhere near the top of the right column of your blog.

<comment><AUTHOR> good call on the link to the marketing site :) Making an enhancement here now!

</comment></comment><comment><USER9> Design is the most important part of your product if you are not creating a new market because that's the only way you can differentiate your product. Everybody is going to have the same features and what you are really selling is your design.

When you launch a new product into a new market, the features (i.e. what it actually does) end up being slightly more important than the design. The design is obviously still important, but probably not the most important part of your product.

P.s. I really like the retro-beach lifeguard metaphor for customer service.

<comment><USER10> And, by 'design' I assume you mean the entire user experience, not just the pixels?

</comment></comment><comment><USER11> Congrats on semi-launching.

1000+ signups in just 7 days is awesome.

Out of curiosity, what's your conversion rate to paying users?

I doubt you are gonna give out that number, but it would be very interesting to see :)

</comment><comment><USER12> "The viral sign up form probably quadrupled our signups through sharing the links on Twitter and Facebook."

Does 'viral sign up form' = buttons to share it on Twitter and Facebook? Or did you guys do some form of 'refer 2 friends to get higher in the beta queue'?

Nice write-up, thanks for sharing!

<comment><USER13> From the looks of it, it's buttons to share it on Twitter and Facebook, and if you refer 3 you can get it sooner, I believe.

<comment><USER14> They have a unique URL you can share via email, facebook etc. If you refer 3 friends, you move up the queue.

I have always been skeptical about such a tactic for B2B apps. They say it worked for them but it seems they are just looking at signups. I'm wondering if they are real users or just people pestered by others to signup so that they can move up in queue.

</comment></comment></comment><comment><USER15> For what it's worth, I have been using Groove and have been loving it. I briefly looked into other options and the decision to go with Groove ended up being a no brainer - it's beautiful, it's made for people who want to hit the ground running (no learning curve) and most importantly, Alex is a fantastic guy. I don't know him personally...so I'm not just vouching for a friend, but he is extremely professional and ALWAYS receptive to all of the crazy feedback that I throw his way. As a 'customer', I can't think of a time that I've ever felt this special and appreciated. Great job guys!

</comment><comment><USER16> I love the idea of winning on design - I'm a UX designer, after all - but I question the conclusion that design is how they got all those signups. They may not have been written up in TC, but they were written up in TNW. Did they get that coverage because of the UX, or did they get it because they are in a hot market?

Don't get me wrong - from what I've seen, Groove looks beautiful and well- thought-out from the user's perspective. But a beautiful and intuitive user interface won't get covered by anyone if it's in a market that no one's interested in.

Keep killing it, guys!

<comment><USER17> My thoughts exactly. It's easy for them to say it's about the design after the fact.

I'm much more inclined to think it has to do with their market, connections, and blog coverage.

Also, the design suffers from a lack of whitespace (feels crowded) and overuse of color. The landing page is way too loud, I have a hard time getting through it.

</comment></comment><comment><USER18> Really appreciate your insight on how you built your marketing. I have been looking at many different ways to market a product online (<http://infostri.pe> with little or no money.. or as you say being Crunched. It's a tough road but there is lots to learn and way to get ahead. I should do my own blog post on what we have done at Infostripe. Thanks again.

</comment><comment><USER19> I'm not sure. As potential user of this product, I really don't care about design. Even usability can be a little off. What I need is: good support, reliability, speed, flexibility/good integration with other things I use.

Somebody mentioned Apple. Is anybody buying Apple XServer disk arrays?

</comment><comment><USER20> Congrats, the startup i'm working on <http://getdealy.com/creative> got to 1000 in a few days as well, but this was mostly by Forrst Ads and telling users we had on a couple of other design lists about the deal.

</comment><comment><USER21> Just signed up for their beta and had a nice chat with what I think is one of the founders. I've used snapengage and olark in the past, have had small gripes with both of them so I'm very interested in trying Groove out. Nice work guys!

<comment><USER22> I work at Olark - just out of curiosity, what could we do better?

<comment><USER23> It sucks that the "Powered by Olark" text is there even for paid accounts/that it is so big and it sucks even more that it can't be translated to other languages. English text on non-English websites looks incredible non- professional, so much so that even though I love all the other aspects of Olark I've considered switching.

From my Norwegian customer's perspective it looks like a free script. A Norwegian company, Idium, is actually successfully charging 3500 USD for a live chat solution inferior to Olark, but since it's in Norwegian they're able to do it.

</comment></comment></comment><comment><USER24> Hi Groove Team, first off, congrats! Excellence in execution to the point that I only have 1 piece of very minor feedback: Your helpful chat window, even minimized, covers up your company info in the footer. Just the footer.

<comment><USER25> Oh, one more thing in the footer - the Privacy Policy and Terms of Service links don't go anywhere. But it looks great otherwise!

</comment></comment><comment><USER26> The site does look nice and congrats on launching!

The real test will be how many of those signups turn into paying customers.

</comment><comment><USER27> Congratulations Alex! I've been waiting for something like this for too long :)

</comment><comment><USER28> Very nice website indeed.

</comment><comment><USER29> i hope microsoft doesn't get fussy about your name

<comment><USER30> My initial expectation was that Microsoft had relaunched groove as a saas app.

</comment></comment><comment><USER31> The site looks great - congrats.

</comment><comment><USER32> Very sneeky: [http://groovehq.com/images/marketing/features/EasilySubmitTi...](http://groovehq.com/images/marketing/features/EasilySubmitTickets.png)</comment>


Show HN: Buy and Sell Retargeting Lists, Feedback Appreciated - <AUTHOR> http://retargetking.com/

<comment><USER2> I have a lot of legal concerns! Is this going to get me sued by my existing customers, whose details I would be sharing? Can you perhaps explain why this would be legal?

<comment><AUTHOR> User privacy and legal matters will always be a controversial topic on the internet. Bitcoin for example challenged the government strongly early on, but now things have regulated themselves.

</comment></comment><comment><USER3> Pretty vague. Retargeting on what - Display/Facebook/Email? How would a customer onboard these lists?

<comment><AUTHOR> Sure our startup will help you share everything that supports retargeting. You'd be able to share it through retargeting codes.</comment></comment>


Evolution of Application Data Caching: From RAM to SSD - <AUTHOR> https://medium.com/netflix-techblog/evolution-of-application-data-caching-from-ram-to-ssd-a33d6fa7a690 <comment><USER2> The i2/i3 series devices are the reason I became an AWS partisan. Azure still has nothing comparable and while GCP seems to have caught up with an NVMe offering, they seem to be in indefinite catch up mode.</comment>


Zero - <AUTHOR> http://mathworld.wolfram.com/Zero.html?

<comment><USER2> In college we had a freshman writing seminar requirement, which were encouraged to be broadly interpreted. I took a Math course, of all things. We learned Euclidean geometry, proved the Pythagorean theorem through construction, calculated ancient dates, and wrote about it all.

My final paper was a 15-20 page paper on Zero, and, despite cringing at my own writing, is still probably my favorite thing I've ever written. Zero has a fascinating history, from being outlawed in a few European countries, to being associated with the Mayan King of Death. One great little piece is the following poem:

>U 0 a 0, but I 0 thee

>O 0 no 0, but O 0 me.

>O let not my 0 a mere 0 go,

>But 0 my 0 I 0 thee so.

The word "cipher" used to be another name for zero/0, so the above reads as:

>You sigh for a cipher, but I sigh for thee

>O sigh for no cipher, but O sigh for me.

>O let not my sigh for a mere cipher go

>But sigh for my sigh, for I sigh for thee so.

Which, of course, explains why Neo, The One from the Matrix, had an enemy named Cypher.

<comment><USER3> Cipher comes from the same root as Zero (sifr), making it a doublet word.

[http://english.stackexchange.com/questions/30774/origin- of-z...](http://english.stackexchange.com/questions/30774/origin-of-zero)

<comment><USER4> So the whole thing is a love poem then, with "cipher" actually meaning "zero", "nothing", or "negate".

Cool.

</comment></comment></comment><comment><USER5> Bill Casselman is interested in the history of the number 0, and travelled to Gwalior, India, to see one of the oldest known written occurrences of it. I had the good fortune to be eating at a dinner with him in which he was talking about his trip (see [http://www.ams.org/samplings/feature-column/fcarc-india- zero](http://www.ams.org/samplings/feature-column/fcarc-india-zero)), and another diner remarked, without missing a beat, "that's a long way to go for nothing."

</comment><comment><USER6> I know of an easier explanation on why a^0 (with a != 0) is 1. It is because a^0 = a^(n-n) = a^n / a^n = b/b = 1.

</comment><comment><USER7> It is sad that the link to the School House Rock segment "My Hero, Zero" appears to have been hijacked.

The last good capture was in Feb 2009 [https://web.archive.org/web/20090214010119/http://school- hou...](https://web.archive.org/web/20090214010119/http://school-house- rock.com/0.html)

</comment><comment><USER8> _It is the only integer (and, in fact, the only real number) that is neither negative nor positive._

Yet in the IEEE 754 standard there is both a negative and a positive zero. They produce "true" when compared for equality but they usually produce differently signed infinities when divided by.

<comment><USER9> That makes complete sense when you consider that IEEE 754 is all about approximating values, though. It is possible that the value you're _trying_ to represent is smaller than the smallest values actually representable by IEEE 754 floating point, but it would be nice if you could at least preserve the sign information (so that, as you point out, dividing produces the correct `Inf` value).

The real WTF in IEEE 754 is why there needs to be so many different ways to represent NaN.

<comment><USER10> What other way is there than all ones exponent and non-zero significand?

<comment><USER11> I think parent meant the many different ways to be non-zero.

<comment><USER10> Just as there are many different ways for a number to be negative.

</comment></comment></comment></comment></comment><comment><USER12> Zero: The Biography of a Dangerous Idea (Seife) is a terrific book. Highly recommended!

[http://www.goodreads.com/book/show/329336.Zero](http://www.goodreads.com/book/show/329336.Zero)

</comment><comment><USER13> Wolfram's MathWorld seems dead-set on broadcasting a lie about 0^0. It is, in fact, defined to be 1. If it were undefined, then the Maclaurin series for e^x, e^x=sum_{n=0}^{infty}x^n/n!, would be undefined at x=0, but this series is universally understood to be defined for all real x.

<comment><USER14> I think Knuth cleaned up the definition of 0^0, and showed that it should be 1 for consistency with a whole lot of other series' and function definitions

<comment><USER14> see this Quora article [http://www.quora.com/What-is-0-0-the-zeroth-power-of- zero](http://www.quora.com/What-is-0-0-the-zeroth-power-of-zero)

</comment></comment></comment><comment><USER15> This is fascinating, didn't know there was such a rich history behind zero.</comment>


Show HN: Automatic Interview Generator - <AUTHOR> https://www.interviewgps.com/generator/ <comment><AUTHOR> Creator here. I just released a tool to design a culture fit / behavioral interview in a snap. Just select the core values and competencies you want to focus on, and the application suggests an optimal set of questions.

Some questions read on multiple values/competencies, so it prioritizes these questions to get better coverage.

The questions were hand tagged. Over time, we're using data collected from our application platform to learn question efficacy.

If there's enough interest, I'll add the ability to search, submit, tag, and rate questions to this tool.

If you like what you see, you can also sign up for a free account on our main service which supports optimization across multiple interviewers, interview scorecards, and result summaries

<comment><USER2> Thanks that's really useful!</comment></comment>


Upwork to Charge Freelancers to Bid on Jobs - <AUTHOR> https://www.entrepreneur.com/331700 <comment><USER2> I feel like it's a way to weed out developers from developing countries like Bangladesh, because they won't be able to afford the cost of the bids.

</comment><comment><AUTHOR> Here's the link. For some reason the one in the post redirects to 404...

www.entrepreneur.com/amphtml/331700</comment>