99% code coverage (2017) - <AUTHOR> https://rachelcarmena.github.io/2017/09/01/do-we-have-a-good-safety-net-to-change-this-legacy-code.html <comment><USER2> The industry is obsessed with getting 100% unit test code coverage even though it doesn't mean anything to the project. The purpose of unit tests is to lock down the project's source code once it's essentially completed; to avoid regressions when making minor changes.

If you start writing unit tests too early in the project, you're effecively locking down units of code which haven't yet proved themseves to be useful to your project. If you build square wheels for example, you may not realize that they're not designed correctly until you attach them to the car and realize that the car doesn't function well with them. It makes no sense to preemtively write unit tests for a component which has a very high likelihood of not being in its final desired state; you're just giving yourself more work to refactor the unit tests over and over; or worse, you're afraid of refactoring the tests and so you lie to yourself thinking that square wheels are fine.

Integration tests are by far the most useful tests to have at the beginning and middle stages of the project; integration tests allow you to keep your focus on the real goals of the project and not get stuck on designing the perfect square wheel.

<comment><USER3> It drives me nuts during interviews talking about test automation because people are very particular about the type of testing whether its unit testing, integration testing, acceptance testing, or whatever.

In my mind you only need 1 kind of testing: feature tests. Does the application provide the expected output for a given input and/or configuration. The application does all that it claims to do in a very precise way or it doesn't. Everything else is extraneous, though you may have to test the application in wildly different ways with wildly different means of automation to validate all feature support.

Feature tests are executed by running the application with a given input and configuration and comparing the result against a known expected output. Provided sufficient feature coverage this is enough to test for regression. While the feature tests are running each test runs against a clock so that dramatic swings in performance can be qualified with numbers. When that is not enough, as in the case of accessibility, have people (actual users) perform feature tests.

Other problems like bad design, redundant features, or poor code quality are qualified using code reviews and validation tools, like a linter.

<comment><USER4> I think your argument is missing the "cost" of feature tests, which is that they necessarily must run much slower than tests that are only testing a small unit of code.

For example, I worked on payroll software at some point. After finding a bug, we'd want to ensure that could never happen again, and would want to add a test for it going forward. So for example, I may have needed to write a test around someone who worked in one city in Ohio, lived in another, previous income above some amount, and with certain tax advantaged benefits. Setting up this test via feature testing is certainly possible, but it's likely the test itself will take a significant amount of wall time to execute. It's way faster to just test the payroll calculation code, which means you can run the tests more often, and with less developer inconvenience.

<comment><USER3> > but it's likely the test itself will take a significant amount of wall time > to execute.

Why? What about your application changed so that it is slower when testing compared to real world use? If anything it should be dramatically faster because people don't provide microsecond accurate automated responses. If the application naturally executes very quickly I would imagine it would take far long to set up the test scenario than to execute against it.

In my own applications if they take more than two seconds to deliver a response (even for 5mb input) then at the very least I have a critical performance defect. There are not many administrative tasks I can complete from start to finish in that frame of time.

<comment><USER4> Sure, let's go back to my payroll example.

I need to make 8 HTTP requests to properly setup my test from a clean slate, including setting up the deductions, previous earnings, company location and employee home address. If each of those requests takes 50ms, and then I need to make a request to actually execute my test, and verify everything went well, that could easily be 500ms.

And that's just what needs to happen to run one end to end test of the payroll calculation feature. It's absolutely valuable to have a few such tests, but I'm not going to run tests for all the weird one off scenarios (like what happens if someone lives in NJ, and works in Yonkers, and the company has a location in NJ as well?) because they'd take minutes to run. I could run that entire test as a unit test in 2ms for the payroll calculation. That lets me run all of the tests I need very quickly.

<comment><USER5> can't you run these feature tests in parallel? I'm runnning a system where it full on downloads and mounts containers, and executes them (in a loopback, they get hosted by transient webservers on the test host aka my laptop, but possibly also travis), about 50 of them in parallel with tons of database calls, and it usually takes around 10-20s to complete.

<comment><USER6> It only takes you 20s to start up 50 containers? I doubt I could start 50 alpine containers in that time on my company issue 2015 MBP (Edit: A quick test reveals my personal desktop can in fact accomplish this, but it's much more powerful than my work MBP and has no virtualization overhead since it's running native docker instead of docker for mac).

I don't know about jeffasinger's company, but in optimal circumstances, a test instance of our app running against a in memory h2 DB takes 3 minutes to start. The app internally already performs heavy lifting in parallel, so it's also not clear that running multiple instances of the app will make it that much faster...

<comment><USER5> Singularity containers, my dev laptop is Linux, way less overhead than docker on mac. I'm simulating request load on a scheduler for compute jobs. In principle those jobs are not generally local, but it helps to stresstest the scheduler.

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER7> Mutation testing is a neat idea I'd not heard of. Wonder how well it works in practice.

Someone's implemented a package for doing it with Go which looks good: [https://github.com/zimmski/go-mutesting](https://github.com/zimmski/go- mutesting)

<comment><USER8> Me neither, I liked the concept of mutation testing. (I was using this performing changes manually, without knowing this technique has a nice name). I would appreciate if somebody points out a mutation framework /tools for .net

