Stop future-proofing software - <AUTHOR> https://medium.com/@george3d6/stop-future-proofing-software-c984cbd65e78 <comment><USER2> This article reminds me of the adage about ops people which goes, "You know you're doing a great job in operations when nobody thinks you do anything."

The problem with taking the experience that "future proofing" is never worth it, is that it suffers from survival bias, which is to say that when you did it and it made the future event a non-event, it didn't even register on your brain. If you practice more mindful engineering you can teach yourself to recognize the things you did in the past that made what you are doing today easy or even possible.

That is not to say that all future proofing is good, especially if it ties up the group in knots trying to predict all possible futures. That is where the mantra of keeping it simple really helps. Simplicity is the greatest protection against the future precisely because it has the smallest disruption surface. The simpler a process or product is, the more difficult it is to find a change that would invalidate its effectiveness.

<comment><USER3> So, to me, "future proofing" has some very specific connotations. It doesn't mean building for eventualities that you know will happen and already know how to build for (though, if it takes extra time to do so, you do need to be mindful of the cost of delay), and it doesn't mean things like writing well factored and loosely coupled code (within reason) so that you get a system that's generally easier to modify.

It means going out of your way to try and handle scenarios that you don't _know_ will occur, or whose details you don't really understand yet, with clever one-off facilities.

E.g., I've come into a couple projects now, where I'm supposed to add in some new feature, and I discover that the original author has thoughtfully added a bunch of extension points to try and help me with that. Both times, I also discovered that building in those extension points accounted for a large amount of the pre-existing complexity in the code, even though they weren't actually being used for anything yet. And both times I also found that none of them actually addressed my needs, so all that extra effort and complexity was a waste. One time I was unfortunate in that the existing code was of the "600 line functions and a whole mess of mutable state and temporal coupling" variety, so changing it would have incurred excessive risk, and I opted for just jamming my square peg into that round hole. The second time it was well- factored code, so it was easy enough to rip the round holes out to make room for square ones. But it would have been even less effort if I could have skipped that cleanup step and just jumped straight to adding the extension points.

<comment><USER4> Exactly. When people talk about "future proofing," they're imagining the future as a predictable, linear progression--which it definitely isn't. The people best equipped to deal with the complications of the future are those who have direct experience with it ... in the future.

</comment></comment></comment><comment><USER5> _The simpler your codebase is, the easier it is to adjust to fulfill a different purpose._

I think this is the most important sentence in the article. I've worked on a few _extremely_ abstracted and horribly-indirect codebases that happened to be so very flexible and extensible in exactly all the wrong directions, so much that it made it much harder to change in the way that was actually required.

<comment><USER6> Agreed 100%, this is all that matters I'd go as far to say. It's also is a key lesson in the disposable code shift that serverless is enabling as well.

</comment></comment><comment><USER7> As Martin Fowler correctly explains, YAGNI is primarily about end-user features, not the flexibility of the code and the toolchain. If you don't keep your tech stack (code, infrastructure, people) flexible, then iterative development becomes impossible. The assumption behind YAGNI is that 'you can't predict requirements accurately'. Which is true, so don't build them ahead of time. However, the same assumption requires you to be flexible, modular, etc.

Specific example from TFA: distributed app vs. large server. A distributed app might give you better scalability, which you might not need because large servers are cheap. However, a distributed app also forces you to think about state, so if you screw something up and have to fix it middle of the day, you can BG deploy the app instead of having a 4 minute outage. It forces you to modularize the logic and think about interfaces, so if you need to add, remove or change functionality then it'll likely be faster.

Etc.

What this article forgets to say is: "Stop future-proofing your software if you are still looking for a good product-market fit. As soon as you know what your business is going to be, make sure your technology stack is flexible."

<comment><USER8> > If you don't keep your tech stack (code, infrastructure, people) flexible, > then iterative development becomes impossible.

Thats the crux of the problem. Different people have different definitions of flexible. How are you defining it?

<comment><USER9> In this context it means that it's easy to make changes. As in add new functionality.

<comment><USER10> But you can't make it equally easy to add in every type of functionality. For any type of extensibility design you bake in, some other types of extensibility now become harder.

So "making it flexible" hinges entirely on whether or not you can correctly forecast exactly which types of flexibility you'll need. But this is no easier, and often harder, than predicting how end user requirements might change in the first place!

<comment><USER9> What it means in practice is no extensibility baked in at all.

Rather it is very modular design, that is very simple, bordering on dumb.

This is all very much easier said than done. "Simple ain't easy".

</comment></comment></comment></comment></comment><comment><USER11> FWIW, maybe I'm living in a bubble but I don't seem to run across unnecessary "future proofing" very often. In fact, I see the opposite as a problem much, much more frequently. I work in a boring corporate job though, not a hip startup, so nobody at any of my jobs are trying to be the next Google or Facebook - that's probably the main difference.

>We need to hire a team of developers and build in-house software, despite wordpress and shopify being a much easier alternative, because when our customer base grows to 100 times what it is now, it will make our lives easier.

I think this comes from "not invented here syndrome" rather than the assumption you'll need to support hundreds of orders a minute in the future. Also job security.

<comment><USER12> I used to see future proofing all the time in boring corporate jobs. One example I saw multiple times was complicated "generic form builders" where the dream was users would be able to add their own forms quickly and easily. Then 5 years later the whole app would be say 10 screens, but maintenance was a nightmare because under the covers everything was poorly abstracted and generic.

I also saw lots of "split it into microservices so we can scale out for load" on systems that years later still only saw minimal use.

<comment><USER11> I fully admit my experience might not reflect most people's, just sharing mine. Thanks for sharing yours, it's interesting the differences.

</comment></comment></comment><comment><USER13> YAGNI is, as ever, pretty good advice. It's hard to follow, it's always tempting to ignore.

</comment><comment><USER14> My mantra is - never assume features, but always assume change.

As others have mentioned - it's orders of magnitude easier to add a layer of abstraction to a simple system as requirements evolve, than it is to remove an unneeded one down the line. The latter is often impossible.

<comment><USER15> As a software engineer, you should be building a platform on which the product can exist.

I rarely, if ever see this done. Probably because it takes a big risk as an engineer to actually do it.

</comment></comment><comment><USER16> I thought this was really spot on. The point about the glorification of people working on really hard problems at scale. I just read The Google SRE book and while there are definitely lessons I can use in the company for which I work (~5 devs), it definitely isn't a straightforward "do what worked there".

I couldn't find hard numbers from the Bureau of Labor Statistics, but this Stackoverflow survey [0] from 2016 points out that 50% of developers work at companies with less than 100 employees (that's employees, not developers). So many many software jobs are at smaller companies. Why don't we hear from them about their trials and tribulations?

Here are some ideas I've had (off the cuff), would love to hear other thoughts.

1\. Big companies invent the future because they have the resources to do so. That wisdom then gets rolled out often in the form of software (Hadoop, k8s, React).

2\. Small companies are boring. They are still struggling with product market fit or are stable and boring. They are not sexy, especially if they aren't growing quickly or are a services company.

3\. Bigger companies have a bigger platform to announce work and/or support people to write and speak. Software they develop touches more folks.

4\. Smaller companies are not doing anything interesting to the wider development community. They are focused on niche problems that aren't really interesting.

5\. Folks at smaller companies don't write/speak as much.

6\. We are hearing from smaller companies, just not as much/it's categorized as 'startups'.

7\. Consultants, who tend to do a lot of proselytizing of new software trends, work for larger companies because "that's where the money is".

8\. The scale of small business is such that software quality doesn't matter as much.

I don't really know what the reason is. I've primarily worked for small companies my entire career and I think the impact that software can have on a small business is transformative and well worth writing about (as I have for years and years [1]).