<comment><USER9> [https://github.com/fscheck/FsCheck](https://github.com/fscheck/FsCheck) is something I've used very briefly in the past. I did more work with this sort of thing in Scala.

In my experience, you usually end up with much more coverage than you want or need.

</comment></comment></comment><comment><USER10> I hadn't realized this mutation testing existed as automated tooling. I'll be looking more into it. Traditionally, I've gone with "sabotaging" the code when writing unit tests; altering the code to verify a test goes from red to green or vise versa. Never trust a test that has never failed.

<comment><USER11> > Traditionally, I've gone with "sabotaging" the code when writing unit tests; > altering the code to verify a test goes from red to green or vise versa. > Never trust a test that has never failed.

That's completely backwards compared to how you should be doing things.

You either write the test:

1\. to verify the existence of a bug by reproducing it, or

2\. to formalize the spec for yet-to-be implemented code/feature.

And then you make the test green. Retroactively writing tests for working code, only to sabotage the code... Seems like an odd way of doing things.

<comment><USER12> Some people feel more comfortable writing code without tests first, gradually shaping final design of the interface. Especially if the tests involve a lot of stubbing and mocking of things like Redis and Sphinx Search, or messing with crypto tokens, parsing HTML, freezing time, setting up global config attributes like support emails, interaction between 2 different databases, etc. Tests are code as well and oftentimes might feel heavier than production code. You can of course say that there is a way things should be no matter what but that might lead to negative emotions, toxicity and complaining instead of getting stuff done.

<comment><USER13> Agree, actually designing & implementing good tests requires a lot of effort. It's rarely wasted effort but if you really need something out the door now it can distract from short term delivery.

e.g. I'm using a 3rd party transpiler / build tool, which I don't know all the details of, my test runner wouldn't do exactly the same transpliation of code this build tool, it took me about an hour to figure out where the build tool's config file was and how to get it working with the test runner.

Did I learn more about my tooling and code base? Yes. Was it useful? well maybe not as I might kill this project shortly anyway.

</comment></comment></comment></comment><comment><USER14> I had a similar experience, you always get what you measure.

IMO the best a approach is to first integrate the test coverage in the code reviews, cause there is no hard rule [0] and second write property-based tests [1].

[0] [http://www.se-radio.net/2018/05/se-radio-episode-324-marc- ho...](http://www.se-radio.net/2018/05/se-radio-episode-324-marc-hoffmann-on- code-test-coverage-analysis-and-tools/)

[1] Sample framework for JavaScript [https://github.com/jsverify/jsverify](https://github.com/jsverify/jsverify)

<comment><USER15> I prefer just setting coverage requirements to 100%, and give developers the freedom to mark code as ignored for coverage (e.g. /* istanbul ignore next */ for many Javascript applications). That way, the annotation is something that can be brought up during code reviews in case the reviewer does not agree with that not being covered, and it doesn't depend on the reviewer having to remember to run or look at a separate coverage report.

(I wrote more about this here: [https://vincenttunru.com/100-percent- coverage/](https://vincenttunru.com/100-percent-coverage/))

</comment></comment><comment><USER16> Does anyone have experience with [https://github.com/stryker- mutator/stryker](https://github.com/stryker-mutator/stryker) for code mutation testing?

</comment><comment><USER17> The author suggests to add mutations to the code, like replacing '<' with '<=' in order to "test the tests". He assumes that tests should fail due to such small differences.

I think this might apply when you write your own algorithms and want to test them. But if you are, like most of us, working on Business Logic, then you are probably writing the wrong tests.

We usually want to know whether a workflow or a customer story works as intended and as such we should write more Integration tests.

The idea itself has merit though and draws parallels to writing tests with variable or random input parameters, I am pretty sure there already was something on this.

<comment><USER18> You think customers aren't affected if you mistakenly replace a < with a <= in your code?

<comment><USER19>
      while (car.wheels < 4)
        car.attach(new Wheel);

</comment></comment></comment><comment><USER20> I can't imagine, as a developer, writing tests without assertions. Any developer who does that is actively making the situation worse for the team and the application.

Conversely, I've worked in teams whose managers encouraged the developers to forgo tests for the sake of delivering faster. Never again.

</comment><comment><USER21> Some tools for mutation testing in Python:

\- [https://github.com/boxed/mutmut](https://github.com/boxed/mutmut)

\- [https://github.com/sixty-north/cosmic-ray](https://github.com/sixty- north/cosmic-ray)

</comment><comment><USER22> You can do that, or you can let priority of business requirements drive your testing efforts. For each project, I have a certain set of hard requirements that will never be used in the field. We deliver these half-assed and fix bugs if 2 years later someone uses the feature by accident.

</comment><comment><USER23> Use a language that doesn't allow incorrect code and you get 100% code coverage without writing tests.

Smart compilers and precise language (ala Haskell) obviate the need for writing unit tests.

</comment><comment><USER24> Who is going to test that the mutators are doing the right kind of mutations? lol I've worked on code that has 1000's of tests and is still a bug ridden hell.

<comment><USER21> Those tools also have tests.. :)

</comment></comment><comment><USER25> I always achieve 100% relevant code coverage. I just set up a test with one input which tests my main(), which then obviously calls all the relevant parts of the code.

Or am I missing something in the definition of code coverage?

I don't see anyone using exhaustive-input tests, which is usually impossible anyway, or splitting up each branch of conditionals into separate functions so as to make them unit testable.

I only see people splitting up the code into arbitrary function blocks, having at least one unit test for such function and then declaring all lines of code of that function as test-covered.</comment>


Prototyping a connected piggy bank - <AUTHOR> https://medium.com/@stuarttayler1/prototyping-a-connected-piggy-bank-1d4e507a9a77#.uop9w1ha6 <comment><USER2> This is a really cool idea. I'm particularly impressed with the small details that together make this project work.

As it so happens I was introduced to the Particle Photon during a hackathon this weekend, and here it is again. It looks like it's a great little controller to work with and probably should be on my list of things to pick up soon.

</comment><comment><USER3> I can just see the commercial version of this. "You now have enough money to buy Pokemon Double Crisis. Would you like to buy it now?"

<comment><USER4> That is just plain evil. And unfortunately, I'm sure it will be attempted.

</comment></comment><comment><USER5> The technical side of the project is awesome, but the rationale of "digital piggy-banks" seem somewhat questionable to me.

First of all, there is still a long way (and a good number of discussions) to go until we have a 100% cashless society. So is it really necessary today that children deal with bank accounts and e-commerce before they even completely grasped the concept of money? Moreso, this seems to tie "dealing with money" inextricably to the smartphone. A bad idea if you want to teach children to get away from computers now and then.

Second, the children seem to have a lot less agency than with an actual piggy- bank: With a normal piggy-bank, the children are given money and can decide for themselves if they want to save it or spend it on the next ice-cream stand. (Even if they have to disobey their parents to do this, it's still a choice). With digital cash, the parents/relatives/etc aren't giving the money to the kid anymore, they're sending it directly to the piggy-bank. There is nothing the kids themselves can/have to do anymore.

Both the OP project and the one Asturaz posted seem to have recognized this as a shortcoming and tried to fix it by adding some longime planning options ("you can choose what you want to save _for_ ") or some actions without consequences so there is at least _something_ that the kid can do. But I think those provide a very differenct concept of "choice" than a normal piggy-bank does.

Again, the concrete projects are pretty cool and this is more a general rant and not supposed to be criticism of the blog author.

</comment><comment><USER6> A New Zealand bank has made this one: [https://cleverkash.asb.co.nz](https://cleverkash.asb.co.nz)

Obvious there's a certain advantage to already being a bank for projects like this.

<comment><AUTHOR> There are but it's not long until Monzo is a bank & they will have an open API so this type of integration should be straightforward.

[https://community.monzo.com/t/status-of-the- api/5497/4?u=ale...](https://community.monzo.com/t/status-of-the- api/5497/4?u=alexs)

</comment></comment><comment><USER7> a kickstarer project which have observed se same issue with cashless society [https://www.kickstarter.com/projects/187482891/ernittm- the-s...](https://www.kickstarter.com/projects/187482891/ernittm-the-smart- piggy-bank)

</comment><comment><USER8> Really beautiful way to make an account physical. Oink!

</comment><comment><USER9> i love it!</comment>


Jack Dorsey Takes Over Product Again at Twitter as Executive Chairman - <AUTHOR> http://techcrunch.com/2011/03/28/jack-dorsey-takes-over-product-again-at-twitter-as-executive-chairman/ <comment><USER3> This is all part of a plan that was laid down some time ago.

Jack is a product guy. Tremendously good (evidence being he created both Twitter and Square). Jack is not an operator of a quickly scaling company, or at least, that's what Ev has said on the record more than once.

Jack recognizes his strengths and weaknesses. At Twitter his weaknesses were "recognized" for him and he was pushed out as CEO. It was painful and left some damaged bridges. He's been maturing and growing since then and looking back, probably agrees it was the right move even if it was handled the wrong way.

Then he founded Square. He got the product launched and hired Keith Rabois, a well-known operator. A hardcore, real operator and business guy.

Jack will run product at both companies. Keith will run day to day operations at Square, probably even as CEO. DickC will continue to run day to day operations at Twitter. Jack will play to his strengths and let someone else keep the cash balances in check.

With Twitter, Jack was pushed out. With Square, he probably couldn't have hired Keith if there wasn't a plan or timeline in place for Keith to become CEO.

* This is all my speculation.

<comment><USER4> I doubt Keith Rabois joined because he felt he could become CEO. I think you're underestimating the draw of getting to work with someone as good as Jack Dorsey and on a product as exciting (to Keith) as Square.

<comment><USER3> What kind of timeline would you like to lay down a bet? 12 months?

</comment></comment></comment><comment><USER5> How can he expect any loyalty or dedication from his employees after doing this? If I was working for square, I'd be pissed that the leader of the company just cut a significant amount of time from what you're working on everyday.

</comment><comment><USER6> Everyone initially believes they can "focus" on two big things at the same time. No one can. He's about to learn this lesson the hard way.

<comment><USER7> like Steve Jobs with Apple and Pixar?

like Elon Musk with Tesla and SpaceX?

like Peter Thiel with Founders Fund and Clarium Capital?

<comment><USER8> Clarium Capital has been performing terribly for years.

However, I agree with your general point (that it is possible for one person to focus on two large projects).

<comment><USER9> Still, Executive Chairman and CEO are two rather "big" titles. If he can juggle both and be successful I will be impressed. We will never really know how much effort he puts into each role.

</comment></comment></comment></comment><comment><USER10> Any thoughts on why he'd choose to do this when he is focusing on Square? Could it be that he disagrees with what's happening with Twitter and wants to steer it in the direction he wants it to go?

<comment><USER11> My guess is that he just really loves the product, and now that Ev and Biz are AWOL, he can actually do what he wants with it.

It's also a great PR response to the #dickbar.

<comment> brown9-2 Is it a great PR response? It seems to me that a move like this helps solidify the #dickbar as a failure, and shows the company acknowledges it needs to fix the direction (which they have not been willing to state thus far).

<comment><USER12> I think the acknowledgment is what he meant by a great response.

</comment></comment></comment></comment><comment><USER13> Nothing against Jack, but this much management chair swapping is not good for a company. Tells me there is a lot of internal struggle going on. Perhaps the shareholders are pressing for monetization, and Ev pushed back on that (or tried and failed) and now Jack is coming in to give it a try.

<comment><USER14> The management chair swapping occurred when Ev pushed Jack out, and then later realized he was burned out and faded out as Dick stepped in.

Having Jack back involved in the company - assuming he is fully committed - <USER2> perhaps the best thing that can happen to Twitter right now. New ideas, stability and founder support.

I think it's great news for everyone, including us users.

</comment></comment><comment><USER15> Hopefully he can bring a working monetization model with him.

<comment><USER16> I think Jack will concentrate on the product, the monetization part will be left to Dick Costolo.

<comment> brown9-2 Can the two really be separated like this?

<comment><USER7> Yes

<comment><USER17> Are there any historical examples of it working?

</comment></comment></comment></comment></comment><comment><USER18> To paraphrase from LL Cool J: Dont call it a comeback, he's been there before!

<comment><USER19> Rocking his peers. Putting suckers in fear.

</comment></comment><comment><USER20> Can't help but wonder how Square's investors feel about this.

<comment><USER21> It's not all bad, Square just got in the news again as a result.</comment></comment>


How Googlebot crawls JavaScript - <AUTHOR> http://searchengineland.com/tested-googlebot-crawls-javascript-heres-learned-220157 <comment><USER2> This was actually my primary role at Google from 2006 to 2010.

One of my first test cases was a certain date range of the Wall Street Journal's archives of their Chinese language pages, where all of the actual text was in a JavaScript string literal, and before my changes, Google thought all of these pages had identical content... just the navigation boilerplate. Since the WSJ didn't do this for its English language pages, my best guess is that they weren't trying to hide content from search engines, but rather trying to work around some old browser bug that incorrectly rendered (or made ugly) Chinese text, but somehow rendering text via JavaScript avoided the bug.

The really interesting parts were (1) trying to make sure that rendering was deterministic (so that identical pages always looked identical to Google for duplicate elimination purposes) (2) detecting when we deviated significantly from real browser behavior (so we didn't generate too many nonsense URLs for the crawler or too many bogus redirects), and (3) making the emulated browser look a bit like IE and Firefox (and later Chrome) at the some time, so we didn't get tons of pages that said "come back using IE" er "please download Firefox".

I ended up modifying SpiderMonkey's bytecode dispatch to help detect when the simulated browser had gone off into the weeds and was likely generating nonsense.

I went through a lot of trouble figuring out the order that different JavaScript events were fired off in IE, FireFox, and Chrome. It turns out that some pages actually fire off events in different orders between a freshly loaded page and a page if you hit the refresh button. (This is when I learned about holding down shift while hitting the browser's reload button to make it act like it was a fresh page fetch.)

At some point, some SEO figured out that random() was always returning 0.5. I'm not sure if anyone figured out that JavaScript always saw the date as sometime in the Summer of 2006, but I presume that has changed. I hope they now set the random seed and the date using a keyed cryptographic hash of all of the loaded javascript and page text, so it's deterministic but very difficult to game. (You can make the date determistic for a month and dates of different pages jump forward at different times by adding an HMAC of page content (mod number of seconds in a month) to the current time, rounding down that time to a month boundary, and then subtracting back the value you added earlier. This prevents excessive index churn from switching all dates at once, and yet gives each page a unique date.)

<comment><USER3> > (This is when I learned about holding down shift while hitting the browser's > reload button to make it act like it was a fresh page fetch.)

Most useful aside of all time.

<comment><USER4> I used to use this a lot. My experience is that for some reason, a couple years ago it stopped working reliably as a fresh page fetch. Some items were still coming up cached. Now I use incognito or private browsing windows instead.

<comment><USER5> If you're running Chrom(e|ium) with developer tools open then you can right click the refresh button and it gives you a few refresh options (eg clear cache and reload).

That tends to be my fall back whenever I'm specifically fussed about the "freshness" of a page. That or _curl_

<comment><USER4> Thanks, never tried right-clicking that before. There's also a checkbox in dev tools settings to "Disable cache while dev tools is open."

</comment></comment></comment></comment></comment><comment><USER6> I feel that dynamic websites are not websites, but applications. Even after this thorough research, I'd still be very wary of turning a primarily content- based site into a dynamic app.

A plain HTML site is accessible, and will be accessible in a 1000 years. A site depending on (external) JavaScript sources will force John Titor to travel back in time to find version 1.x of jQuery. Starting with JavaScript abandons principles of progressive enhancement. Sometimes there is not even a fallback/graceful degradation, reminding me of these 2001-era: "Best viewed at 800x600 resolution in Netscape"-sites.

Google holds enormous clout among SEO's. Google says they will factor in site- speed and a large fraction of the web will become faster. Google can say more sternly that using JavaScript can have ugly consequences for user experience and accessibility, but they are swimming upstream: The web seems to be moving on to fancy new technologies regardless of what their SEO says.

Not much good comes from HTML5 JavaScript fans forcing your hand. Tor enabled JavaScript, because too much of the web would break without it, leading to a poor user experience. This led to a huge security gaffe, which I fully blame on webdevelopers eschewing basic principles, to get that slideshow running.

<comment><USER7> I think the trend of "turning a primarily content-based site into a dynamic app", and indeed most of what has been referred to as "Web progress", "moving the Web forward", etc. comes from the desire of content producers to obtain and maintain more control over their content. Look at how browsers have evolved to de-emphasise features which give the user control while adding those that are author-targeted.

We're moving from browsers being viewers for simple HTML documents (which can be copied, shared, and linked via simple means), to a platform for running complex applications written in JavaScript which often render data retrieved in proprietary formats from proprietary APIs. The "open by default" nature of plain HTML has become the "closed by default" of the data processed by web apps, much like with many native apps. Native app platforms (e.g. mobile) are also gradually becoming more "closed by default"; I'm not sure if that's a related trend.

 _Google can say more sternly that using JavaScript can have ugly consequences for user experience and accessibility, but they are swimming upstream: The web seems to be moving on to fancy new technologies regardless of what their SEO says._

Part of the reason is because Google themselves are doing this in many of their products... some of their employees probably disagree with "JS everything", but they're in the minority.

<comment><USER8> _I think the trend of "turning a primarily content-based site into a dynamic app", and indeed most of what has been referred to as "Web progress", "moving the Web forward", etc. comes from the desire of content producers to obtain and maintain more control over their content. Look at how browsers have evolved to de-emphasise features which give the user control while adding those that are author-targeted._

I don't agree with this. Browsers are more user-targeted than ever.

 _We 're moving from browsers being viewers for simple HTML documents (which can be copied, shared, and linked via simple means)_

Browsers still allow this.

 _to a platform for running complex applications written in JavaScript which often render data retrieved in proprietary formats from proprietary APIs._

I have rarely seen a web API that uses anything other than straightforward JSON.

 _The "open by default" nature of plain HTML has become the "closed by default" of the data processed by web apps_

Almost always equally as open as any HTML you would previously received.

 _Native app platforms (e.g. mobile) are also gradually becoming more "closed by default"; I'm not sure if that's a related trend._

What do you mean by this?

<comment><USER9> > I have rarely seen a web API that uses anything other than straightforward > JSON.

There are differences between HTML vs. AJAX+JSON+Javascript+DOM. JSON has a lot less of a schema than HTML. You don't have to execute custom code from a remote server to render plain HTML. Client-side rendering is more complex for the client. A Javascript-based page is typically going to require more requests for remote resources than inline HTML, potentially meaning more bandwidth and caching/archiving costs. I can't quite put my finger on the implications right now, but I wanted to note that "JSON is a standard." doesn't mean much to me, since JSON is not comparable to HTML.

</comment></comment></comment></comment><comment><USER10> With the way websites work today surely the only possible way to build a search engine is to make something like a headless browser (similar to PhantomJS) that crawls the web like a user, seeing what the user sees, ignoring everything that's hidden from the user, and interpreting the importance of pages like a user would. Just parsing the HTML source of the page won't even get close to seeing the key features of a page any more.

Impressive work by Google to do that at scale, of course, but they'd be dead in the water if they didn't.

</comment><comment><USER11> But how! I don't know about other people here, but in our company we haven't figured out how to parse (for testing of course) dynamic websites. All tools, including free tools like Selenium and paid tools like QF-Test, seem to not be able to understand how it works, or our web developers are not able to code dynamic web like it should be coded.

<comment><USER10> I use nightwatch.js ( [http://nightwatchjs.org/](http://nightwatchjs.org/) ). It's a layer on top of Selenium that makes browser testing _a lot_ more straightforward. If you start with small, straightforward tests and build testable things from there you code _will_ improve.

<comment><USER11> The problem is that tester and developer aren't the same person. This way the tests are much better at finding expectations the developer didn't have, but it's harder to convince the developers to code more testable, because they don't know the pains of testing.

<comment><USER10> The point of testing is not to prove the code doesn't work. It's to prove the code does work. That subtle but important difference is the key to good testing.

Finding a problem with code is useful, but it's extremely limited. You might find 100 bugs, but if there's 101 bugs your product has the potential to fail completely. It's so much more useful to define a framework of things that the code _has to do properly_ and make sure it _does do them all properly_. To that end, testing should come first - define what the code needs to do, write tests to make sure it does those things (automated unit tests where possible, but at the very least well defined processes for how you make sure it works), and _then_ write the code to actually do it. Any developer who isn't interested in proving their code works, and will continue to work as it becomes more complex, is a _terrible_ developer.

tl;dr If you want to fix testing don't write any code until you know how you're going to test it works.

</comment></comment></comment></comment><comment><USER12> We wrote our scraper to use phantomjs via the selenium.webdriver interface in python 2, simply because for something like 80% of the sites we extract information from, the data was not fully available unless we could render the dynamic parts of the page. I am not at all surprised that Google's bot is executing js. I have assumed they could do this for years now.

As for pure html front-ends, I understand the attraction, but when a single js-based implementation gets you consistent behavior and presentation across all browsers and mobile devices the advantages are pretty huge.

</comment><comment><USER13> I've long thought that the need for a high performance sandboxed JavaScript VM was the real impetus for Google's investment in v8, and that Chrome was just a useful opportunity to leverage it and to get external contribution. Is there any evidence that this is the case?

<comment><USER2> Unlikely. I was using SpiderMonkey to execute JavaScript in Google's indexing pipeline long before I had heard about v8, and I doubt Lars had me in mind when he started on v8. Of course, I tele-conferenced with Lars before Chrome was released, but SpiderMonkey was still the indexing system's JavaScript interpreter on Chrome's go-live date.

<comment><USER13> Interesting. Thanks for clarifying that!

</comment></comment></comment><comment><USER14> I wonder how google indexes a page that inserts an element in the DOM 120 seconds after the page was loaded using a setTimeout()

<comment><USER15> They probably don't care about that content.

My first guess would be that they snapshot the DOM in the JS tick immediately after window.onload completes. Maybe they have a short pause to let any fast timeouts or callbacks complete, but there's got to be a cutoff at some point (e.g. to stop an infinite wait for pages that continuously update a relative date). Of course, with their own JS engine, I bet they can get really fancy with the heuristics to determine when to take that snapshot.

<comment><USER2> Actually, we did care about this content. I'm not at liberty to explain the details, but we did execute setTimeouts up to some time limit.

If they're smart, they actually make the exact timeout a function of a HMAC of the loaded source, to make it very difficult to experiment around, find the exact limits, and fool the indexing system. Back in 2010, it was still a fixed time limit.

Source: executing JavaScript in Google's indexing pipeline was my job from 2006 to 2010.

<comment><USER16> What about AJAX? Does it load/read/index data after the fact?

</comment></comment></comment></comment><comment><USER17> There is no doubt Google continues to get better at indexing client side rendered HTML but it is not perfect and indexing is not the same as ranking high in organic search. For ranking, there are distinct advantages to server rendering. The biggest one is consistent initial page load performance. Long story short, if you care about ranking and not just indexing, you still need server rendering.

</comment><comment><USER18> For people wondering about Ajax requests, Googlebot is performing them very well together with SVG rendering.

For example this URL:

[https://www.chemeo.com/predict?smiles=CCCC](https://www.chemeo.com/predict?smiles=CCCC)

is performing the drawing of the molecule using RaphaelJS, then pulling the corresponding molecule from the database using Ajax and updating the page. Googlebot is performing all the steps perfectly well to add the end index the page.

It is very annoying because this is not important in our case, what we want is the good indexing of the main data pages, not these pages... I do not want to block the bot yet, but I need to figure out a way to have the main page better ranked.

<comment><USER19> However, if you search on Google:

        "Property Prediction for Butane" site:https://www.chemeo.com

You'll see this page is not indexed.

<comment><USER18> Interesting, it looks like they massively dropped these pages from the index (or at least, from what they return as results) this is great (if they are not dropping other important pages)!

</comment></comment></comment><comment><USER20> Now, what kinds of V8 vulnerabilities can we exploit to get inside Google? Said every intelligence agency everywhere.

<comment><USER2> From 2006 to 2010, my primary role at Google was JavaScript execution in the indexing pipeline. I knew I was likely executing every known JavaScript engine exploit out there plus a good number of 0-days, and ran the javascript engine in a single-threaded subprocess with a greatly restricted set of allowed system calls.

Certainly the right combination of kernel zero-days and JS interpreter exploits could be used to take over the machine, but it would be non-trivial.

<comment><USER21> > ran the javascript engine in a single-threaded subprocess with a greatly > restricted set of allowed system calls.

You were trying to sandbox the JS engine rather than using disposable VMs?

</comment></comment></comment><comment><USER22> I'm just waiting for the first security researcher to exploit the googlebot.

<comment><USER2> My primary role at Google from 2006 to 2010 was executing JavaScript in the indexing pipeline (not exactly in Googlebot, but close enough). I knew I was executing probably every known exploit out there, plus a lot of 0-days, and took lots of precautions (single-threaded subprocesss with very restricted list of allowed syscalls, etc.). It's not perfect, but breaking out of the sandbox would require a kernel 0-day in the subsystem used by our sandbox, plus a JS engine exploit.

<comment><USER22> I think it goes without saying that no system is 100% safe. ;)

</comment></comment></comment><comment><USER23> Any idea how Google digests\consumes web pages while crawling? Does it take out all the html and store just the plain text? If this is the case then can you share some more info on how they are doing it?

I think there is no way they are going to scrap the websites as there are millions of them with each having their own structure.

</comment><comment><USER24> I get rendering HTML from JS, handling timeouts, even infinite scroll. But how in the world are they handling onMouseOver, and other mouse events? My best guess so far is reversing the code from the document.location events.

<comment><USER25> I think you are misunderstanding how this works. Google isn't "handling" any events at all, your webpage is. Google is instead the source of those events - it is simulating the role of a user.

So the bot loads your webpage into a headless browser and sends it a series of events to simulate a user interacting with it, and waits for navigation requests.

There is probably a whitelist of simulation behaviors:

      * mouseover, then click each <a> node
      * mouseover every pixel
      * mouseover, then change every <select> node
      * mouseover, then click every <button>
      etc...

Caveat: though I worked at Google when this work was being done, I was on a different team and don't have any inside knowledge - just speculating on an approach that would make sense.

</comment></comment><comment><USER26> Any idea whether this affects (randomized) A/B testing? I think that in the past, Google has simply ignored the dynamic test changes to the site's content. Now I'm not quite sure anymore.

<comment><USER2> For duplicate elimination, it's important to have deterministic execution of Javascript, for duplicate elimination. Getting several identical pages (with different URLs) in your search results is a really bad user experience.

As of when I left Google in 2010, the JavaScript random number generator always returned 0.5 (and some SEO figured it out and blogged about it, no secrets here). However, I was trying to convince my manager to let me instead seed a random number generator with an HMAC of all of the currently loaded HTML and JavaScript (to make it deterministic but hard to display something good 1 in a million times but 100% of the time to Google's indexing system).

</comment></comment><comment><USER27> If we can execute Javascript on GoogleBot, could it possibly be hacked/broken somehow? Surely there must be security vulnerabilities in its Javascript engine.

</comment><comment><USER28> It would be interesting to see how client-side templating affects SEO, namely now that we understand that JS is indeed executed by the crawler.

</comment><comment><USER29> I wonder if it does Ajax. Then you could do some kind of weird recursion where it does a request to google for itself.

</comment><comment><USER30> Google can even read frames! (sarcasm) It makes all other search engines look bad in comparison though ...

</comment><comment><USER31> Just remember that there is life outside of Google and by brushing it off you're stifling further web innovations.

Also, I wonder how Google handles security while executing random JS code. It's one thing to hack into a single browser. It's another thing to hack into a crawler. Think of all the possibilities.

</comment><comment><USER32> searchengineland hasn't tested AJAX as the author wrote in the comments: "That's a great question! Our test was to programmatically insert text where we wanted into the DOM, but not as a server side transaction, like AJAX."

<comment><USER33> I read another blog about someone who tested that (don't have the url, but it was easy to find), and their conclusion was that the crawler won't wait for any Ajax request to finish to let you render that content. If you want to render with Javascript, you need to make that data a part of the initial payload and render that data during onload.</comment></comment>


First Circuit Affirms Right to Record the Police - <AUTHOR> http://www.cato-at-liberty.org/first-circuit-affirms-right-to-record-the-police/ <comment><USER2> Thank goodness - there aren't many things that get my blood boiling, but this idea that police can arrest people for filming them really angers me. I saw a news clip about a woman filming the police from inside her own home and they arrested her. That seems abusive. People should be respectful, but I welcome this news that the courts are finally affirming their right to film public officials in public places.

</comment><comment><USER3> Here's yesterday's discussion of this: <http://news.ycombinator.com/item?id=2930417>

That was to this story: [http://www.universalhub.com/2011/court-says-state- law-bannin...](http://www.universalhub.com/2011/court-says-state-law-banning- recording-police-offi)

<comment><AUTHOR>
        	[dead]

Odd.</comment></comment>


Did we at any point say it was a nightmare developing on Android? It wasn't. - <AUTHOR> http://www.wired.com/gadgetlab/2010/10/androids-champions-defend-os-against-steve-jobs/

<comment><AUTHOR> Steve should of actually talked to Android developers of major apps before making these claims.

<comment><USER2> Why? Developing for Android is a pain in the arse, especially once you're done and testing in the field.

There are hundreds of devices, all different, all with their own bugs and all running different versions of the OS to deal with. This is J2ME all over again.

That doesn't mean it's impossible, it just means it takes longer. It also means you need to go out and buy a tonne of development/testing phones.

All of the above might be okay for people with money and/or investment, but makes it difficult for small developers. Let's not even begin to talk about the Android Market, supported seller/buyer countries, currency display, return policies, etc, etc.

Compare that to iOS -- Apple rolls out an update to the OS, it works on all devices, and they're all identical. There's far less testing required (version N, N-1), and far less hardware investment too. You pop your app up on the App Store and it all 'just works'. That's what Steve is talking about -- integration vs fragmentation.

<comment><USER3> Yeah, fortunately this is not how software works in practice. The best example is probably the PC market, which is fragmented to such a degree that the hardware permutations are uncountable -- and yet Windows, Linux, other major operating systems and applications all manage to deliver stable, consistent user experiences. The situation with Android is parallel: lots of different hardware, but basically still a "write once, run everywhere" environment. (Everywhere being any phone with a legit Android environment.) Similarly to when you're developing on a PC, you _occasionally_ need to know something about the specific hardware or version you're running against, but more often than not, you just code, and it just works.

<comment><USER4> Mobile is a different ball game. To start with, while hardware is more varied it's also got far more standardised input hardware - there's a keyboard and there's a mouse and you can rely on that being the primary input.

On Android there will be a touch screen, but it's size, resolution and accuracy will vary. There may be buttons but their quantity and makeup will vary.

The second factor is that you cannot get away with bad UI as much as you can on the desktop. On the desktop it's frustrating but survivable, on mobile it's a death knell.

It'd be more accurate to call it write once, run poorly everywhere.

</comment></comment></comment></comment><comment><USER5> CEO states rival product is worse than the one his business sells, Film at 11.

</comment><comment><USER3> How hard is it to run spellcheck before publishing an article for half a million readers?

      compile Android on a home Linux machin--a way</comment>


Design Patterns: Factory Pattern, Part 1 - <AUTHOR> https://henricodesjava.blog/2017/10/29/design-patterns-factory-pattern-part-1/ <comment><USER2> I wish new programmers weren't shown these "classical" OO design patterns without a corresponding functional pattern. Most of the time the corresponding functional pattern is "pass a function".

Most cases of a factory is basically a Func<Inputs, Output> type function definition. Now that all the big OO languages support it, I'd go for passing creator _functions_ around over defining factories, for nearly all use cases.

This approach works for nearly all the classical GoF patterns.

<comment><USER3> Are there any resources that you would suggest for learning about functional patterns?

<comment><USER2> This page has a few of my favorite resources. Especially the first set of slides there is great. [https://fsharpforfunandprofit.com/fppatterns/](https://fsharpforfunandprofit.com/fppatterns/)

</comment></comment></comment><comment><USER4> > NYCStyleCheesePizza

> ChicagoStyleCheesePizza

Chaining M by N adjectives together to form a type hierarchy is a design smell. Odds are, you just need to add 'toppings' and/or 'style' members to your structure.

But, to praise the Factory pattern, you can walk back your gratuitous class hierarchies if the concrete class name is an implementation detail of your code.

</comment><comment> Const-me There're too many classes (and too much code in general), coupled very tightly to each other.

The example code is very error prone. These string item names are easy to mistype, the compiler will OK that, if you're lucky you'll find a runtime error, otherwise you'll introduce the bug. Enums are usually better.

That "code likely/unlikely to change" stuff is just a guess. If neither of them changes, the proposed approach introduced a lot of complexity for no value. But if the "code likely to not change" ever changes (e.g. extra steps dependent on pizza or store), the proposed approach won't work at all, it's either redesign or hacks.

Personally, 80% of times I used factory pattern was while implementing deserializers (esp. in C++ that lacks reflection). The other 20% is when I instantiated concrete classes based on come config values of user input. Oh, and all my class factories were just functions, there's no need for separate factory classes.

</comment><comment><USER5> I always wonder: these 'patterns', do they simplify programming for beginners? What are they for, really? Why is there a whole set of standard patterns even with standard names that people find useful? Do they really find them useful?

It seems simplistic to me to cut the world into pieces of 'if you have this problem, you solve it with this pattern, dude.' Isn't this missing the point of really understanding the problem? Especially because (a) the problems are usually not exactly like (so often applying a standard pattern makes the code overengineered) that and (b) the proposed pattern often more reveals the limitations of the underlying programming language, so why is that not mentioned in the motivation of that pattern? Like the 'visitor pattern' \-- does any pattern intro tell people that this exists only because Java and C++ have no multiple dispatch? Does is not just awkwardly implement what is naturally expressible in, say, Julia or CommonLisp. Yet I've never seen this as an explanation for that pattern.

For the excessively applied 'factory pattern', it even has it's own jokes: Java, the language without verbs (or, only with 'run()' and 'do()').

Instead of having a simplistic cookbook of patterns, would it not be wiser to teach programmers about problem analysis and programming languages?

TL;DR: I don't understand 'patterns'.

<comment><USER4> > Like the 'visitor pattern' \-- does any pattern intro tell people that this > exists only because Java and C++ have no multiple dispatch?

It's not exactly a secret. The Double Dispatch wikipedia page has a visitor section: [https://en.wikipedia.org/wiki/Double_dispatch#Visitor_patter...](https://en.wikipedia.org/wiki/Double_dispatch#Visitor_pattern)

> Java, the language without verbs

Right. But in the C++ standard library, they use a version of the factory pattern (see make_shared) to allow for some optimizations and nicer syntax.

Separating some construction options from the class definition itself allows for more separation of concerns with no real loss to encapsulation.

> I don't understand 'patterns'.

I mostly agree that patterns help you work around language limitations. Though having names for concepts is generally helpful to help move the state of the art forward. There are "sidecar", "proxy", and "broker" patterns in system design. If we didn't have those, we'd have to reinvent prose every time we were describing those maneuvers to our coworkers and (even harder) strangers in the industry.

<comment><USER6> Visitor pattern isn't just used to overcome language limitations. In Rails it's used to dynamically generate SQL statements for different databases.</comment></comment></comment>


Ask HN: HN Meetup in Barcelona? - <AUTHOR>

Hi all!
Me and my co-founder are working from Barcelona in a nice little office at Port Olimpic  (https://www.google.com/maps/preview#!q=Carrer+Escullera+de+Poblenou%2C+Barcelona%2C+Spain&data=!4m10!1m9!4m8!1m3!1d23059125!2d-95.677068!3d37.0625!3m2!1i1280!2i679!4f13.1) and we would love to meet some HN folks from or currently residing in Barcelona
Is there interest for an HN Meetup in Barcelona? Also let me know if you're interested in giving a small talk or something similar. We could host a bunch of people in our office in the evenings! <comment><USER2> I'm in Barcelona too, and if you guys set up a meeting in the evening I'll definitely come!

contact in my profile.</comment>


Barely scraping by with a $250,000 salary in Silicon Valley - <AUTHOR> https://medium.com/@lucasroitman/barely-scraping-by-with-a-250-000-salary-in-silicon-valley-d2b5d665c1c0 <comment><USER2> This works as satire, the subtle point being that "barely scraping by" should not be equated with owning a 2-bedroom home and working toward a Stanford MBA just 4 years out of college.

That said, someone complaining they are having a hard time with $100K from Facebook isn't hard to believe, depending on circumstances. I'm reminded of the story about Menlo Park firefighters making well above $100K but being unable to live in Menlo Park: [https://news.ycombinator.com/item?id=11367881](https://news.ycombinator.com/item?id=11367881)

<comment><USER3> Insane as the SV real estate situation is, you're going to definitely have to throw kids into the mix for $100K to land you in the "scraping by" category. Anyone who's single and can't "scrape by" on $100k (or even a far lower figure) simply lacks imagination.

</comment></comment><comment><USER4> _" Edited: Way too many people haven't noticed this is satire. I've seen an article on Facebook claiming $100k isn't enough to live in the valley, and then another one claiming $130k isn't enough. Then there's another Twitter employee complaining with $160,000.I wanted to make a hyperbolic next step to show the stupidity of those articles. There are service workers living with $10k or less. Working in tech, you should be fine with your salary. Stop complaining."_

I understand this is intended as satire, but I don't think it succeeds on that basis.

Hyperbole based satire certainly can be used to reveal an absurdity, but sometimes the hyberbole involved in satire is exactly what turns a reasonable position into an absurd one. Although it is true that people make it in SF on less than 100k a year, I don't think it's reasonable to use a satire based on a single person earning 250k a year to tell people who earn 100k that the should be happy and stop complaining.

I noticed that this analysis left out childcare. A quick google search shows that the average cost of childcare per month is 1,900-2,400. If you want the kind that allows two people to work full time, 2,400 isn't a bad deal.

You also need housing, especially if you have two kids. That's going to be expensive. It's very unlikely you'll get this for less than $2500 a month in rent.

As for not complaining... honestly, most of the people I know with kids in SF and are hard up for money don't complain much, they get on with it. It's the Silicon Valley tech _employers_ who constantly complain about hiring woes. These companies often refuse to allow remote work or find a way for workers to live in places where 100K would be a wonderful salary for a family.

As far as I see it, it's those companies that are constantly complaining to congress about a shortage of workers.

</comment><comment><USER5> The recent article edit helped:

 _" Edited: Way too many people haven't noticed this is satire. I've seen an article on Facebook claiming $100k isn't enough to live in the valley, and then another one claiming $130k isn't enough. Then there's another Twitter employee complaining with $160,000. I wanted to make a hyperbolic next step to show the stupidity of those articles. There are service workers living with $10k or less. Working in tech, you should be fine with your salary. Stop complaining."_

<comment><USER6> None of this changes the fact that Silicon Valley is, in fact, ludicrously expensive. Knocking someone down for alleged hypocrisy or naïvety may instill a temporary feeling of moral superiority but emphatically does not actually change that fact.

</comment></comment><comment><USER7> Nice satire, but to truly be on point he needs to do the kind of willfully- ignorant accounting that claims someone maxing out their 401(k) and putting another $40k/year into a retirement account is "after expenses, left with no extra money at all".

<comment><USER8> I have read a few that say "after regular expenses" and then go own to include: "$60k towards Roth/401k" and "three vacations a year"

After that..I'm only left with $17,000 for entertainment.

<comment><USER9> Wait, how do you even PUT 60k in a Roth/401k in one year?

You're capped at 18k for the 401k, and you're capped at 5.5k for a Roth IRA, assuming you're under the income cap to contribute to the Roth in the first place. If you're doing a Roth for your partner as well, that's another 5.5k.

So if you and your partner both max out your 401ks, that's 36k per year, plus another 11k for the two Roths to make 47k going to retirement savings.

Is there another vehicle for retirement savings that I could be dropping money into, aside from my Roth IRA, my wife's Roth IRA, and my 401k?

<comment><USER10> You can do a backdoor Roth IRA contribution. It has no limits.

<comment><USER11> That is incorrect. Conversion from traditional to Roth IRA has no limit. Contribution limit is $5500 per year regardless backdoor or not.

<comment><USER12> It's a well-known trick across googlers....

1\. IRA Backdoor: Contributed to traditional ira with after tax money, capped at 5500, then converted to RothIRA

2\. After-Tax 401k Mega Backdoor: Contributed to After-Tax 401k, capped at 26K, then converted to RothIRA.

</comment></comment></comment></comment></comment></comment><comment><USER13> That was really very, very subtle satire. Maybe it's a little sad that it was entire believable!

<comment><USER14> It's sad and hilarious because it's true. Some people are blowing 60+k/year dining out.

</comment></comment><comment><USER15> Well done, I read all the way to the end thinking "Wow, he is setting himself up for some serious backlash"

</comment><comment><USER16> I wonder why SF/Peninsula SV knowledge workers have an expectation to live large at salary $X when many of their colleagues/friends are making just as much, whereas Manhattan New Yorkers do not have an expectation to live large making great money in absolute terms but still making relatively "average money" wrt relative income.

I suppose one hypothesis is that the region has yet to come to terms with how widespread high earning power in absolute terms (but not on relative terms) have become.

<comment><USER17> I think it's two things: the influx of young professionals who suddenly have lots of expendible income, and the fact that NYC has a very clear pecking order. I make a very comfortable living in NYC but there's still the "old money Central Park" crowd and the "lunch at Dorsia" crowd to remind me where I stand.

</comment></comment><comment><USER14> I'm bootstrapping on 9.5k/yr. It's doable. Which means I should probably stop all this startup "nonsense" and make more working a $250-300k salary and be a multimillionaire within a decade.

The majority of people choose to eat out every meal, subscribe to a bunch of memberships they use very little, redecorate with new furniture every few years, go to the movies every weekend, take a vacation with excursion$ and so on.

Spending or saving money is a choice, just like one's diet or anything else.

<comment><USER18> I did the big company route for a few years out of college and without even trying very hard, had something like an 80% savings rate. To be fair, this was a few years ago, so rents were better, but I live in an excellent location in the heart of the city and even _doubling_ my rent would leave me with a super high savings rate. I knew people making half as much as me and spending twice as much, and I'm truly baffled as to how they managed to do so. Especially since I have a weakness for (among other things) good food and beer: even if I did it regularly, spending $30 on a good beer hardly makes a dent in the kind of numbers we're talking about.

</comment></comment><comment><USER19> > My taxes are of 15%, because I get paid in capital gains, through equity.

I know this is satire, but out of curiosity is it really possible to be paid 100% in stock (and then just sell however much you need to live immediately)?

<comment><USER20> Even if it was, you still pay regular income tax on stocks which are given to you.

<comment><USER21> Get an individual patent and get arrange to get paid via royalty licensing. As I understand it, this is all long term cap gains. However. I am not a lawyer or a tax advisor.

<comment><USER22> a quick Google shows that royalties from patents are taxes as ordinary income.

</comment></comment></comment></comment><comment><USER23> What's wrong with living in a trailer for a year and banking 200k?

Nice satire.

All he talks about are buying liabilities (pool, car, entertainment, renting, filling big house with shit you don't need).

Imagine if he talked about assets instead (ETF's, rental property, and starting his own side hustle corporation).

He's rich, but far from wealthy.

</comment><comment><USER24> Admitted clickbait BS, could use a downvote for this one.</comment>


Why did Koum leave WhatsApp? - <AUTHOR> https://www.theguardian.com/commentisfree/2018/may/06/whatsapp-founder-sends-facebook-users-coded-message <comment><USER2> My guess:

1\. Most of the stock vested 2\. FB mafia is moving in and there's no stopping it

Educated guess from watching several acquisitions slowly disintegrate (though not at FB)

</comment><comment><USER3> I'm more curious about why Gundotra left Google. Hopefully that story will be "declassified" some day.</comment>


List of top internship offers (Bay Area + NYC) - <AUTHOR> https://twitter.com/tzhongg/status/536565474041937921 <comment><AUTHOR> These are incredible. First, a caveat: _these are internship rates, not yearly salaries, for top school students. Yearly values seem to be lower for FT employees._ Also, if you see the FB thread below, students discuss rates for the top 10% of their class vs. non-10%, and it sounds like they differ.

Some comments from skimming the responses:

I agree with another commenter: rates are _really_ increasing. Internships in NYC were at $5-6k 3-4 years ago.

patio11 is right: this is a reminder to raise your rates.

This Facebook post has more details on internship and entry-level rates for top school grads:

[https://www.facebook.com/groups/hackathonhackers/permalink/9...](https://www.facebook.com/groups/hackathonhackers/permalink/915111391877680/)</comment>


Odoo Studio: build business apps in minutes - <AUTHOR> https://www.odoo.com/page/studio <comment><AUTHOR> And here is the youtube video to see it in action: [https://www.youtube.com/watch?v=xCvFZrrQq7k](https://www.youtube.com/watch?v=xCvFZrrQq7k)</comment>


iOS 11 bugs are so common they now appear in Apple ads - <AUTHOR> https://www.theverge.com/2018/3/16/17131148/apple-ios-11-bug-face-id-ad <comment><USER2> I know a lot of the comments are saying what a bad example. And how trivial it is. But it's a clear illustration of Apple's lack of attention to detail now. I dare say there was a time when Apple would never have published such an advert. Likewise there was a time they would never publish software with the embarrassing bugs we have seen through macOS and iOS.

<comment><USER3> _> Likewise there was a time they would never publish software with the embarrassing bugs we have seen through macOS and iOS._

When was this?

Remember Snow Leopard? The release The Internet likes to parade as the Last Good OS X Release? It had a bug where your all _user_ data will be deleted if logging into the Guest account. Here's a headline from the time: Snow Leopard Bug is a Doozy, How Did Apple Miss it? [1] Sound familiar?

Or in _2010_ (and all the times after) when they couldn't get DST right and would screw up people's alarms.

[1]: [https://www.cio.com/article/2423952/security0/snow- leopard-b...](https://www.cio.com/article/2423952/security0/snow-leopard-bug- is-a-doozy--how-did-apple-miss-it-.html) [2]: [https://www.cultofmac.com/60691/ios-alarms-broken-for-new- ze...](https://www.cultofmac.com/60691/ios-alarms-broken-for-new-zealand- users-after-daylight-savings/)

<comment><USER4> That bug didn't appear in an advertisement. The point isn't that Apple is making mistakes (they always have), it's that they're bad enough at even noticing the mistakes that one was able to slip into an ad.

<comment><USER5> The ad is from ATT, not Apple.

<comment><USER6> wait what? the ad in OPs article is definitely from Apple

</comment></comment></comment></comment></comment><comment><USER7> But actually aside from the example in the article being rather silly I believe that something we could learn from this as developers is that in some situations it might be valuable for us to record our monitor with a high speed camera and look at it slowed down.

This mainly has value for game development I think, but other programs that feature a lot of animation could benefit from it as well.

When I say "high-speed camera" you might think of cameras that cost in the range of hundreds of thousands to millions of dollars but actually from what I've seen on YouTube even a camera that would capture some hundred FPS could provide interesting insight. Preferably at a not too low resolution though. Some cameras like that exist for the price around some hundreds to under a couple of thousand dollars. It might be worth looking into. And let me know if you find one that seems especially good and with not too big of a price tag because I am looking too and haven't found quite the perfect one yet.

Btw it probably helps if you have some other intended use for the camera as well like for example to take photos and pictures of things in the nature.

<comment><USER8> I normally write my CSS transitions [1] at 3-5x the time they will be in the final version. So if I intend for `transition: all .3s ease`, then I'll write `transition: all 1s ease` and test it like that. I actually try different speeds, first a decent one (2-3x) not to be slowed down and then a slower one (~5x) to make sure it is works as intended. I've found this much easier to debug and find issues.

The only problem with this approach is that, since you are making things in slow motion, it's easy to over-animate things and make it look messy on normal speed. So just compensate for that and everything is fine.

[1] example: [https://picnicss.com/](https://picnicss.com/)

<comment><USER9> Chrome's devtools let you set all animation to run at at 1/4 or 1/10 speed, simplifying that process a bit.

[https://developers.google.com/web/tools/chrome- devtools/insp...](https://developers.google.com/web/tools/chrome- devtools/inspect-styles/animations)

</comment></comment></comment><comment><USER10> So I thought people were exaggerating but something I recently found that is _weird_ is the time slider not progressing for music/podcasts playing while on the lock screen. I thought it's just when you play something out of Safari but it's also happening with the official music app? Like what the hell?

<comment><USER11> Seconded. It _does_ reveal the right playhead once Face ID unlocks the screen. Perhaps playhead position is sensitive info?

</comment></comment><comment><USER12> Me personally, I've had less issues with iOS 11 than with previous iterations and I'm happy overall with wit iOS 11.

Is the data (say, normalized number of issued bugs) really showing a decrease in reliability of iOS over time or rather the contrary?

Not an Apple evangelist here, but it would be good to be fair.

Let's please remember that often a few loud voices are just that, loud, but few.

<comment><USER13> iOS 11 is by far the buggiest iOS release in my experience. I have multiple devices and I held off as long as I could to upgrade my main device after seeing the myriad of bugs on my other devices. They broke the touch screen. Even clicking on buttons isn't reliable anymore, never mind the keyboard issues. Speaking of which, they also broke the keyboard in iOS 11. Typing is almost as bad as old Android.

IMO, it all went downhill after the "flat" iOS 7 release. It was unstable beta software then, and it's still unstable beta software now. Apple would rather add Animoji than fix these long standing iOS 7 bugs.

<comment><USER14> > They broke the touch screen. Even clicking on buttons isn't reliable > anymore, never mind the keyboard issues.

What keyboard issues? The symptoms described sound like a hardware problem.

<comment><USER15> Not the poster you replied to, but the keyboard is ridiculously slow sometimes. It can take a second or so for letters to echo until the keyboard code warms up its cache, or whatever it's doing immediately after it is displayed.

I've also noticed that I sometimes have to click the fingerprint sensor 4-5 times to get the pin screen to display. Clicking works reliably once the phone is unlocked.

They definitely broke the touch screen on iPhone X, at least during winter weather. They had a point release of iOS where that was one of the headline bug fixes.

<comment><USER14> > It can take a second or so for letters to echo until the keyboard code warms > up its cache, or whatever it's doing immediately after it is displayed.

This is rare but it also goes back to the earliest iOS releases. Once background apps became possible swapping became common, especially since most people just enable it for every app which asks.

> I've also noticed that I sometimes have to click the fingerprint sensor 4-5 > times to get the pin screen to display.

This also sounds like memory pressure. It doesn't happen normally even old older hardware.

</comment></comment></comment></comment></comment><comment><USER16> A few months ago I've bought an iPhone for testing and development. I've used it for a few days total, yet I can already count something about a dozen of UI glitches I've found just by using it, and one severe stability issue with underlying frameworks. It looks really untidy.

</comment><comment><USER17> I don't know iOS inernals, but to me it looks like they started using multiple threads for the UI? Smart when you want to update multiple areas of the screen at once, buggy when multiple areas have to sync animations?

<comment><USER18> >I don't know iOS inernals, but to me it looks like they started using multiple threads for the UI? Smart when you want to update multiple areas of the screen at once, buggy when multiple areas have to sync animations?

iOS has always used separate threads for UI rendering standard since GCD was added in iOS 4. This is just lazy mistakes and poor QA.

<comment><USER19> I'm pretty sure that iOS renders UI on a single thread? You can't even create UIImageViews off the main thread without risking severe breakage. Fortunately, modern Xcode has an Analyze option that will flag attempts to access UI off the main thread.

GCD is a nice API for scheduling async tasks but that doesn't mean those async tasks can access UIKit or OpenGL contexts safely?

<comment><USER20> Correct, you need to do everything that touches the UI on the main thread. But I never ran into problems that it would lead to frame drops, scrolling frame drops are because too large calculations are done (especially on the main thread) while displaying a new cell. I don't say it's trivial always to do complex stuff in a non-blocking way but if I can do it probably somebody working at Apple can do it too.

</comment></comment></comment></comment><comment><USER21> for any ad, I'm sure the editor and the final stackholders are going through every scene in detail, those frames showing the text message on the lock screen, I'm sure has been viewed hundreds of times by multiple people. Yet no one thought that the UI was weird with that messed up animation?

</comment><comment><USER22> You know what's funny? The base premise of the ad would be that you can unlock anyone's phone with your face. In the ad she is unlocking everything, even those that do not belong to her. How could they miss this?

<comment><USER23> Yeah, from where I sit, sure—maybe this UI thing is a glitch, maybe it's to preference readability, have to assume it's a glitch because it doesn't look good. But really, the problem for me is that the ad itself is a colorful simplistic mess.

And am I the only one who finds it infuriating that the timing in other parts of the ad is off? At one point one of the cars bursts open before she looks at it. If you're going to follow through on this concept, IMO it really needs to be frame-level precision.

<comment><USER24> The whole thing is stupid. If I look at my phone, does that mean I want it unlocked? Not really.

</comment></comment></comment><comment><USER25> I think this yearly new iOS release schedule is really wearing on the quality of iOS, although its still leagues about Android its just not high quality as it use to be. iOS11 has been riddled the bugs and bad design. Apple in general seems to be suffering from this as High Sierra has also been a cluster fuck.

<comment><USER26> Have you tried stock Android lately.

I just switched to a cheap (<$300) Android phone from an iPhone and it's been better in every way except the camera. iPhone used to be miles ahead of Android, but the lack of product focus and the decreasing attention to detail at Apple have allowed Android to catch up.

One example: my iPhone shit the bed recently and I tried factory resetting it. In the OOBE, I had to enter my Apple ID credentials and do two-factor auth 3 separate times. Apparently the different screens were implemented by different teams and didn't share the authentication context. I only had to sign in to my Android once.

</comment></comment><comment><USER27> Shitty animation no one notices is nothing to worry about.

Those utf8 bugs that kill your phone on the other hand... How many of those had Apple had by now?

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

<comment><USER28> > _Shitty animation no one notices is nothing to worry about._

Jobs would've had a seizure at this statement.

<comment><USER29> I think it may even be a way to raise the dead.

This is how we get a fire-breathing ZombieJobs stomping on Cupertino.

</comment></comment></comment><comment><USER30> Is it possible that the multiple bugs in iOS 11 could be attributed (in part) to the frustration felt by Apple's engineers about the open office floor plan in the new campus?

<comment><USER31> no.

(not least because they didn't move in until a good while after ios 11, which was released a good year after the development was heating up the most.)

</comment></comment><comment><USER32> Has anyone considered the possibility that this isnt a bug?

<comment><USER33> This is more of a jank: [https://medium.com/@nathangitter/designing-jank-free- apps-9f...](https://medium.com/@nathangitter/designing-jank-free- apps-9f66d43b9c87)

</comment></comment><comment><USER34> People think that this is a bug. But it's not. The way it is rendered helps actually people to read the message faster. This was proven in studies.

<comment><USER35> I'd be inclined to agree if it weren't showing dark colored text on a dark colored background.

</comment></comment><comment><USER36> Frankly, after the misguided whimsy of "what's a computer?" I don't expect much from them.

(It was the first Apple ad to mock a segment of its own customers, as opposed to mocking competitors' customers, a dubious but established marketing strategy)

</comment><comment><USER37> I thought it was impossible, but I guess those that said that Apple without Steve Jobs would go to waste were right.

They won't go bankrupt anytime soon, but it's not the same Apple.

I've personally switched to PC with Xfce after a few nightmarish 6 months with the new MacBook Pro...

</comment><comment><USER35> Oh no, not a glitch that needs to be slowed down about 10 times to be anything more than unnoticeable. Those are the worst!

</comment><comment><USER38> So it is visible for like 50 milliseconds during the animation and not at all looks bad when you actually see the animation happening in real time.. Yeah, APPLE IS DOOMED!

I'm not creating excuses but this is ridiculous. As if there is a shortage of Apple stuff to complain (like shitty mbp keyboards breaking all the time, siri the moron, fucked up security issues popping up weekly..) this is making headlines.

<comment><USER39> I've been developping ios apps since ios 3, and i can't tell you how glad i am to see this apple media bashing trend. They build the most expensive products, lock you in using their tools and their hardware, take a 30% cut on all income, rejects apps for very very various reasons, some of them borderline illegal (like the competing with apple apps clause), and they're the most profitable company in the world.

AND, their software quality has been declining for the last 4 years without any sign of them taking notes. So, yeah, please more shitstorm, someone needs to shake something inside, because a whole ecosystem of businesses (like mine) has been built relying on their product being flawless.

<comment><USER40> I will not argue against your experience. I had my share of problems with iOS (and Android and really any large enough piece of software).

Two points though. As someone living in the wrong EU country to sell apps on Play store I am far less bothered by Apple's 30%. I would certainly welcome that percentage to be lower and have more flexibility on the platform itself, but it is not a particularly offensive number when compared to any other industry where you need a distributor.

Second, do you really rely on any product to be flawless? To me that seems an unreasonable position to have.</comment></comment></comment>


Node.js modules you should know about: dnode - <AUTHOR> http://www.catonmat.net/blog/nodejs-modules-dnode/

<comment><USER2> If you're interested in dnode you should also check out hook.io <https://github.com/hookio/hook.io>

It uses dnode to essentially let you build an auto-discovering message bus. I recently started using it and so far its been an amazing way to build up small independent services. With almost zero configuration the services can boot up and start talking to each other. It even works in the browser.

<comment><USER3> It's not clear to me what this offers exactly beyond events, which are easy enough in socket.io. And dnode allows very free-style form of RPC where you can have an event/call pass a function that then can be called from the other side.

What is it that makes hook.io exciting?

<comment><USER4> hook.io isn't about client server communication. It's about seamless mesh communication with high fault tolerance. The browser is just another end point.

<comment><USER3> I don't quite understand this from the documentation I'm reading. Doesn't high fault tolerance require automatic failover of some sort that goes beyond broadcasting the messages to all Hooks? For instance, if you want to send an SMS robustly are you supposed to have multiple SMS listeners? And if so, how do you avoid sending multiple messages without some sort of ACK or message queue?

</comment></comment></comment></comment><comment><USER5> Not to diminish substack's huge achievements, but we used dnode on a project and finally went back to just using socket.io as it worked way better.

The latest socket.io releases have added a lot of features (node client, rooms, ...) that make libraries like dnode less useful imho.

<comment><USER6> I came across a really nice socket.io benchmarking tool @ a node.js hack event last night ... <https://github.com/mixu/siobench>

Quite a nice ecosystem forming just around socket/engine/hooks io's

</comment></comment><comment><USER7> I think I understand the remote procedure call concept, but could someone explain how I'd want to use this if I were building a web app?

Would this replace a lot of my ajax calls or... ?

<comment><AUTHOR> Yeah! You can use dnode on the browser. You'd then be calling functions in your code, which would get executed on the server side. All transparently. No more explicit ajax calls.

Just write a server.js:

        var express = require('express');
        var app = express.createServer();
        app.use(express.static(__dirname));

        app.listen(8080);
        console.log('http://localhost:8080/');

        // then just pass the server app handle to .listen()!

        var dnode = require('dnode');
        var server = dnode({
            zing : function (n, cb) { cb(n * 100) }
        });
        server.listen(app);

And whip up an index.html:

        n = ?

Then just run the server.js:

        $ node server.js

And navigate to <http://localhost:8080>!

<comment><USER8> "You'd then be calling functions in your code, which would get executed on the server side. All transparently."

Transparent RPC is an anti-pattern, not a benefit. <http://news.ycombinator.com/item?id=2318249>

</comment></comment></comment><comment><USER9> I really liked using dnode, but I had serious scalability problems with it. I didn't have time to look too closely, but I found quite significant latency between sending/receiving messages to the extent that I just downgraded to using socket.io directly and was quite happy. Sorry to be vague, but it's been 8 months since I experienced the issue.

Definitely, give dnode a go. It's a lovely piece of software, but keep an eye out for performance issues.

<comment><USER10> Same here, we had to abandon usage of it in favor of a simple json-tcp bridge. We were looking at 100ms+ for communication between two ec2 instances; with straight tcp it was closer to 7ms.

</comment></comment><comment><USER11> Taken to the next level:

<https://github.com/tblobaum/nodeQuery>

</comment><comment><USER12> Is this in some way significantly better than using normal REST APIs to communicate? It seems to me like we've been through various RPC's in the past (SOAP, XML-RPC, etc.) and REST has generally proven the simplest and most interoperable solution for APIs. Unless you have a need to really optimize and tweak the performance.

</comment><comment><USER13> I just built a browser version of the Redis client using dnode, to test it out. Fun and easy to use, and preferable to AJAX. Probably won't replace socket.io where I use it, but could be the foundation for CMS type apps.

</comment><comment><USER14> That does it! I am getting into node.js!

What should I read?

<comment><USER15> The Node Beginner Book is excellent. <http://nodebeginner.org/>

I've read it twice. I suggest doing the examples as you read along with the book, and then improve on them (there is room for improvement in the code architecture).

After that there is a list of other such tutorials here: [http://www.readwriteweb.com/hack/2011/04/6-free-e-books- on-n...](http://www.readwriteweb.com/hack/2011/04/6-free-e-books-on- nodejs.php)

</comment></comment><comment><USER16> is this similar to now.js?

<comment><USER17> no, now.js is similar to dnode. an even better analog is that now.js is more like a commercial version of socket.io</comment></comment>


Platform of the future - <AUTHOR> http://neugierig.org/software/blog/2011/09/platform-of-the-future.html <comment><USER2> It is definitely an interesting article I disagree with a couple of bullets, but it is mainly because of "the programmer circle I hang out in".

I am also worried, just like the author, about the future of the development platform. I am all "pro-cloud" now, but most of my day is spent working in my desktop. So my full experience is really based around my current desktop platform.

I am very disappointed on what Apple is building and the direction they are going. Linux seems to keep following somebody. They stopped following Windows and now they are following Apple (Specially Gnome). (This is exactly why Linux never gets a leading role.) Windows is the best platform right now for me, but that is really not a lasting option since it seems Microsoft also decided to go the Apple way.

I actually love Touch interfaces and tablets, but the problem I have with the direction everybody is taking, is not about touch interfaces is about limiting the user's options, is about killing the power user. It seems now that in Lion to do simple tasks, you are required to swim among a sea of hidden menus. The same goes for Gnome3, which is really a big disappointment.

It seems the industry is focused on forgetting about the power user. I guess we are definitely becoming extinct.</comment>


Tell HN: Somebody build this (Google Answers) - <AUTHOR>

Google Answers was awesome. It was a fantastic service that gave you access to high-quality researchers at a fair price.
It's not a super-high-margin business I'm guessing, and it doesn't scale well, but it would be a great lifestyle business I think.
Perhaps you contract with PhD candidates throughout the world. They're smart, they're great at research, and often they are getting paid like $15 an hour-ish (obviously this varies a TON depending on where they live in the world).
So a customer pays anywhere from $15 - $500, depending on the quality of research they want. 80% of that goes to the researcher, and the service keeps 20% to pay bills and turn a profit.
It seems like to start you'd just need to find a handful of smart people (PhD's is one idea, maybe there are other ways, perhaps even just smart people from communities like HN etc.) that were ready to take the jobs. RentAResearcher.org and .net are both available.... would love to see this built. <comment><USER2> Have you thought about doing it yourself?

<comment><AUTHOR> I am focused on another startup idea.</comment></comment>


Among the 200 top CEOs, median compensation jumped 16 percent. - <AUTHOR> http://www.nytimes.com/2013/06/30/business/an-unstoppable-climb-in-ceo-pay.html

<comment><USER2> The interesting bit are the new metrics proposed for company performance, in page 2, after the first paragraph ( [http://www.nytimes.com/2013/06/30/business/an-unstoppable- cl...](http://www.nytimes.com/2013/06/30/business/an-unstoppable-climb-in-ceo- pay.html?pagewanted=2) )</comment>


Joseph Menn on the Cult of the Dead Cow - <AUTHOR> https://decipher.sc/q-and-a-joseph-menn-on-the-cult-of-the-dead-cow <comment><USER2> Space Rogue also posted a book review. [https://www.spacerogue.net/wordpress/?p=723](https://www.spacerogue.net/wordpress/?p=723) TL;DR "Great story, but not a history book."

</comment><comment><USER3> Beto O'Rourke was in the Cult of the Dead Cow! This is the biggest reveal in the history of HN, or SlashDot, or maybe since Phrack.

<comment><USER4> I agree, it is very interesting. Here's a longer article about it from a couple months back.

[https://www.reuters.com/investigates/special-report/usa- poli...](https://www.reuters.com/investigates/special-report/usa-politics- beto-orourke/)

</comment></comment><comment><USER5>
       _   _
      ((___))
      [ x x ]
       \   /
       (' ')
        (U)

</comment><comment><USER6> Argh, I hate to be "that guy" but when there's such an obvious typo in the first paragraph it really cheapens the appeal of reading the rest of the text.

If they haven't even proof-read the thing before publishing then I'm going to (likely incorrectly) assume that attention to detail has been overlooked in other areas too.

<comment><USER7> I understand your position, but I think 'L0pht' is how they actually spelt it, instead of 'Lopht'. </s?>

<comment><USER8> This is correct.</comment></comment></comment>


New app vows to expand 'human potential through positive reinforcement' - <AUTHOR> http://www.itworld.com/mobile-wireless/290164/giving-your-goals-and-aspirations-big-lift

<comment><USER2> Now this is a great idea.

<comment><AUTHOR> I agree!</comment></comment>


GM's Volt: The ugly math of low sales, high costs - <AUTHOR> http://www.reuters.com/article/2012/09/10/us-generalmotors-autos-volt-idUSBRE88904J20120910

<comment><USER2> The article seems to confuse the development costs and the marginal costs of production, which are two very different things. The marginal costs are estimated at $20K-32K per unit for a car with a base price of $40K, so the idea that GM is losing money on each Volt is simply wrong. The way they get there is to burden the first model year with the entire development cost, which of course is absurd even for a normal car. It's even more absurd for the Volt, which represents a strategic investment in an entirely new automotive platform, an investment that GM absolutely had to make if it wants to be around 20 years from now.

Rest assured, every Volt GM sells is a positive for the company.

</comment><comment><USER3> I don't know if there's a name for this, but a company can be in the position of clinging to the past to its detriment (as many U.S. car companies are famous for doing), or be so far ahead of the technology curve that they have a hard time building and selling what in 20 years will be commonplace, to its detriment (in the present).

Electric cars are an obvious evolutionary step in car design -- I think there's general agreement about that. But they won't seriously eat into the market for internal combustion cars until a handful of problems is solved -- battery performance and lifetime, charging issues, infrastructure.

For those ahead of the technology curve, the advice is to be patient -- technology will catch up. For those behind, the advice is to rely on a shrinking pool of loyalists for your outdated technology. Only one of these actually makes sense.

<comment><USER4> "Outdated technology" is a hard thing to say.

Focus on energy/mass ratio.

That is the main constraint.

Petrol is not "outdated" on that metric.

For good or bad.

<comment><USER3> > "Outdated technology" is a hard thing to say.

On the contrary, it's very easy to say, and sometimes even to identify.

> Focus on energy/mass ratio. That is the main constraint.

If that were the only issue (and you're not saying this), we would drive cars with little nuclear reactors in them. Reactors like the one powering Curiosity on Mars right now, but a little bigger. That would give "hot rod" a whole new meaning.

> Petrol is not "outdated" on that metric.

True. It is in every other way. I agree that electric cars have an uphill struggle against the petroleum economy, and it will be a while before electrics offer the performance we're accustomed to from gas-powered cars -- assuming that ever happens.

<comment><USER4> And by say, I imply of course "truthfully".

While you merely do so _Trivially._

But sleight-of-hand aside:

You're talking about an N dimensional problem

Without reference to N or which dimensions are most important.

Extending one dimension: energy/mass, threshold cost,... N

That that N2 fails your nuclear reactor. Electric still silly. etc, but now on 2 dimensions.

I'm not a schill for dino power.

But "It is in every other way..." is vastly comical.

Recall, Churchill _created_ the petroleum economy.

Why did he do it? Energy to Mass.

He replaced coal with diesel oil to power the entire British navy.

This was ca 1910.

Only then, was the petrol infrastructure built in EMEA.

It follows, that this is a real problem.

And the petrol economy holding-you-back is a red herring.

And, sadly Energy/mass cuts the "envinonmental argument" deeply too.</comment></comment></comment></comment>


Ask HN: What are some good cities to live in while hacking on a project? - <AUTHOR> I'm a 29yo single guy, and would prefer not to spend a princely sum of money on rent. I value walkability/public transit, the ability to meet interesting people, and good transit to/from. I'm from the US, but would consider any city worldwide. Which cities would you recommend and why? Thanks in advance! :-) <comment><USER2> Vienna, Austria. Why? Because it's rather cheap (in comparison to other european capitals), according to expats it's the city with the greatest quality of life worldwide and it would be easy to get a dev job, if you need one.

<comment><AUTHOR> I love Vienna. Would the language barrier be a problem for a non-German speaker? I have no hesitation to learn a different language, though I'd be starting from scratch. How would you compare Vienna to someplace like Berlin?

<comment><USER2> You don't need to learn German necessarily, I know quite a lot of people there that don't speak German. I was never in Berlin, but my guess is that it is better for developers (Vienna has no startup culture) but at the cost of quality of life.

</comment></comment></comment><comment><USER3> This year I travelled for a few months working, here is the summary of every city I've been:

\- Barcelona: Pricy, very modern, cool people, lots of events and things to do.

\- Canary Islands (Las palmas gran Canaria / Santa Cruz Tenerife): Cheaper than Barcelona, cool people, fewer events but you can surf, dive and hike all in the same day. Don't know how English friendly it is since I also speak Spanish but there is a lot of ex-pat/tourist all year long.

\- Zagreb: Average to cheap, nice city. I dint socialize a lot since I was working like mad at this time. People may be more distant than other places but nothing crazy you can still make friends. Reality English-friendly. Best public transportation of any Balkan city I've been.

\- Sarajevo: Pretty cheap, don't even think about going here in winter unless you like -20 degrees Celcius. Small city, bad infrastructure but still nice, really walkable. If you go here go to the coworking HUB387 and tell them Elian from Argentina send you haha. In that coworking, I met so many people, the main reason why I would go back.

\- Belgrade: Pretty cheap, nice city, like Sarajevo but bigger and with more stuff to do. Again don't even think of going here in winter. Good nightlife and hot girls (same in all Balkan countries)

Sofia: Pretty cheap, boring in my opinion. There are some things to do like, it has many huge parks, trampoline park rock climbing places, and some other stuff, maybe stay here for a few days, more than that.

\- Istanbul: Really cheap (Kebab + chips + small coke = 1 to 1.5 USD, if you know were to look for), summer is pretty hot. People are good but some of them may try to trick you to sell something more expensive, but it's not a huge deal. Pretty safe also. Nice because it's pretty different, also you can meet a lot of people from some very strict Islamic countries (Marrocco/Irak/Iran) and talking to them and listening to their lack of freedom and stuff will make you appreciate a lot more your country. Prepare to walk a lot and with lots of ups and downs. It's very noisy and chaotic, personally would not like to live here but it still pretty nice. Not so English friendly, less than the other places I mentioned.

\- Berlin: Expensive, still my favourite place, a million things to do, millions of historical thing happen there, people from all over the world, international events/conferences. Expensive but really really REALLY good and reliable public transport. Very English friendly, also bike-friendly.

\- Dresden: Expensive, nice to see a more german city, since there are not so many immigrants/ex-pat. Do be scared of the news about nazi emergency or right-wing extremist, the media its been pretty alarmistic. The most bike- friendly city I've been to.

Hope you find it useful!

<comment><AUTHOR> Thank you so much for this! :-)</comment></comment>