[0]: [https://insights.stackoverflow.com/survey/2016#company- size](https://insights.stackoverflow.com/survey/2016#company-size)

[1]: [http://www.mooreds.com/wordpress/archives/43](http://www.mooreds.com/wordpress/archives/43)

</comment><comment><USER17> > We need to use a kubernetes & docker based solution for our infrastructure, > despite a single large server being a much easier alternative

It's a half-truth that one doesn't have to do it from the very beginning.

You don't have to set up a whole cluster where a single host suffices for a long while. You do have to plan that your project may eventually become big enough to require a cluster - and consider doing yourself some design favors here and there to make that transition easier. Or knowing that you're going to spend a while redesigning stuff, while being pressed by the growth.

I mean, I've regretted not doing some design _assumptions_ (e.g. about storage) from the start more than once or twice.

<comment><USER18> I find using Docker (or any container) actually simpler than maintaining a pet server, even if you never need a cluster or Kubernetes. Just the ability to develop & test in an environment identical to production is a huge benefit on its own.

</comment></comment><comment><USER19> The fact that we're having these discussions shows to me how immature our industry still is. Say, people figured out pretty well by now how to design, build, maintain and use aircrafts. Not so much spacecrafts, though. Yes, hardware is improving faster than anything, but I wouldn't say the same about software, unfortunately. I'm still puzzled what CS education does – those graduates seem incapable of doing real coding jobs. And the camps phenomena is a different story all together. As a result, we keep on guessing and experimenting on every project, everywhere. Just imagine the same in the airspace industry (not that they don't experiment, just in a completely different manner). I don't know what I'm doing wrong, but it seems everything I built or coded wasn't great: under-engineered, over-engineered, took too long, used wrong platforms, etc. There are certain minimums below which the software is crap, but we never know what they are, and there are no standards that last long enough, as they lack value and have to be rewritten. The big software companies don't lead, and they are actively opposed by the general industry public; the Open Source community sounds great, but I think that the Every Man for Himself state of the industry is till predominant. So, lots of things to work on and improve – got to sound positive at the end.

</comment><comment><USER20> I just stick to the rule of three: if I see the same pattern three times I consider the abstraction I'm missing.

This surprisingly leads to "future proof" code. I didn't anticipate the needs of the business. I just wrote what needed writing. Yet over time I build the abstractions in that the code is actually using.

I say surprising because code written this way looks obtuse and... messy. You get very senior and very confused developers asking you why you didn't apply The Singleton Factory Pattern or use the XYZ architecture. So you say, _because I didn't need it_ and they just don't get it.

But that's part of the reason why I like Haskell so much these days. And why I liked Python for so many years. I like languages that bake in good ideas and abstractions for you. Python baked in the iterator pattern, the decorator pattern, etc so that you could use them in the language with little ceremony. Haskell bakes in the most powerful abstractions of all: type theory and algebra.

And still the idea of only writing the code you need to solve the problem; nothing more or less; stands up. People may look at you like you've lost your marbles. But if you can get them to stick around in the codebase for a year or two they'll start to see it too.

</comment><comment><USER15> I don't have a problem with future-proofing. I do have a problem with half- solutions (which is mainly what I see in the industry). E.g. if you need to run some code before or after a transaction, make a generic way to make this happen.

The problem is that devs do not create enough leverage in their solutions, so they're never that useful in the future. And, devs tend to over estimate what is actually re-usable. The second point may be the most important. Too often, I see solutions that are half-way reusable, which means they're not re-usable at all.

In the end, building out a solid foundation is key. The problem is, this is pretty hard and takes a lot of experience to know how to do well.

</comment><comment><USER21> The way I have approached this problem is to take a look at previous large code bases where I and others inevitably built frameworks and solutions to problems we ran into. They were created because we either couldn't find a reasonable alternative or our needs were simple that we didn't need to introduce a lot more complexity to our app. It's nice to take a step back every once and a while and try and build toy problems where you revisit those problems in architecture and see how you would do it different using today's existing solutions. I find balance using really simple and boring tech while taking advantage of some frameworks that make life easier (depending on preference)

</comment><comment><USER22> I saw startups struggle with ops and run out of runway implementing trendy micro-services from first day. But then I saw successful startups flourished from faux pas CLI-generated monoliths and no-brainer deployment templates. MVP FTW!

</comment><comment><USER23> Better idea: dont pretend you are about to be the next google. Worry about that when it happens.

I see too many startups burning time/money on scalability they dont need. If you have 1000 customers, and your rack can handle 20000, dont talk to me about future-proofing against the day you are building your own datacenter. Keep your code working for today's customers. Worry about scale when it happens ... IF it happens.

Imho, limit your perspective and planning to double your current customer base (good day senario) and half (bad day senario). Any day beyond those bounds will require a rethink. A rethink THEN, not today.

<comment><USER24> If you're optimizing for investment, I wonder how much of potential funding is tied to your ability to communicate that you have thought the scaling problem out. If your investors are more technical, service oriented architecture and orchestration tools (like k8s) may serve as signifiers that you have some sense of what you're doing.

<comment><USER25> David Sacks said in his Twitter that's one of his criteria for investment - "What's the friction to scale? Can the team solve?"

</comment></comment></comment><comment><USER26> > We need to use an inheritance based design for our types,

> despite composition being a much easier alternative, because

> after 5 years of codebase growth, it will make our lives

> easier.

And a equally future-proofy statement:

"We need to contort our code to avoid our implementation language's inheritance features to instead use composition because after 5 years of codebase growth it will make our lives easier"

There's a reason why the GoF says "prefer composition over inheritance" and then spends half the book covering inheritance.

<comment><USER27> I admit being confused about this one. Composition or inheritance isn't harder or more work, and neither provides velocity or maintainability benefits. The argument is about how to model complex behavior -- they have tradeoffs in duplication and statefulness. And you can mix both in the same code base with ease.

Here's another one though. We need to use Promises despite callbacks being trivially understandable and supported everywhere in arbitrary JavaScript versions because in 5 years everyone will probably always use Promises for everything.

<comment><USER28> I think the real takeaway is that composition is much more likely to model the semantics you have, even though inheritance feels like it gives you better code re-use.

<comment><USER27> I admit to being a composition bigot when green fielding some functionality, and I've never felt like code reuse was a thing either mattered for. I like composition because it's easier to create small testable component contracts. But I maintain plenty of inheritanace based code and, while it's less testable, it's... fine. Not really a big deal to use either or both.

Edit: to be clear, when I hear "code reuse", I think "using a component outside its original intent". Composition does impose some duplication sometimes, but it's braindead plumbing code, not buggy logic code, that gets duplicated. I generally think that cost is worth it to gain more statelessness. Hence my greenfield bigotry

<comment><USER29> _I like composition because it 's easier to create small testable component contracts._

You don't need testability or 'greenfielding' for this. 'Design by contract', as you mention, is a useful way to think about this, without attaching value judgments to composition or inheritance. Inheritance is a much stronger and therefore burdensome contract. It's much less likely bits of your model can really adhere to it. The advice to lean towards composition is a function of that - few models can meet that high bar.

<comment><USER27> Right. Inheritance implies contracts that include behavior, composition implies contracts that don't.

I talk of greenfielding because it's rare that the inheritance alone holds a codebase back so much that it needs to be rewritten. But code I originate is always composition based

</comment></comment></comment></comment></comment></comment><comment><USER30> This may be true while searching for product market fit, but once you hit a certain (small but stable) size, your ability to identify what your existing and future customers currently want, and will in the near to mid future want goes up.

There's a difference between future proofing to be able to deliver a roadmap or using your market research to get the next X customers and trying to guess at what some as yet unknown market might one day want.

</comment><comment><USER31> We built an SQL compiler in Haskell, and this has been our model from day 0 (back in 2010)...

It's really easy to follow these rules with Haskell. We develop our syntax to be easily extensible. Being strongly and statically typed allows us to extend our parser/compiler with relative ease, and not think too much about how the future will look.

<comment><USER32> Any chance to open source and have a look? Thanks!

<comment><USER31> The parser is open source - [https://github.com/JakeWheat/hssqlppp](https://github.com/JakeWheat/hssqlppp)

<comment><USER32> Looks great, thanks for sharing it!

</comment></comment></comment></comment><comment><USER33> like so many things written about software, this ignores everything in the process that isn't a computer program. Future-proofing is a natural consequence of a management style that doesn't clearly set goals and boundaries. Engineers wind up future-proofing because their goalposts are constantly moved. Picture this scenario:

        Engineer: I can build it in different ways. This simple way will accommodate N users, this more complicated way will accommodate M users but will take three times as long. I recommend we do the first option, because it's unlikely we'll see more than N users.
        Management: no, we want to get to M users, build it the second way

That sort of situation is exceedingly common. The reality is that the vast majority of engineers don't get to set the product development road map based entirely on engineering concerns.

</comment><comment><USER34> Posts like this always remind me of "Notes on Postmodern Programming" ([http://homepages.mcs.vuw.ac.nz/~kjx/papers/nopp.pdf](http://homepages.mcs.vuw.ac.nz/~kjx/papers/nopp.pdf) [pdf])

</comment><comment><USER35> my understanding is that keep code modular, if it repeats 3 times then 'maybe' abstract it, and no matter what you do .. in time you'd have to rewrite from scratch if not all but parts of it.

there is no future proofing as there is no way to predict or time to put effort in predicting how business needs are going to change, how apis you talk are going to change, and how technologies you use are going to change.

it's easier to just write simple functions, that you can come to later and see what they do quickly and change them.

Only on going problem I do have is dependency, that I've to check every thing that used the said function, does it continue to work

</comment><comment> m-p-3 You still somehow have to think about the future though, but you gotta make sure to keep it simple as well. It's all about juggling different needs vs available resources.

</comment><comment><USER36> "A company that can eat one marshmallow now should never wait to get two marshmallows." This is simply false.

<comment><USER37> Not to mention that that's not how that experiment works.</comment></comment>


Six Common Internet Privacy Myths - <AUTHOR> https://www.danieldent.com/blog/six-internet-privacy-myths/

<comment><USER2> This blog post is a complete joke.

SSL and Full Disk Encryption are not secure, but gmail is because gmail is a leader in email encryption. What does gmail use to encrypt emails between its server you ask?

SSL/NSS the cryptographically standard... Which the blog post already said was insecure. It reeks of corporate cargo-cult mentality. Google said this is secure, therefore it is secure.

The truth about security is you are never secure. If somebody wants to hack you, they will given enough time. All you can do is force them to spend more time. There will always be the _first time_ an academic attack vector is used in the wild.

It maybe used on you.

:.:.:

One positive note. The blog post didn't use, "Freeze the ram with liquid nitrogen" Paper to talk about Full Disk Encryption being broken.

<comment><AUTHOR> I agree that you are never fully secure.

I also agree that not even Gmail is "fully secure". But for the average person, it poses _less_ of a risk to their privacy than the realistic alternatives.

<comment><USER2> Yes but on the same argument the _average person_ is more secure trusting the TLS/SSL icon on their browser than not.

This is one of my problems with the blog post is its self contradictory.

On one hand, "We should herd the ignorant sheep to the most secure plateform."

On the other hand, "We need to whine about how insecure and buggy TLS/SSL is."

Self contradiction.

If the point of gmail is to herd people to the _most_ secure platform, then you can't tell people to not trust TLS since its really is the _most_ secure platform for web communication.</comment></comment></comment>


Parachute use to prevent death and major trauma when jumping from aircraft [pdf] - <AUTHOR> https://www.bmj.com/content/bmj/363/bmj.k5094.full.pdf <comment><USER2> I read this and I'm not sure if it's a joke, or bad scholarship or what. As in, did anyone actually jump from a plane wearing (or not wearing) a parachute?</comment>


Have you ever wondered what the hiring process was 20 years ago vs. today? - <AUTHOR> https://www.reddit.com/r/cscareerquestions/comments/brjexy/have_you_ever_wondered_what_the_hiring_process/ <comment><USER2> What surprised me about LinkedIn is after I had a job for a year (first job out of school), my views went up by a factor of 10 (well, from 3 to 30 per week or whatever) and I at last started getting messages from recruiters. I felt pretty useless at first!</comment>


Mobile Internet cost around the world [Infographics] - <AUTHOR> http://gigaom.com/broadband/mobile-internet-cost-around-the-world-infographics/ <comment><AUTHOR> The U.S. needs to model our wireless regulations after these leading countries. Our economic health will suffer unless our regulatory structure improves to accommodate more competitive markets.

As it stands, much of the potential of the software business is being hamstrung by the lack of affordable and high-quality internet access.

</comment><comment><USER2> Japanese mobile internet costs about half as much as UK mobile internet, not about a sixth as much.

Starting the graph at 10 instead of at 0 is misleading.</comment>


Music Theory and White Supremacy [video] - <AUTHOR> https://www.youtube.com/watch?v=Kr3quGh7pJA <comment><USER2> I have a music theory book from India that has English translations after every paragraph. It never once says "Indian Music Theory" even though so much of it doesn't connect well with "Western Music Theory." It just says "Music Theory." I suspect the same is true for Chinese, Japanese, etc. since their music theory would also be different than for the West. It just seems unlikely that any culture will refer to it as "something other than Western music theory," and will just call it "music theory" with an apparent audience in mind.

One thing I thought was interesting is that the book states unequivocally that classical guitars are not appropriate instruments for "professional music," and are even inferior because they are "out of tune" all the time and cannot be played in any particular key. Is this Indian Supremacy at work? It could come across that way, but really they are speaking to a specific group of musicians that simply aren't playing Western music.

Whenever the book refers to guitar in a positive way, it is always the steel string slide guitar played on the lap, since they are capable of hitting the "right" notes and accommodating the "correct" techniques.

</comment><comment><USER3> When did focusing on one's own culture become "white supremacy"? How often is this standard, this demand for cosmopolitanism, applied to other cultures?

<comment><USER4> The comments are - surprisingly - on topic and cogent!

They suggest that you and I need to watch the video, where your question will be answered.

It appears to boil down to how "music theory" is described, vs. what it actually does.

One comment: "As an outsider to music theory, this is kinda mind blowing. I assumed that music theory was like linguistics but for music. A field of study that attempts to explain the structure of all types of music from around the world. Now music theory seems to be more like teaching Spanish and then saying you know everything about all the languages."

That is, what's called "music theory" should be called something like "Western Classical Music theory" (as one commentor says it done in South Africa).

Another writes: "As I commented on that 12tone video, this really reminds me of freshman seminar discussions of the literary canon, and efforts in the 60s-80s to open it up. It would seem that music in the academy is going through a lot of the uphevals that other humanities disciplines went through in the last century. "

<comment><USER3> > That is, what's called "music theory" should be called something like > "Western Classical Music theory" (as one commentor says it done in South > Africa).

In Italy, Italian restaurants are just called "restaurants".

So Music Theory doesn't differ much from how History or Geography or Literature are taught all over the world. I agree that when speaking to a global audience, some clarification would be nice, but that's a very low bar to call it "white supremacist".

The comparison with literary canon is apt. The one I was exposed to in school was composed in great part of works that are completely unknown to English- speaking audiences. Yet we didn't feel the need to call ourselves supremacist for focusing our studies on our own culture.

<comment><USER4> I don't understand why you write that it "doesn't differ much from how History or Geography or Literature are taught all over the world"

The history courses I took in school in the US weren't called "history", except maybe in elementary school. In high school I took "World History" (8th grade), "American History" (11th), and "European History" (12th).

In elementary school geography I remember doing reports on Iceland and Ecuador. My college geography course also wasn't limited to geography, though it focused more concepts like Chisholm's hinterland theory and orographic rainfall. I also remember learning about using mapping of extant fruit trees on one of the Caribbean islands to infer the locations of vanished homesteads.

I didn't take a literature course. My high school English course readings included Zora Neale Hurston and Chinua Achebe, which was part of the then- trend of moving away from a dead white male western european focus.

So if "Music Theory" has that name, but excludes music theory for other musical traditions, then it seems _unlike_ the three fields you listed, based on my own experience.

Amusingly, [https://www.italiarail.com/food/italian-restaurant-names- ita...](https://www.italiarail.com/food/italian-restaurant-names-italy-eatery- guide) says that "A "restaurant" in Italy is more upscale and pricier than a trattoria or pizzeria, with a menu that often isn't limited to typical Italian food."

<comment><USER3> Your US experience differs from my non-US one, at least regarding how courses are named. Even when they focused on, or dealt exclusively with, our corner of the world, they were called just "History" or "Geography".

Though I didn't mean to imply the rest of the world wasn't covered in them, but it was covered in far less detail. As ksaj noted, in other countries, Music Theory also has a local focus. The only difference is those countries don't feel a need to represent the whole world, or guilt when they don't.

And trattoria just means something like "small restaurant", so it would again need an "Italian" prefix to distinguish it from other kinds. But since it's in Italy, and with an Italian name, they don't feel the need to do that. And while restaurants (often) aren't _limited_ to typical Italian food, their menus would often earn them the label of "Italian restaurant" outside of Italy.

<comment><USER4> Sure, but you wrote "all over the world".

What culture do you come from? I have a hard time thinking that past primary school a history course is simply called "History".

Are you actually responding to the video? If so, could you explain what points you are responding to?

Or are you responding to my half-baked interpretations of YouTube comments? Because if so, it seems like a waste of your time and mine.

FWIW, "white guilt" seems more often used to silence white support of non- whites than be an accurate description.</comment></comment></comment></comment></comment></comment>


Cross-Browser Testing Tool Will Rock Your Socks Off - <AUTHOR> http://www.browserstack.com/ <comment><USER2> If you're looking for a service that's live, I've been using <http://crossbrowsertesting.com/> happily for the last two or three years.

Also, if you're testing emails in different clients (worse than IE6 compatibility testing IMHO), I highly recommend <http://litmus.com/>

</comment><comment><USER3> By the way, just realized you are based out of India. Great job! Very happy to see a quality web product that is made in India. Who did your design? Love it!

<comment><USER4> great you liked our design! I am the designer of the site :)

</comment></comment><comment><USER5> Is it like <http://browserling.com> ?

Can it handle httpauth?

<comment><USER6> yes it can. you can even test your local setup (both local servers and local html files)

</comment></comment><comment><USER7> One thing I never quite understood about online testing tools like browserstack and saucelabs is how to reset server state.

Most webapps have some kind of datastore. Poking around a web ui will CRUD records in that datastore, possibly corrupting the next test. Another problem with this is coupling between tests, making them hard to modify without breaking a bunch of others.

Most automated test setups I have seen run on a local machine, and all server state is reset between each test.

How is this done on browserstack/saucelabs?

<comment><USER8> I think they just delete the user profile which is where browsers usually save their data.

(not 100% sure about that, but I think Selenium mentioned that in the logging output)

<comment><USER7> By datastore I meant server side database (SQL/NoSQL)

<comment><USER8> The way you'd usually do it is either having a multi-user application and just create a new user for a new test (also helps testing concurrently) or you'll have to reset the app by:

\- redeploying it on a new e.g. EC2 instance

\- clearing out the database and inserting your original blank state from an SQL dump

\- clearing out the filesystem by e.g. using a git reset

p.s. you should try to have an automated deployment for your product. That way you could also just spin up a new EC2 instance -> deploy -> test -> kill instance

</comment></comment></comment></comment><comment><USER9> It's funny, the only use I see for this is IE testing, since everything else I can install the latest version of on my Mac, and the differences between versions are pretty small (and if you can support IE's lack of HTML5 functionality you can certainly do the same for FF3).

Still, solid UI and product, and will be handy for the quick IE spot-checks that I should be doing more of :).

<comment><USER10> What about testing on Windows?

<comment><USER9> With the exception of fonts there should be virtually 0 rendering differences between osx and windows versions of the same browser.

<comment><USER11> _should_

</comment></comment></comment></comment><comment><USER12> <http://crossbrowsertesting.com/> is an alternative that has proven very good and cost effective for me.

This does appear to be cheaper though. The local testing thing may be cool. Not sure how that will work.

</comment><comment><USER8> Sadly doesn't seem to offer an option to do automated testing (such as a selenium endpoint).

<comment><USER4> Thats entirely a different problem, as of now we are completely focused in providing browsers across OSes and Mobile platforms with a very easy to use UI!

</comment></comment><comment><USER13> Might be OT, but does anyone know of a similar service for MOBILE browsers?

Obviously Android and iOS are webkit based... but what about the horror that is BlackBerry rendering? <shudder>

<comment><USER14> Perfecto Mobile is pretty good

</comment></comment><comment><USER15> I thought this was going to be another cross-browsing testing thing that wouldn't work for me, but the local access is a really good idea. It really does change everything.

</comment><comment><USER16> My invite request got approved right after the request, but the service isn't working for me :(

All I get is "Oops! We have run into a small problem. Please try again." over and over again.

Overloaded?

<comment><USER6> Is it working for you now?

</comment></comment><comment><USER17> Would be nice if it supported browsers on Linux and Mac too, or does it already?

<comment><USER9> It's their next feature according to Twitter

<http://twitter.com/#!/browserstack/status/110011514911592449>

</comment></comment><comment><USER18> How does it work? It's not a virtual machine, right?

<comment><USER4> We provide real browsers in the cloud across the globe for high responsiveness!

</comment></comment><comment><USER19> I think it's too pricey. But maybe it's just me.

<comment><USER4> we are trying to keep our prices as low as possible. We want to reach every developer/designer!

<comment><USER20> I think your prepaid plan should appeal to many small sites that anticipate only small changes over time. It's really a sweet spot in my mind.

</comment></comment></comment><comment><USER21> Is that similar to Browsermob and AlertFox?

<comment><USER6> nope. they are monitoring and load testing tools. Browserstack helps you make your site work on all browsers

</comment></comment><comment><USER3> Invites?

</comment><comment><USER22> I would add a per-test pricing plan, which is useful when you need to do just a few tests while developing, rather than forking $19/month.

99c to test in 5 different browser/OS combinations would be cool.

<comment><USER4> For you we already have reasonable prepaid plans!</comment></comment>


Most stars are actually born as two seperate suns - <AUTHOR> http://www.nature.com/news/double-stars-succumb-to-fatal-attraction-1.11483

<comment><USER2> Link text is wrong: the article claims that most short-period binary stars merge to form a single star, NOT that most single stars were formed from the merger of a short-period binary star.

<comment><AUTHOR> Link text should have said 'Many' stars are born as two separate stars. That is consistent - it's not clear to me what proportion of single stars started off as binaries - probably not 'most', I admit. The implication of the paper, though, is that many stars around now that we think of as 'single stars' started life as binaries.</comment></comment>


Ask HN: DNS naming conventions for cloud environments - <AUTHOR> - What sort of naming conventions do you use for your cloud environments?<p>- How do names correlate to environment (dev, staging, prod, etc), region (us-west-2, etc) and so on?<p>- How do you scope non-prod environment sub domains to reduce collision with business/product subdomains (e.g. marketing might want to use stage.example.com)?<p>For example:<p>- staging.example.com points to a load balancer for staging workloads<p>- the request is routed to us-west-2.staging.example.com via a geolocation routing policy (closest region to the user)<p>- us-west-2.staging.example.com load balancer proxies the request to the backend workload(s) <comment><USER2> In the organisations I have worked, we have normally done something like this:

\- <environment>-<component>-<application>.<application- portfolio/team>-<tenancy>.<hosting-environment>.<business_name>.com

This allowed us to delegate hosted zones to the application teams to self- manage their dns.

Example, the hosted zone:

\- marketing-nonprod.aws.example.com

Would appear as a hosted zone in the Marketing, Non-Production aws account. Note that we track the "Tenancy Environment", i.e. whether it's a prod/non- prod/labs. This will map to multiple application environments, e.g. UAT/INT/etc will be under non-prod.

Then an application like:

\- prod-web-app.marketing-prod.aws.example.com

could have a cname to:

\- app.example.com

Which we would handle as a one-off service request to the central DNS management team (often dealing with things like Akemai at that stage).

If the application stack required multi-regionality, we could added a regional identifier into the application name.

My approach is overkill in many orgs. Many of these issues are made simpler through mechanisms like service discovery.</comment>


5 Social Media Start-Ups You Should Work For - <AUTHOR> http://www.thedailymuse.com/job-search/obsessed-with-social-media-5-companies-you-should-work-for/

<comment><USER2> none of the companies listed there have a compelling value add proposition IMO.

Does anyone give a damn about anything besides advertising and marketing?

<comment><USER3> I don't know if that's fair. Livefyre just announced something like 1 billion page views/month, so clearly someone must think they have a compelling value prop!

<comment><USER2> i'm just going based on the company descriptions, when I read LiveFyre's I thought "disqus" so, not very interesting to me, as it has been a solved problem for a while.

Where's the "self-driving car" start up? or the "Let's revolutionize higher education and put colleges out of business and save the world" start up?

all of these revolve around acquiring, engaging or making sense of web traffic. not very compelling if you ask me.</comment></comment></comment>


The First Universal Quantum Processor - <AUTHOR> http://www.physorg.com/news177515046.html

<comment><USER2> A grid of coupled qubits can be used to simulate quantum systems. A quantum system many physicists like to simulate is the Hubbard model (<http://en.wikipedia.org/wiki/Hubbard_model>) . A simulation of the Hubbard model can possibly lead to a better understanding of high temperature superconductivity. This in turn can tell physicists where to look for room- temperature superconductors, the discovery of which will drastically transform the world as we know it.

This is in my opinion the most important application of a quantum computer.

</comment><comment><USER3> I'm curious, what kinds of application ideas exist that are possible on quantum computers that aren't on regular computers?

<comment><USER4> Theoretically none. Quantum computers are universal Turing machines. The main advantage of quantum computers is speedup.

5 years ago (when I took a couple of courses in QC) there were basically 2 quantum algorithms -- Shor's factorization and Grover's search. The former speeds up integer factorization (and discrete logarithm) and brings it to polynomial time, and the later speeds up search from O(n) to O(sqrt(n)).

So just being able to quickly factor integers breaks a lot of encryption algorithms, and a faster search would really help with data processing.

One of the main difficulty with quantum computers is quantum de-coherence. Qubits when they are entangled must be isolated from the outside environment until the final result measurement is taken. That is what is preventing the creation of large, multi-qubit computers. For example, it would be useful to have a 1024 qubit machine to simultaneously represent all 1024 bit states.

Quantum error correction might solve the problem, but we are yet to see practical quantum computers.

<comment><USER5> Where does quantum cryptography fit into this?

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

Does this have anything to do with quantum computing?

<comment><USER4> You are right, thank you. I embarrassingly forgot quantum cryptography.

<comment><USER6> you were right to leave it out - quantum cryptography and quantum computing have only the quantum in common. (i've published on quantum cryptography protocols)

<comment><USER5> Could you elaborate on this?

Classical encryption can be done on a classical computer.

Is it the case that (some) quantum encryption cannot be done on a quantum computer?

<comment><USER6> quantum cryptography isn't "encryption" in the sense that crypto algorithms are involved. the encryption part is just XOR with a random one-use string (the key). the hard part is distributing that key.

a better name is quantum key distribution. entangled photons are used to get the random data to both parties in a way that eavesdroppers would introduce error (because of something called quantum indeterminancy).

since no computation is involved, there's not a lot relation to quantum computing. wikipedia's got the details!

<comment><USER7> Disclaimer: I'm not quantum-anything researcher. But: Based on the description of how "quantum encryption" works, I prefer to call it "quantum intrusion detection". It allows you to verify that the channel is free of eavesdroppers and get a stream of random bits that are guaranteed to only be agreed upon by the two ends of the connection, which can then be used for any other purpose that a stream of random bits only known by two parties can be used for. Using it for a one-time pad is the easiest thing from a theoretical point of view, but you can use it to feed a conventional encryption algorithm, too.

The real key isn't the "random", which is easily obtained from a wide variety of other sources, including fully unpredictable ones like decay sources, nor is it the "encryption" which is merely one application (though easily the "killer app") of the system. The real key is the part where you can detect any intrusion into the connection.

(Obviously, you, enki, know this, well, unless I'm wrong. I'm just elaborating.)

<comment><USER6> hey, nice idea - but that's not how it works.

there's no intrusion detection - an attacker increases the error rate, and by the error rate we can calculate the maximum probabilistic information an attacker plausibly might have. i say can, because that number is actually pretty uninteresting, since it isn't intrusion detection - we just now there's something causing the error rate to go up - doesn't have to be an attacker. a higher error rate in practice just means we gotta throw more bits away both during error correction and during privacy amplification - which is kinda like packetloss on a classical channel.

at some point the error rate is too high for error correction with a positive yield (= more key lost in communication, than gained through said communication) - thus the scheme stops working.

my personal favorite name is 'quantum key growing', because that's essentially what happens - you turn an initial shared secret (= random key) into a longer random key. (and while you're continually doing this, you're using up part of the previous key to secure communication as you go along)

<comment><USER7> Is there some interesting characteristic of the channel that you're looking for, other than intruders, though? Merely detecting the error rate on a channel is uninteresting; conventional algorithms have nailed that problem to the wall. I'm not worried about exactly how it is done, I'm thinking about what it's good for; take away the ability to detect intruders, even if that's not the only thing it may be doing, and what's left?

</comment></comment></comment></comment></comment></comment></comment></comment></comment></comment><comment> cool-RR Waiting for Scott Aaronson, <http://scottaaronson.com/blog/> , to give his verdict.

</comment><comment><USER8> Quantum Computing seems like voodoo to me, I have to read up more about it. Anyone care enough to explain a bit to me how data compression can benefit from it?</comment>


UX Engineering - <AUTHOR> https://dev.to/emmawedekind/ux-engineering-3hem <comment><USER2> I just can't get past the banner graphic. Who types like that? And why are their watch and mouse so far away?</comment>


Introducing Closure Stylesheets - <AUTHOR> http://google-opensource.blogspot.com/2011/11/introducing-closure-stylesheets.html

<comment><USER2> This looks like an evolution of the CssResource mechanisms used in GWT for a while now, adding some features from LESS like mixins.

</comment><comment><USER3> LESS/SASS, Java style.</comment>


Internet Archive Paying Employees in Bitcoin, Asking for Donations - <AUTHOR> http://bitcoinmagazine.com/internet-archive-paying-employees-in-bitcoin-asking-for-donations/

<comment><AUTHOR> Some additional info: Internet Archive blog post [http://blog.archive.org/2013/02/21/employees-to-be-paid- in-b...](http://blog.archive.org/2013/02/21/employees-to-be-paid-in-bitcoin- please-donate/) @brewster_kahle's tweet announcement: <https://twitter.com/brewster_kahle/status/304761086962434049>

</comment><comment><USER2> I wonder if they will keep doing this once the bitcoin bubble bursts in a few months time</comment>


Adobe tackles Hacking Team zero-day vulnerability - <AUTHOR> http://www.zdnet.com/article/adobe-tackles-hacking-team-zero-day-vulnerability/ <comment><USER2> Adobe tends to catch a lot of flak with regard to security... and a lot of it is well-deserved. It's nice to see that they saw a problem, and immediately began work on a fix -- for those people with Flash still enabled, it'll be nice to have a security hotfix :)

<comment><USER3> An impressive turnaround from "we use 3DES-ECB as a password hashing function" to "we identified and fixed 0days in our product fast enough to meet a project zero deadline".

</comment></comment><comment><USER4> Flash should have been AFL-Fuzzed (Or something similar) a long time ago and this should have been found proactively. Flash hasn't been on my computer for ages and I urge you to do the same thing.

<comment><USER5> Apologies from straying from the topic at hand but "Fizzbuzzed"? That's a verb now? And its meaning is nothing to do with typical hiring process that FizzBuzz is popular for?

<comment><USER4> Sorry, tech-term-mixup in my brain. I meant AFL-Fuzzed ofcourse. ([http://lcamtuf.coredump.cx/afl/](http://lcamtuf.coredump.cx/afl/))

<comment><USER6> AFL-Fuzz is great, but it isn't going to find everything. Some things I can think of that might make finding this difficult with afl-fuzz:

* Flash is a scripting language. It's very hard for a fuzzer with no domain knowledge (like AFL-fuzz) to fuzz language-level constructs, since the vast majority of random inputs are trivially invalid.

* Flash is typically embedded in a larger program like a browser; this makes it much more expensive to test (browsers have long startup times, and are very slow when run under the kind of instrumentation needed to detect things like use after free bugs)

Unfortunately there's no silver bullet for finding vulnerabilities...

<comment><USER4> While I agree with this, Adobe does have the knowledge and skills to hook a fuzzer into their Flash source on sandboxes and vm's, and basically let a fuzzer rip. When you build one of the most installed pieces of software in the world, you should take that responsibility.

<comment><USER7> AFL works from the outside (and even accepts certain keywords to "hint" the fuzzer)...so really anyone could run it against Flash having it generate SWF's. But it'd probably take a really long time to find anything.

</comment></comment></comment></comment></comment></comment><comment><USER8> There's a typo in the article:

> user-after-free (UAF)

Should be "use-after-free" (no r on use).

Edit: Actually looks like the typo was in the origin Trend Micro blog post and the author just copied the typo into their article 1:1.</comment>


Notes on Plan 9 - <AUTHOR> http://pages.cs.wisc.edu/~madthanu/qual-notes/plan9.txt

<comment><USER2> Looking at the directory in which these notes appear,

[http://pages.cs.wisc.edu/~madthanu/qual- notes/](http://pages.cs.wisc.edu/~madthanu/qual-notes/)

these seem to be Thanumalayan Sankaranarayana Pillai's 2012 qualifier notes on Plan 9.

They're nice notes, but given the title ( _Notes on "Plan 9 from Bell Labs" by Rob Pike_ ), readers interested in reading Rob Pike's notes on Plan 9 may be disappointed.

<comment><USER3> We added the year and shortened the title. Thanks.

<comment><USER4> This is not from 2012, this is ancient. It talks about IL and 8½, which were removed more than 13 years ago.

<comment><USER5> The Barney Stinson homage, would put it at 2005 at the earliest (when the show started)

<comment><USER4> It's earlier than that, 4th edition was released in 2003, and IL and 8½ were removed between 3rd (2000) and 4th edition.</comment></comment></comment></comment></comment>


Facebook acquires Israeli data shrinking startup - ONAVO - <AUTHOR> http://blog.onavo.com/2013/10/joining-facebook/

<comment><USER2> Congrats to the Onavo team!

For those not familiar, Onavo publishes apps that proxy and compress traffic from your phone so that you have less data usage with your carrier. The business model was to sell analytics on this traffic to third parties.

I'm an outsider to the deal, but I suspect Facebook isn't interested in continuing the analytics product. It seems likely that they'll integrate the data into their mobile advertising platform behind the scenes. Mobile advertising is _really_ heating up, and this will be a important competitive edge for Facebook.

Disclaimer: my company, MixRank, has a competitive advertising intelligence product.

</comment><comment><USER3> I'm rather disappointed by Onavo, despite getting in early and falling in love. They had a great product, but they kept having bugs and UX mistakes.

But good for them, getting acquired. Assuming this wasn't a burning-building acquire, which I sincerely hope it wasn't. I liked Onavo.

</comment><comment><USER4> According to Israeli media, the price is between $150M-$200M: [http://www.calcalist.co.il/internet/articles/0,7340,L-361422...](http://www.calcalist.co.il/internet/articles/0,7340,L-3614221,00.html)</comment>