The Anthropology of Hackers (2010) - <AUTHOR> http://www.theatlantic.com/technology/archive/2010/09/the-anthropology-of-hackers/63308/

<comment><USER2> They seem to fail to mention BBSes, which is arguably the most important influence on the creation of the hacker underground, and IRC, which is today still the most permeable means to access it. They seem to breeze over MUDs/gaming even though that's a large part of what got people into BBSes to begin with.

From the early 1990s and on through the present, if you want to find out what governments are doing with your data, who has your credit cards and SSN, what the next major DDoS attack target will be, or get the dirty details [along with photo evidence] on the social lives of the most popular hackers, you go to IRC. To learn about the hacker underground they should be reading IRC transcripts.

Edit: I forgot about one of the newer and more exciting aspects of the cyber crime, hacktivist and hacker underground groups: web forums. Want to know who's planning Jihad on a Yahoo! Groups page? Want to know who's planning a "digital sit-in" (e.g. DDoS) alongside an Occupy or animal rights group? Want to get crack cocaine delivered to your front door (without using Silk Road)? Want to buy 10,000 US credit card numbers? Want to rent out a botnet of a million nodes for an hour? It's all on (somewhat) publicly-accessible web forums.

While we all like to play dumb that these forms of cyber-crime and vigilantism aren't "really hackers", they use the same techniques and often co-exist with the more "respectable" hackers. It's not uncommon for a more traditional hacker to live a double life (and make some nice coin on the side), committing a lot of the back-room crimes that someone else later gets caught for using. And it's just plain interesting to see how they all work.

<comment><USER3> From this comment I am confident in saying we were either friends or enemies in the 90s :)

</comment></comment><comment><AUTHOR> My first real job out of High School (no, not college) was in 1991 at a Crown Bookseller where there was an Ingram Micro computer that connected to the Ingram database and nothing else. I was never the same :)</comment>


What is the best way to network at tech events? - tefo-mohapi <comment><AUTHOR> Sign up and deliver a good tech talk.

<comment> tefo-mohapi Asking from an attendee point of view.</comment></comment>


Another perspective on pair programming: Hackers vs Engineers - <AUTHOR> http://www.jacobrothstein.com/entries/pair-programming

<comment><USER2> I'm not sure what is going on but the font renders fine and then freaks and becomes unreadable.

<comment><AUTHOR> Probably has to do with typekit (<http://typekit.com/>). I'm using the beta of typekit because it seemed like a neat way of using @font-face, but I guess it's more beta than I expected. What browser are you using?

<comment><USER2> firefox, arch-linux with vimperator. Both flash and javascript are enabled.</comment></comment></comment>


Show HN: Home and Interior Design App – Seeking Testers - <AUTHOR> Greetings,
Currently seeking a healthy influx of testers to give honest feedback about a home/interior design app I'm currently helping develop.
Please see the opt-in link below. Feel free to post feedback in this post, or shoot it to my inbox. If there's any issues in acquiring the app, let me know.
https://play.google.com/apps/testing/uk.co.homesmatch.app
Thanks. <comment><USER2> This is what I'm getting when I click on the link: [https://cl.ly/362p0F3A2U27/Screen%20Shot%202018-01-02%20at%2...](https://cl.ly/362p0F3A2U27/Screen%20Shot%202018-01-02%20at%2019.59.53.png)

Not sure about this but you may need to change the distribution type of your application. Good luck!

<comment><AUTHOR> Apologies, you were absolutely correct. Thought I'd switched to open beta prior to posting. Let me know if there's any further trouble. ^^

</comment></comment><comment><USER3> I'd love to give a hand, but I'm on iPhone. Do you have any plans of releasing for iOS?

<comment><AUTHOR> Unfortunate! Slightly out of my hands for the moment, but the consensus is we'll be on iOS ASAP (within the next 2 weeks).</comment></comment>


Ask HN: What's it like working for typical consulting companies? - <AUTHOR> How do they compare to say SaaS/product companies?
Are they more likely to have bad environments? Do you actively seek/avoid them?
I see some medium and large ones around (like Accenture) and I wonder if they can have good environments or if they quickly turn into "renting expensive warm bodies" shops only pressuring for filling up time-sheets and so on.
From the outside it looks like they are constantly hiring and firing lots of people on 3/6/12 month terms in complex roles. Given the difficulties of creating a quality team even on a more permanent basis I wonder what's the effect of their practices.
Any stories or tips you can share? <comment><USER2> > I see some medium and large ones around (like Accenture) and I wonder if > they can have good environments or if they quickly turn into "renting > expensive warm bodies" shops only pressuring for filling up time-sheets and > so on.

I worked with a bunch of contractors on an enterprise software project, one of my colleagues was from Accenture, he was actually pretty good at what he did, he gained a lot of marketable experience (AWS, automated deployment etc) on the gig by working long hours for months and learning from other experienced people in other teams. He didn't get any support from Accenture - they weren't interested in training him in any modern technical stuff that he wanted to learn. They would have been taking a hefty profit atop his daily rate. He was able to cash this in by getting a job with a smaller consultancy specialising in cloud services (better pay, better culture, more opportunities for learning and specialisation). So that's one example of how to use a bad professional services org job as a stepping stone to a better job in a more specialised professional services org, if you're willing to work hard for a year or two and have a bit of luck in terms of the project you get allocated.

I think some of the consulting companies work a bit like cults: get useful but naive young people on board who haven't experienced a sane working culture or figured out how to put boundaries in place between their life and their work, and bill them out for 80 hour weeks.

If you have a specialisation and can find work with a smaller consulting / professional services company that matches that specialisation, you might have a much more agreeable time.

@ncerezo -- your comment is thoughtful and adds to the discussion, unfortunately it is only visible to users with "showdead" on. so it goes.

<comment><USER3> @shoo thanks, I'm quite new posting comments here. How can I know if my comment has been killed? Or was it the question itself?

<comment><USER2> it appears that both of your comments in this thread are showing up normally now. doesn't appear that you're doing anything unreasonable to me. welcome!

here's a few links to FAQs: [https://news.ycombinator.com/newsfaq.html](https://news.ycombinator.com/newsfaq.html) & [https://jacquesmattheij.com/the-unofficial-hn- faq](https://jacquesmattheij.com/the-unofficial-hn-faq)

</comment></comment></comment><comment><USER3> I've worked for both types of companies, and I prefer product companies. But that's possibly a matter of preference.

Consulting is more dynamic and you're exposed to many different projects and probably to many different technologies. I had a good time doing it, but it was for a very good company which is remembered by all former employees: DEC (Digital Equipment Corp.) DEC was acquired by Compaq, which in turn was acquired by HP.

You need to travel and your work place and team is constantly changing, as you work at the client's office usually and teams are determined by availability and budget. If you work for a big consulting firm, chances are that once you leave a project you won't come back to it, and that can lead to solutions that work in the short term to meet the project deadlines, but are otherwise bad solutions for the long term.

Practices can vary greatly among different consulting firms, some will treat you well, others will simply sell warm bodies as you point out.

Working for a product company means having less or no travel at all, and a stable team to work with. It means also having much better care for quality and long term planning, because you or your colleagues will also be taking care of bug fixing and new features.

You're in touch with the business and the day to day customer issues and needs, which brings a greater understanding of the system you're working on.

However, the technology stack will be less diverse for obvious reasons.

Culture fit is also much more important as your team is not likely to change for a few years.

</comment><comment><USER4> Really demanding clients, no glory for anything you do, people being thrown under the bus, lots of travel, some greenfield projects with tight deadlines, sometimes made to fix a project half finished.

</comment><comment><USER5> I started my career from one of such consulting companies. I was naive back then. I thought I am a developer/engineer and this is how software industry is. Now, I actively avoid them. The culture in these companies is horrible. I would rather prefer to work for a small innovative company than working for these body shops.</comment>


Ask HN: Opinion on reverse social data model. - <AUTHOR>

For some years I ahd had this tiny idea for a reverse social data model (For obvious reasons, it cannot become a goliath like FB etc - but I wanted feedback on the concept):
Reverse Social Data Model:
Executive Summary:
Social Networks represent an online representation of user profile data which is presented in either a customizable or standardized format for consumption by others.
These profiles are created through the process of a user filling in data about themselves into the data-model of the site they subscribe to.
Every profile currently exists/comes to existence in this manner.
A reverse social data is based on a standard set of named fields. These named fields reside in a personally controlled profile blob which has a schema based on an open schema standard.
The user has full control over which fields are available to the public, to which sites, to which user roles on that site.
You would sign up for a community then in the process of creating your profile - check the fields from your profile which would be displayed in that community.
This would allow for you to maintain local control of all personal profile data and to be able to customize profile displays across varied sites.
Further, it would allow you to monitor reads of all fields from any site. Cut off sites completely - and be able to confirm that when an account was removed from a site, that your data was no longer available to that site.
An open standard would be created that would dictate the available profile fields.
---
Just a thought, wanted a little feedback on it... <comment><USER2> one issue as site owner is why would I use your service and not just stick with Facebook login. Facebook give me access to everything I need. I have no reason to go with your service. If and only if you got some huge traction would I need to implement your service, but your whole idea is based off the idea that people want to use your service to login/authenticate to my site.

</comment><comment><USER3> Sounds like Diaspora with a new name to me.

<comment><USER4> isn't Diaspora just another social networking site, similar in function to Facebook? I've used Diaspora, and I think what the OP is describing is a little different. Sounds like the OP is describing something like FB, in the sense that it's a central spot for your personal info, but for the purpose of using it to supplement other websites that would use the service. So, if you ever wanted to leave other sites, you'd just block access to your personal info on it and the site would be left with nothing that you gave it, for example. Or, you change personal info once on the main site, and it is reflected across all sites using the service.

I think it sounds kind of neat, but it may be a little complicated to use for the average crowd. Also, whats in it for other sites if they allow people to sign up using a service like this? Doesn't sound like a very good trade off.</comment></comment>


Show HN: Open Sukkah – Airbnb for Public Sukkahs - <AUTHOR> http://www.opensukkah.com <comment><USER2> I hope it's not for Russians customers though

</comment><comment><USER3> I like the very straightforward ui. But after making a test offer, i couldn't even cancel it.

<comment><AUTHOR> Thanks. I just deleted it. I didn't want to get into authentication to let people update or delete their posts so for now I'm just going to get rid of them manually. Maybe I'll probably add it for next sukkot though.

</comment></comment><comment><USER4> Cool project. Who are you? Chag Sameach

<comment><AUTHOR> Thanks! Canadian who now lives in Tel Aviv. Working as a frontend developer. Just did this as a fun side project. Chag Sameach!

<comment><USER4> Cool. I am an american living in Jerusalem, working at mobileye.</comment></comment></comment>


Abusing SHA-1 collisions for Chromium updates - <AUTHOR> https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/networking/browsers/chromium/update.nix#L96 <comment><USER2> If I'm understanding this glorious hack correctly, this allows Nix to determine if Chrome has an update available:

1) Nix network access is only allowed for things where you guarantee the hashes of what's output. This is generally used to do things like "download [http://example.com/release-1.2.tar.xz](http://example.com/release-1.2.tar.xz), it will have SHA1 93f3025c7802a1a11e4f16186089b583ef1095b8"

2) There are known pairs of strings that have equivalent SHA1 hashes.

3) To determine if a fetch would succeed in a "pure" way, write a network- accessing function that will return a "true" or "false" string with identical hashes, then you can use that (supposedly deterministic) string to return a (nondeterministic!) True or False to the caller.

4) This is used to run a command like `curl -s -L -f -I [https://commondatastorage.googleapis.com/chromium-browser- of...](https://commondatastorage.googleapis.com/chromium-browser- official/chromium-74.0.3729.169.tar.xz) `. If the command succeeds, we know we can use this version of the browser to update.

I don't know how it reads the channel version data without running into the same determinism issues.

Here's the latest update to the hack, moving from MD5 to SHA1: [https://github.com/NixOS/nixpkgs/commit/ed8f3b5fa3cebfc3662a...](https://github.com/NixOS/nixpkgs/commit/ed8f3b5fa3cebfc3662ad5fff098567616220cf8)

<comment><USER3> Even after reading this 10 times I still don't understand what this hack is about.

I understand these things independently: 1) SHA1 collision weakness 2) Nix checking package SHA1 when updating packages 3) Chromium returning different SHA1 for each download

Seriously, what is this?

<comment><USER4> Someone made a Nix thing that's supposed to check whether a new version of Chrome is available, and if so, generate an updated package.

While doing so, they found themselves needing some kind of "tryFetch" function that would return true or false depending on whether a certain URL is reachable.

But there's no such function in Nix. Why not? Because you're not really supposed to do stuff like that in the Nix paradigm which is all about determinism.

So... they really wanted to do it anyway, so they invented a clever hack, probably too clever.

What can you do in Nix? Well, you can make a package that downloads a certain URL and uses the downloaded result, provided that all the observable outputs of that package are deterministic. So after the package's build script runs, Nix verifies that the result matches a hash specified in the package definition. If the hash doesn't match, the package fails to evaluate.

So this hacker decided to make such a package that tries to download the Chrome update and results in the boolean information about whether the update was available. But the result needs to have the same hash in both cases. That's where a hash collision comes in handy.

So this hacky build script uses a couple of well-known PDF files that both have the same SHA1 hash. If the update exists, it gives PDF 1, otherwise it gives PDF 2.

The update script then depends on that hack package. It "installs" that package, and then checks whether it actually contains PDF 1 or PDF 2, and now it knows whether the Chrome update was available or not.

<comment><USER5> > Why not? Because you're not really supposed to do stuff like that in the Nix > paradigm which is all about determinism.

That's the part I always feel when looking at FP languages. They sound good on paper, examples are very tempting, but when reality kicks in to this pure, predictable, perfect world, it turns into a massive pain.

<comment><USER6> The key point is that the Nix scripting environment (think "a Ports manifest") is an intentionally restrictive language intended to have deterministic results for every operation. It's not intended to be a Turing-complete programming language; that's the whole point.

What the author of the script has done here, you're _supposed_ to do by writing code in some other language that generates a Nix manifest (or just by hand-rolling a Nix manifest.) And yet, the author here managed to get Nix to non-deterministically generate Nix.

Considered from the point of view of Nix's goals, this is more an "exploit" than a truly-needed feature.

<comment><USER4> Total nitpick but Nix is indeed Turing complete since it contains the untyped lambda calculus; you can write arbitrary recursive functions.

</comment></comment></comment></comment></comment></comment><comment><USER7> Something I think is a bit misunderstood here is what this is for, and why it was made.

The person who wrote this (aszlig) is truly a hacker, contorting tools to do interesting things -- and indeed, you see his cleverness at work here.

This is an update script, which is run by hand, by a maintainer, to update the Nix expression for Chromium.

This script could have been written in Python, Bash, Perl, or PowerPoint for all it matters. Or even Brainfuck using aszlig's own brainfuck interpreter written in bash[0]. This script could be deleted today and make no difference to using Nix. It is not part of any running system.

This doesn't mean Nix is insecure or broken, and no abuse like this is used anywhere in the Nix package set.

[0] [https://github.com/aszlig/shellfuck/blob/master/bf.sh](https://github.com/aszlig/shellfuck/blob/master/bf.sh)

</comment><comment><USER8> Summary by _max_bo_ in the twitter thread ([https://twitter.com/stdlib/status/1136629930060636162](https://twitter.com/stdlib/status/1136629930060636162)) linked elsewhere:

> chrome wants things different. nix wants things to be the same, always. > nixpkg programmer invokes horrifying incantation from the depths of hell to > trick nix into thinking two different things are the same.

<comment><USER9> Hey that's actually me :) I think there's better explanations elsewhere in that thread (and this one as well). It a was vastly simplified description for a non-technical friend of mine that I replied to.

</comment></comment><comment><USER10> Why would Chrome return non-deterministic bytes for a versioned release?

<comment><USER11> So they could return special build for people targeted by NSA and nobody would be surprised that their download is different.

</comment></comment><comment><USER12> Relevant thread: [https://twitter.com/stdlib/status/1136629930060636162](https://twitter.com/stdlib/status/1136629930060636162)

<comment><USER13> O/T but anyone else have problems with mobile.twitter on iOS? It never seems to work for me - just times out. Both WiFi and cellular.

Edit: this is really strange. Tried opening in a new tab and as it was stuck loading (progress bar halted at about 1/4), I opened "view source" app I have installed. It showed empty html/head/body tags and upon closing, twitter loaded up immediately.

<comment><USER14> I have a similar problem on my firefox-on-android: when I load a mobile.twitter link, it usually pinwheels for a bit, then throws up an error - either "you're rate limited" or just "something went wrong" (or, occasionally, it just pinwheels forever); then, regardless of which way it failed, loading the page a second time almost always works - but only if I do a proper reload from the browser UI, the in-page "try again" button doesn't help.

I figure something's timing out on the first attempt, but various bits get downloaded & cached before it fails, meaning the second try runs fast enough to not hit the same timeout.

<comment><USER15> It's a referer header issue. Caused by the mitigation in [https://blog.twitter.com/engineering/en_us/topics/insights/2...](https://blog.twitter.com/engineering/en_us/topics/insights/2018/twitter_silhouette.html)

</comment></comment></comment></comment><comment><USER16> Although collisions have been found for both SHA1 and MD5 (and the latter are much easier to generate), as far as I know it's still extremely difficult to generate a file with a given hash ("preimage attack")... I wonder if that property might make it useful for some things, since generating collisions even for MD5 is still much more time-consuming than verifying them, and generating a colliding pair means that finding another block with the same hash is still near-impossible.

<comment><USER17> > as far as I know it's still extremely difficult to generate a file with a > given hash

I think this might give a false impression, "still extremely difficult" here means that you'd need to do on average far more than 2^120 hash operations to do this. If you had a billion computers that could do this one billion times per second, and you did that for a billion seconds (ie several decades) you're still doing a billion times too few operations to have any significant chance of finding your pre-image.

However, because all Merkle–Damgård hashes (MD4, MD5, SHA-1, SHA-256, SHA-512) are subject to length extension, you don't need to generate new collisions you can just length-extend an existing one at leisure.

That is - take the | operator to be a string concatenation. At a high level if I know A, B such that MD5(A) = MD5(B) then I can trivially choose x and have MD5(A|x) = MD5(B|x) without doing any of the collision work again.

"Sponge" constructions like SHA3 don't do this. If somebody finds a way to make A, B such that SHA3(A) = SHA3(B) then almost certainly SHA3(A|x) is not equal to SHA3(B|x) for arbitrary values of x because the output from SHA3() is a summary ("squeezing out" the sponge) not the internal state itself.

</comment></comment><comment><USER18> This is would I would call a hack. Finally a real hack in the wild after many years!

</comment><comment> ga-vu This doesn't actually look like a SHA-1 collision attack, tbh</comment>


Whole of Denmark recreated to scale in Minecraft - <AUTHOR> http://www.bbc.com/news/technology-27155859

<comment><USER2> Extensive discussion: [https://news.ycombinator.com/item?id=7639136](https://news.ycombinator.com/item?id=7639136)</comment>


Illinois House requires one Woman and African-American on public companies board - <AUTHOR> http://www.ilga.gov/legislation/BillStatus.asp?DocNum=3394&GAID=15&DocTypeID=HB&LegID=119985&SessionID=108&SpecSess=&Session=&GA=101 <comment><AUTHOR> The debate: [https://capitolfax.com/2019/04/01/breaking-down-fridays- most...](https://capitolfax.com/2019/04/01/breaking-down-fridays-most-intense- house-debate/)

</comment><comment><USER2> and the problem was solved once and for all....</comment>


Unlock honest feedback by asking for "advice" - <AUTHOR> https://m.signalvnoise.com/unlock-honest-feedback-with-this-one-word-dcaf3839e7ee#.6245ug2d8 <comment><USER2> Feedback implies critiquing a past performance.

Advice suggests guidance for a present or future task.

I agree that this small distinction is important. Even if it's something like "here's what just happened, what's your feedback on how I handled it?" vs "here's what just happened, what's your advice on how to deal with these situations in the future."

</comment><comment><USER3> Horrible title aside, it's actually a fairly reasonable point, but feels like a missed opportunity to write something more compelling about trading business-speak for empathy.

<comment><USER4> I would have read it, good premise.

</comment></comment><comment><USER5> Asking for advice is perfectly fine, provided that those giving it have no expectation that it will be followed. I mention this only because sometimes, when advice is given, there's an implicit assumption that it will be followed - "You asked for advice, I told you to do X, but then you didn't do X! Why'd you even bother asking for it then?!" \- when the person asking for it can (and will) do whatever they want.

Of course, this doesn't help with hurt feelings when a person doesn't implement advice, but that'd happen regardless of whether you're giving feedback or advice.

</comment><comment><USER6> This article reminds me of sales techniques in general. For example, there's a talk somewhere on YouTube by a sales guru I can't remember the name of, about the art of closing. In the video he suggests using the word "agreement" over "contract". People never want to sign a contract but everybody loves to agree on something. The point is some words have unintended negative connotations and word choice is very important when trying to steer a conversation or a decision-making process.

</comment><comment><USER7> Don't ask for feedback or advice. Ask for money. If someone is willing to buy that's a very positive sign and you have a new customer. If they're not then you can have a conversation about why, which either leads to some useful feedback or you get to quickly ascertain that the person doesn't need what you're building, in which case their advice (or feedback, or questions) would have been pointless anyway.

<comment><USER8> Not really relevant to the article's premise of a CEO asking her board for feedback - but a great idea in many other situations!

</comment></comment><comment><USER9> I don't think this has much at all to do with the words used.

Give it a few goes and eventually "advice" will become the bad word. People will realise that they're just getting the same response that dissuaded them originally from responding to requests for "feedback".

It's not the word you use, it's way you respond to what you receive.

My CEO currently asks for (and receives no) "questions".

<comment><USER10> Words you use matter as well (Sapir-Whorf hypothesis).

<comment><USER11> Sapir-Whorf is about grammar, not individual words: [https://en.wikipedia.org/wiki/Linguistic_relativity](https://en.wikipedia.org/wiki/Linguistic_relativity)

"The principle of linguistic relativity holds that the _structure_ of a language affects its speakers' world view or cognition." (emphasis mine)

</comment></comment></comment><comment><USER12> In SV, the old chestnut goes: "If you want money, ask for advice, and if you want advice, ask for money." ;) So basically, never ask for money...

</comment><comment><USER13> Another approach is "how does this suck, and how do you think it could be better?" starts off with a premise of unpolished-edges seeking honest input. Also, only ask strangers, preferably likely customers, for feedback/advice because it can seem a catch-22 to most friends and family.

</comment><comment><USER14> tl;dr - talk like a human and not an MBA and people might actually communicate with you.

</comment><comment><USER15> Ask for advice instead of feedback — saved you a click

</comment><comment><USER16> Is the word 'clickbait'?

</comment><comment> ryan-allen ... that doctors hate?

</comment><comment><USER17> Side note: aren't these title styles becoming such a common click-bait trope that everyone automatically discounts any information in the article by now?

<comment><USER18> a kind of Betteridge'a law of headlines, but on this one we are missing the question mark..

Apart from that, being a "hated auditor" for more than a decade I agree that "seeking advice" has a better ring than "seeking feedback".

Advice can be considered friendly, (sometimes) unofficial and positive, while feedback "will be permanently put on your record!"</comment></comment>


LARRY PAGE: I Would Rather Give My Billions to Elon Musk Than Charity (2014) - <AUTHOR> http://www.businessinsider.com/larry-page-elon-musk-2014-3 <comment><USER2> Exactly what Zukerberg is attempting by structuring his investments as an LLC rather than charitable org. But some folks didn't get/like it.</comment>


Starbucks starts rolling out wireless phone chargers nationwide - <AUTHOR> http://www.theverge.com/2014/6/12/5801716/starbucks-rolling-out-powermat-wireless-chargers-nationwide <comment><USER2> Do HNers have an opinion about Qi versus PowerMat?

<comment><USER3> Qi is everywhere. The problem is that Starbucks announced this project back in 2012 when Powermat was more well known. Google, and others, shifted from supporting pm to qi shortly after, I believe due to licensing costs, and now the market is full of android phones that use qi. I've been using it for my last 2 phones. Works fine with a cheap Energizer charging pad. Its simple and it works. I'm now at the point where I'm annoyed with fiddling with little connectors, especially if its late at night and I'm tired and keyed it the wrong way. Less damaged cables as well. While I'm skeptical it'll be used in public spots due to the potential of theft, its really nice to have at home.

From a tech perspective they both use induction. The A4WP product uses magnetic resonance, but I don't think they have a sellable product yet, but in theory they could charge your phone from across the room. I think demos have only shown it work from a few inches away. This solution is very non-green considering the inverse sq law. I have a feeling that there will be pushback if people are wasting 2x or 5x the energy to charge their devices, as well as larger electricity bills. Not to mentionn, Joe User asking about "radiation."

The war isn't over because Apple hasn't picked a side. I imagine they'll go with pm to be difficult and to hurt Android's qi based phones. "Oh, you can't charge here, its iPhone only," seems to be a narrative that helps sell the "exclusivity" of their devices.

I also find it a little hard to believe that Starbucks would invest in all this technology without some kind of nod from Apple that this will be in their next phone. A4WP signed some agreement with PMA recently, so who knows whats going to happen here. It sounded like a desperate move to me, but now I'm not so sure with the starbucks roll-out and the Apple wildcard at play.

[http://www.theverge.com/2014/2/11/5398066/a4wp-and-pma- merge...](http://www.theverge.com/2014/2/11/5398066/a4wp-and-pma-merge-tech- to-win-wireless-charging-war)

<comment><USER2> > While I'm skeptical it'll be used in public spots due to the potential of > theft, its really nice to have at home.

Well, plug-in charging is already fairly common in coffee shops, and the cord clearly doesn't provide security. I think wireless charging will be even bigger since you just pull the phone out of your pocket and plop in on the table, rather than bring the charger with you.

> From a tech perspective they both use induction.

One of the other commentators mentions that he thinks Powermat is more forgiving on exact positioning of the device on the mat. Do you know if this is real/important?

<comment><USER4> > One of the other commentators mentions that he thinks Powermat is more > forgiving on exact positioning of the device on the mat. Do you know if this > is real/important?

I think you're referring to gdilla, who stated (incorrectly[0]) that this Powermat's technology is less sensitive to positioning because it does not use inductive-based charging (in fact, it does).

I've been using wireless charging on the Nexus 4 and Nexus 5 for a while now[1], and the main factor is simply the size of the device and the surface area of the charger. There might be some subtle difference beyond that, but if so, it's too small for me to have noticed after several months of daily use. I never have to think about it.

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

[1] Qi-based, just like essentially all wireless-charging devices on the market

</comment></comment></comment></comment><comment><USER5> If wireless charging is 100% secure, then it's the best way to go for public charging stations. USB cable is a potential path for malware.

<comment><USER6> You should be able to charge with a USB cable after you've snipped the data lines. At that point, it only provides 5V of power, and nothing else.

</comment></comment><comment><USER7> I was in an airline lounge at SFO a few days ago. Alongside the regular power sockets were USB charging outlets. I tried to use one to charge my iPhone, but the current (or voltage?) was so unstable that my touchscreen went haywire and the device was unusable, just like when using super-cheap mains->USB adapters.

<comment><USER8> I just recently flew from Chicago O'Hare to CPH and there were multiple USB ports at a bar table (just after TSA at the international terminal) which work amazingly well (also: no lounge). I wish every airport had places like these.

<comment><USER9> At a stopover in an airport in Sweden, they had password protected locking compartments with a multitude of chargers that you could leave your phone in for free, so that you didn't have to stay in one location while your phone was charging. I was a bit sleep deprived and almost forgot my phone, but other than that the convenience was great. Definitely something American airports should get.

<comment><USER10> There is a cafe at my university (Univ. of Cincinnati) that has something exactly like what you are describing. I've used it a few times and it was really convenient. It has taken people a bit to get used to it though.

</comment></comment></comment></comment><comment><USER11> Weve had them in Cambridge MA for a while now- You have to have a special case to use the wireless charging station. I predict this getting a lot of press but wont be practically useful. If youre on the street going about your day and need a charge up, it is unlikely youll have the required case nearby.

</comment><comment><USER12> iPhone 6 to include wireless charging?

<comment><USER13> Starbucks and Apple have always had a close relationship... it may be a hint.

<comment><USER14> I guess the new iPhone might have Powermat support.

</comment></comment></comment><comment><USER15> Powermat? What uses that?

<comment><USER16> Obviously someone high enough up in Starbucks to influence the position. Either they used it prior or were given enough incentive to use it now.

</comment></comment><comment><USER17> What's the wattage on these? AFAIR Qi is at 2.7W, which is not enough to sustain my Note 2's charge during browsing or video.

<comment><USER10> Looking at the wiki page and the spec on their website v1.0 of the spec is 5W of charging[1]. There is apparently a new one that either has been released or may be released soon that supports up to 120W.

[1]: [http://www.wirelesspowerconsortium.com/developers/specificat...](http://www.wirelesspowerconsortium.com/developers/specification.html)

</comment></comment><comment><USER18> Another way between standards. Hopefully this ends better than HD-DVD and the poor consumers who thought they were on the right side.

<comment><USER19> Considering that Blu-ray is dying along with physical media anyway, I don't think there was a right side.

</comment></comment><comment><USER20> Nationwide? In the nation of let's say Russia? Or the default nation?

<comment><USER21> I think it's acceptable for a US news source talking about a US company to imply that "nationwide" means the USA.

<comment><USER22> Do you think The Verge consider their market to be only the USA? They are using the www not the usw so far as I can tell.

Truth is they make it quite clear which nation in the first line of the article - I think The Verge are a global news source [albeit, yes, with a USA focus] and that they're quite cognisant of that, given the rest of this article.

<comment><USER23> 'www' is not their tld, .com is, and .com is a US tld, created by the US government and administered by US corporations. Russia has .ru, and if there was an article on theverge.ru talking about a nation-wide rollout, we could assume they were talking about the nation of Russia.

<comment><USER22> > _.com is a US tld_ //

.us is the ccTLD for USA. .com is the defacto default for all types of entities from across the world. Verisign call .com "The Global Online Standard". Yes, USA broke the convention and structure to preference themselves - that seems to be a favorite passtime.</comment></comment></comment></comment></comment>


My Ukraine - <AUTHOR> http://www.brookings.edu/research/essays/2015/myukraine <comment><USER2> I think that this article could end up being cited a lot. It has a very believable thesis. I'd like to see it put to the test, and then condensed down and hopefully inform news reporting a bit.

If we accept that, as a member of the super-wealthy post-USSR kleptocracy engaged in an endless Presidency, Putin is naturally most concerned about maintaining domestic power, then the thesis is: massive uprisings in their largest ex-Soviet neighbor, against a Russian-allied President, where the public floods into the President's palace and becomes even more enraged at evidence of their wealth (a golden loaf of bread; a pirate-ship restaurant), make it _impossible_ domestically that Putin not respond with a show of force.

As the article says, he and his chums have palaces too.

<comment><USER3> People like you completely miss the point on Russia. You cannot accept that it is indeed a democracy, that people are not brainwashed. And that pretty much the contrary of what western media portrays is happening there. Trust me, i've been there.

<comment><USER4> They are not brainwashed to the same extent that the people of North Korea are brainwashed, but the majority of them do get all of their news from (State- owned) TV channels and uncritically subscribe to the ruling party's ideology.

Like Neocons in the US.

<comment><USER5> They're brainwashed to the same extent that many people in the US are brainwashed.

The wonderful thing about modern propaganda is that it has become so subtle we often mistake it for our own opinions.

As a European when I watched CNN for the first time at the early stages of the Iraq war, I first wasn't sure whether it was supposed to be satire or fiction. It took me a while to realise that this is what many people think of as "news" in the US. Makes me wonder what I miss in our own news media -- you only spot bold faced lies when you have a trusted reference you can compare them to.

</comment></comment></comment></comment><comment><USER6> I followed the news for a while now with regards to Ukraine. I don't understand why people are arguing about legitimacy of things in international politics.

The facts are simple:

\- Russia had Ukraine in her iron grip

\- EU was expanding east

\- pro-Russian president turned down EU's offer

\- Ukrainians got pissed, because the state of things suck and they want change, and EU seems like a good idea (whether it will work out for them is another story)

\- they overthrew the pro-Russian government, and got a pro-EU one, who is unfortunately also quite corrupt, but that's beside the point

\- Russia is pissed, and finds a way to intervene.

In short, the west started a diplomatic/cultural war in Ukraine, and Russia lost, so it's resorting to physical war now. There is really no good guys in international politics.

</comment><comment> at-fates-hands I've known several people from Croatia, Latvia, Georgia and now Ukraine. They all look down upon Russians and are easily offended when people refer to them as such.

Definitely no love loss for Putin or Russia among them.

<comment><USER7> I am sure a lot of North Osetians in Georgia are offended when they remember Georgia invading them and killing helpless people because the prime minister of Georgia back then was a US puppet.

</comment></comment><comment><USER8> While Putin has many faults blaming him for the situation that lead up to modern day Ukraine is not right. The Ukrainian people overthrew their elected government lead by Yanukovych who may or may not have sought Russia's help in protecting his government. Basically a series of dysfunctional leaders led to Yanukovych's ouster and when they could not get their affairs in order Putin took Crimea.

So while Putin's people are likely causing issues in Ukraine it is just as likely there are many people in Ukraine who did not support the revolution and seek outside support for the last legitimately elected government.

TL;DR. the people of Ukraine made a mess of it, gave Putin and opening, and still cannot sort it out. Not the news HN should be showing

<comment><USER9> _Putin took Crimea._

That's enough for me to put the blame squarely on Russia for the current situation. Whether the people who initiated the coup against Yanukovych represent the entire population, a majority or a minority, it's an internal Ukrainian affair and Russia has no business interfering.

Add the take down of the Dutch plane, the nonsense about tanks taking "relief supplies" over the border, soldiers getting "lost on vacation" and it's pretty clear that Putin is engaging in an illegal war.

And, yes, I am from the US. I don't agree with our illegal wars either so please don't go there.

<comment><USER3> Crimea was Russian and voted to join Russia. Illegal wars are what the US wages around the world. Russians are helping the insurgents unoficially because Nuland and that scumbag US ambassador placed a Nazi Junta in power.

<comment><USER10> 1\. Crimea was Ukrainian from 1954 until Russia's invasion. 2\. The election held after Russia invaded was neither fair nor free. Non-citizens were allowed to vote and militias coerced voting.

</comment></comment></comment></comment><comment><USER11> The article title is "My Ukraine", highlighting the distinctive personal- perspective nature of the piece.

Mrs. Freeland's long-duration take on the situation makes it most worth reading.

</comment><comment><USER12> Seems pretty one-sided and biased. Mentioning Putin personally way too many times, unrelated to the proportion of influence that he's got in the situation.

We are engineers here, we know that big disasters come from a complex of different factors. Why do you think Ukraine is an exception, why continue blaming a single person? I don't see why this sort of article should be on HN.

</comment><comment><USER13> I wonder if the Russian government's Internet trolls try to compromise accounts to make discussion look legitimate.

For instance, felipepiresx was entirely inactive for over a year, before jumping all over this thread 20 minutes ago.

<comment><USER3> with all due respect. I'm a person. I'm Brazilian. I'm not Russian. It's amazing how dismissive people are of people who have a contrarian opinion.

<comment><USER14> A Brazilian, how could you possibly know what's really happening on the ground in eastern Europe?

edit: spelling

<comment><USER3> I've been there.

</comment></comment></comment></comment><comment><USER15> You can begin a lot of things with "The nightmare Vladimir Putin has visited upon"...

I'm an LGBT person (specifically, I'm both L and T), and after seeing what Putin did to my people, I have absolutely zero respect for anyone who supports Russia in any way.

<comment><USER5> Radical ideological extremism is harmful, no matter whether you think you're justified.

Yes, a lot of Russian politics are pretty worrying and negatively impact the lives of all kinds of people, but if you paint everyone in such broad strokes, you end up coating the entire world.

<comment><USER15> It's literally illegal to say it's OK to be gay in Russia. They are an oppressive government that is targeting my people for extermination.

<comment><USER3> It's not illegal to be gay in Russia. Although their gay law is backwards. It's a far cry from what you see in the Middle East. It looks more like what you see in Middle USA. Conservative, yes, oppressive and dangerous, not necessarily. Im for LGBT rights, but this topic is overblown.

<comment><USER15> I live in Texas, I am out and proud as a transgender lesbian, and I've never had any problems. It's not illegal to say it's OK to be gay anywhere in the US, but it is in Russia.

It _is_ oppressive and dangerous.

<comment><USER3> Not true. I've seen gay people and bars in Russia. You clearly have never been there. Go back to watching MSNBC and screaming MUrica

</comment></comment></comment></comment></comment></comment><comment><USER16> Odd since it was America which instigated the Ukrainian coup, inflamed ethnic tensions, and continue to push towards military conflict.

<comment><USER17> >ethnic tensions

No ethnic tensions really happened in Ukraine ever. Biggest problem I (as ethnic Russian and Ukrainian citizen) ever had was about spelling my name in Latin letters.

It's totally made up topic that just appears before elections.

You can use spoken and written Russian almost everywhere including contracts, court, communication with government employees, etc.

<comment><USER3> The people in the east would disagree. There are ethnic tensions. Even VICE shows Nazi ukranian soldiers.

<comment><USER17> They may happen now in Russia-occupied and war-torn areas and boarding areas, but don't happen on the South that is controlled by government and where Russian-speaking and people of Russian ethnos also live.

Yet, at Donbass and Crimea Ukrainians and Crimean tatars are threatened.

So yes, there are ethnic tensions now, thanks to Russian govt.</comment></comment></comment></comment>


Sarah Lacy, Mike Arrington to Start TechCrunch Rival - <AUTHOR> http://www.nbcbayarea.com/news/tech/Sarah-Lacy-Mike-Arrington-to-Start-TechCrunch-Rival-135457043.html <comment><USER3> I believe this was inevitable. especially since TC's core team took off. Its usually not pretty there, with more than 50 posts in a couple of days. My reader is usually overblown with TC and i read very few of them. Looking forward to what Mike has in the bag, maybe they can bring other ex-TCers on- board too.. MG and Paul.

</comment><comment><USER4> The only things that surprise me are:

1\. Why AOL thought buying TC would turn out any other way (or was a remotely good idea at all); and

2\. Just how big of a jackass Arington is. I mean the whole way it's been Arrington cashing out and just sending big FUs to AOL.

TC succeeded at least in part due to timing. The same team won't recreate it's success just by virtue of being the same team. Just look at Engadget and, well, pretty much every other example.

Arrington has a conflict of interest with his Crunchfund. After years of covering startups the armchair quarterback has decided "hey I can do this too!" and starts another quasi-media outlet to pimp his investments. Shocker.

<comment><USER5> TC was running fine for a year at AOL until they bought in Huffington, who wanted TC to fall under her org. This was all about Armstrong being weak over Huffigton, and it wasn't just TC employees who have left but many others in the senior ranks at AOL because of it (Garinghouse, Einh)

AOL are the primary investor in the Crunchfund, a bit hard to FU their own investments

This co. is being started by Sarah with Arrington (amongst many others) as a (minor) investor

Arrington has previously started, and sold, startups. Hardly an armchair quarterback.

Just to be clear, you are accusing Arrington of a conflict of interest on a site that he didn't start and doesn't exist yet.

and re: Engadget. The guys who left and started The Verge are on fire. It is already the 8th most linked blog on Technorati and 3rd on TM rank - <USER2> growing media property I have ever seen. So that works.

</comment></comment><comment><AUTHOR> I just wish it will cover different startups than the one TC loves to write again and again.

<comment><USER5> That comes down to the writers, and TC having pretty loose editorial control over content.</comment></comment>


Ask YC: Sharing ownership with nontechnical founder? - <AUTHOR>

I'm involved in my first startup (cry or laugh I can't decide yet), and we're planning on discussing how to share ownership (and other similar concerns) sometime next week, and I was hoping to get some advice from here beforehand. As far as I know, we'd be considering a CA LLC, we're a mix of self-funding and bootstrapping, and the startup is (mainly) a website.
Simply, there are three people, one is nontechnical and the other two would be doing all of the development and some of the nontechnical stuff as well. Between us two devs, the third guy who I brought in last is going to be doing most of the work and I'm going to pick up the rest (iPhone app anyone? :D ) and do all the leftover nontechnical miscellany..and I'm fine with a small share in exchange. But it's the nontechnical one who had the idea in the first place and is currently the sole source of self-funding by choice (piggybacking on her existing hosting and paying for domains and whatnot).
How do you deal with this kind of situation? How much weight should we be giving to the idea compared to the execution, which is most of the work but wouldn't exist without the idea? How much weight to give to someone funding everything, no matter how trivial it may be? It's pretty easy (to me) to determine how us two devs would be splitting it based on the work we'd be doing, but then when we have to consider all three of us it's hard to determine, and I don't know if an equal 3 way split would be okay with everyone (and I'd feel uncomfortable with that unless I were more involved...). Any insight would be much appreciated. <comment><USER2> Split three ways evenly, it's the easiest and once you go down the slope of differentiating the ownership it starts to become really complicated really fast. You'll spend a lot of time nit-picking and a lot of "yeah but you have more shares so you should do this" talk.

Besides, ownership only matters when you sell in which case there'll probably be plenty for all of you. In the daily business you'll (I guess) all take the same paycheck from the company. So it doesn't matter so much.

That's based on my experience anyway.

<comment><USER3> I think this is a terrible idea. I definitely believe in the one founder mentality. There needs to be one person who drives the vision, and a team to execute on it.

If I was going to have two co-founders, I wouldn't consider offering the other founders more than a 52% / 24% / 24% split, with one person clearly defined as the leader (be it me or one of the other founders) and driver of the vision.

If you aren't comfortable with that from a voting standpoint, simply require all important votes (sale of company, transfer of equity, dilution) to require a supermajority vote. Lawyers have standard language that clearly define these kinds of scenarios.

But 1/3 1/3 1/3 is just asking for trouble on minor details down the road when one person needs to clearly be in charge.

<comment><AUTHOR> With 52% ownership of a web startup specifically belonging to a nontechnical cofounder (she would be the logical "leader" with the vision) is that who knows what will happen on a bad day. I've already shot down one suggestion of hers because it was irrelevant to the service we were going to offer. While a supermajority vote makes complete sense for important votes, 52/24/24 with the two 24% to the developers would be impossible on the less important votes if it was technical in nature and she just didn't get why they may be problematic/impossible.

I'd feel a lot more comfortable with a 52/24/24 split if only she knew more. But she's relying on us to provide everything design/development-related without being fully knowledgeable about it, and without us she's dead in the water.

<comment><USER3> She should be delegating all technical decisions to you. That's a part of being a leader. It requires leadership and knowing when to trust and delegate to your team.</comment></comment></comment></comment>


When does Computer Science become software, and vice versa? - <AUTHOR>

I'm preparing an introductory talk on healthcare software. I keep finding myself writing things like "Computer Scientists and software developers", "the gains of computer science and software development". Is there a term that includes both? <comment><USER2> How does Computer Science find its way into an introductory talk on healthcare software? If you tell us a few of the points you are trying to make, we might be able to suggest alternate phrasings.

(As an aside; I was a healthcare software developer in a previous life, and I can't recall much Computer Science coming into it, except in the most indirect ways...)

</comment><comment><USER3> "Computer scientists" is kind of awkward and would only be valid for labeling academics (aka professors).

Besides, "computer science" is a terrible term. [http://video.google.com/videoplay?docid=-3674140982294628000...](http://video.google.com/videoplay?docid=-3674140982294628000&ei=bbZISO7vAqiSrAKzhdGWDA)

</comment><comment><USER4> I'd say "software engineers" since engineering is usually what gets across that boundary between theory and practice.</comment>


RE: Any updates? "Poll: How much do you make as a programmer?" - <AUTHOR>

I was just wondering if there were any updates on this thread here:
http://news.ycombinator.com/item?id=2763932
OP set up an updated survey and said he/she would share the results in a few days.
I'm in a salary negotiation situation right now. I feel like this information would greatly help me out and I'm curioso to see the numbers as well.
Just making sure it doesn't die. <comment><USER2> glassdoor.com has anonymous company reviews and (self-reported) salary ranges for many companies. The data can also be filtered by job title and geography.</comment>


Ask HN: What do you regret you didn't know when programming for iOS or Android? - <AUTHOR> What do you regret you didn't know when started programming for iOS or Android? <comment><USER2> I'm a self taught programmer and started developing for Android in 2012. It took me a while before I realised that you needed third party libraries to do absolutely anything useful as the platform APIs were so poor and undocumented. There were gaps everywhere and you needed to write tons of boilerplate code to do things properly.

Image loading was often a huge source of crashes due to out-of-memory errors and doing it properly wasn't trivial [0]. Libraries like "Glide" and "Picasso" solved this.

Using the camera hardware was awful. Device manufacturers would implement things differently, and break the camera API unexpectedly. Only recently [1] are we starting to see sane, consistent camera APIs.

Making network requests felt extremely clunky, and the platform JSON implementation wasn't performant, or easy to use as you had to manually parse everything. Retrofit [2] made talking to REST services much easier.

I could go on and on, but I'm sure there's plenty others here who can do that here. These days Android development is much, much more enjoyable. Kotlin has pretty much replaced Java in the Android ecosystem, and there's great reasources around on how to architect your app to make everything testable and easily scalable such as the architecture samples [3]. I've worked on a few React Native projects in the last year. I'm not a fan of it, but I definitely see the industry heading to some cross platform solution eventually.

[0]. [https://developer.android.com/topic/performance/graphics/loa...](https://developer.android.com/topic/performance/graphics/load- bitmap)

[1]. [https://developer.android.com/training/camerax](https://developer.android.com/training/camerax)

[2]. [https://square.github.io/retrofit/](https://square.github.io/retrofit/)

[3]. [https://github.com/android/architecture- samples](https://github.com/android/architecture-samples)

<comment><USER3> Personally I think that Flutter is the future for cross-platform UI toolkits. As a React dev (in my spare time, I'm still a student), using RN was a pain due to the need to install native extensions for almost everything. The batteries-included approach of Flutter and just the polish around the dev workflow made it more attractive to a beginner mobile dev.

<comment><USER4> I would be hesitant to recommend seriously pursuing cross-platform. Most serious applications generally run into scaling issues as they get more complicated and demands require more than the abstractions the cross-platform tool can provide.

<comment><USER5> On the other hand, very few applications need to scale to the point where it matters. If the options are "ship something now and refactor later" versus "ship something in six months that's perfect but too late", most people here would benefit from cross platform solutions.

Very few companies have ever failed because their tech stack didn't scale well.

<comment><USER6> This is a nit, but there's a pretty big difference between refactoring and rearchitecting.

If you plan for an eventual migration of the app from a cross-platform toolkit to native, then often you're committing to a significant rewrite of the app. This means either you dedicate a team to the rewrite or you stop adding features while it gets rewritten.

Plus it will take a while for the native version to get feature parity with the cross-platform version, and you typically can't roll out the native version until you have parity.

I'm sure there are tools and strategies for getting this right, but I've seen this basically kill startups.

<comment><USER7> > _"I 'm sure there are tools and strategies for getting this right, but I've > seen this basically kill startups."_

Well if they're doing it like that, it's indeed not much better than hara- kiri. There are better ways :)

How you do it is incrementally, avoiding too-major changes at once, and progressively moving from codebase A (cross-platform framework) towards codebase B (new native thing). But it happens at the integration level, i.e. you build with increasingly more % from B, but during the whole A->B transition it'll be a hybrid build.

E.g. part Flutter / part native.

1\. You begin with "let's take camera stuff out of Flutter and re-implement our related features using native APIs": this instantly makes two apps (iOS, Android) with 90-99% code in common, just a fork to handle camera APIs separately (by the way, the state of API affairs often forced you to do this to some extent for any non-trivial use-case; I'd wager it used to be the state of most feature-rich apps in the 2010s).

2\. Then you proceed with another component of your app. Rinse and repeat until you've got 90% from B and the remaining stuff is structural.

3\. All that remains is to remove Flutter entirely from the equation and rewrite your core app logic: what glues all of the above components together; all of which at that stage are already rewritten for native and tested independently (critical to your success).

Along the way you never truly break UX, it's more of a classic "ongoing development" thing with details changing here and there, and hopefully better UX each step since your move to native must be motivated by something worth it for the client-side (otherwise it's likely your server API model that needs refactoring).

That's how the now-default-consensual approach to how you change stacks without breaking UX, nor your company. Full rewrites on wholly new tech is just asking for cataclysm: you literally do that to yourself, to your own code and users. It's also the only reasonable way I know for small teams, one-man shows, etc.

<comment><USER8> Make sense. And may be should start with this thinking when I started to avoid the first pain.

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> I should've known that it's turtles all the way down. Considering how many years I've sunk into programming for other platforms, this shouldn't have come as a surprise, but I got suckered into believing that mobile computing platforms represented a significant enough paradigm shift to allow for starting with a cleaner slate.

Not true! Having gotten into iOS development over the past couple of years, I've come to realize that seemingly no attempt has been made to actually clear the cobwebs on this shiny, relatively new platform.

For example, SwiftUI is just an abstraction layer for UIKit, which itself is (keep me honest, HN) an abstraction for some mishmash of Cocoa, Display PostScript and Metal. Bits of NeXTSTEP are everywhere still, even when using Apple's latest and greatest programming paradigms.

Don't get me wrong, iOS is great, and I love it to death. However, the baggage signals to me that a massive opportunity to start anew has been missed.

<comment><USER10> SwiftUI isn't UIKit-specific. Display Postscript hasn't existed since the OS was called NeXT, 20+ years ago, and was never on any iDevice. Cocoa is an alias for AppKit + CoreData, and iOS uses CocoaTouch instead.

<comment><USER11> You're right, yet this doesn't directly address what parent said, in fact it's somewhat agreeing with the point, that there's a ton of influence left behind by these things, even though they are not there anymore.

</comment></comment></comment><comment><USER12> It depends somewhat on why you ask.

A lot of people are recommending using cross platform solutions. As a hobby or learning exercise, go for it! As someone who has a career across many projects working full time as a native iOS and Android dev, I can say these solutions are generally avoided. They are good for prototypes you don't plan to maintain long term, I'll give them that.

I know it's cheesy but my only regret is I didn't go all-in on mobile sooner. I have been on a constant upward career trajectory since the day I put my first app on the store. Get an app on the store as soon as you can and if it gets traction listen to feedback and update it. If you're early in your career this will be the only thing on your resume that matters. I highly recommend you start with iOS just because the tools are more friendly for beginners. Watch WWDC/Google IO sessions and keep up with the latest. However it's best to keep a healthy distance with things that only support the newest OS. For instance I wouldn't build an app in SwiftUI yet but I follow it like a hawk because it's likely to be the only way Apple platform apps are made very soon. Closely follow VR/AR frameworks and machine learning. Those will become must- know this decade.

Mobile dev is so rewarding! Every developer should at least dip their toes in.

<comment><USER13> As a front end dev I've been thinking about it for so long but honestly I don't know what I should build or study first.

<comment><USER12> It's always best to work on something you'll actually use. Maybe think about an app you already use but want to improve or simplify (a to-do list without the frills for instance).

As far as learning, I think this Stanford course is the best way (though not for those who aren't absolute beginners to programming). I notice it hasn't been updated lately but it should be current enough [https://www.youtube.com/watch?v=TZL5AmwuwlA](https://www.youtube.com/watch?v=TZL5AmwuwlA)

</comment></comment></comment><comment><USER14> That developing for Android isn't even as half as smooth as developing for iOS. Yes, with iOS you're using Xcode and have to set up provisioning for your dev device and all that, but once you've done that you're mostly on your way. UIKit, while not the shiniest thing out there, is quite competent and functional — you can easily write world class apps with it while keeping third party libraries to a minimum.

On Android, setting up for development is a bit faster but the actual development story is so, so much worse. Kotlin improved things a great deal and Jetpack improves it further, but it still has such a long way to go. You'll spend inordinate amounts of time researching the "right" way to do things only to find that there really isn't one, but instead several ways with varying levels of wrongness with different trade offs. Even mundane things will be a source of trouble and you will likely have to make concessions in your UI design to work around Android SDK awkwardness.

If I could just have UIKit on Android I would be a much, much happier Android dev. Hoping Jetpack Compose improves the situation but I'm not holding my breath.

<comment><USER15> > You'll spend inordinate amounts of time researching the "right" way to do > things only to find that there really isn't one, but instead several ways > with varying levels of wrongness with different trade offs.

From what I've heard Android is unusually bad for this but this particular sentence resonates with me in terms of basically everything ... though that may be because I do a bunch of deployment/ops stuff which is generally entirely made out of "choose your own petard to be hoist by later"

<comment><USER16> The best-case end result of this instability, of course, is the "double interface" \- an interface abstraction on top that talks in terms of the domain problem, and then a second layer to convert the lower level interfaces into that abstraction.

Unfortunately GUI is particularly fiddly and difficult to write the double interface for, since you get a "thousand words is one picture" problem: it doesn't reduce well to text.

</comment></comment></comment><comment><USER17> I wish I would have not fought the tools so much.

I started Android programming from the command line using make/ant and testing on a device because I didn't like Android Studio. This ended up wasting a lot of time and energy over the years as I had to integrate more 3rd party libraries (including Google's own crap).

Same thing for iOS. I didn't like building GUIs in Interface Builder so I did everything in code. Over time as iOS devices came in different sizes, this became harder to do properly. I should have given in early and learned to use Interface Builder, auto layout, etc.

<comment><USER18> Code-only purists are still prominent in the iOS community. Yeah, there's definitely baggage one must take on when using IB but the ease of being able to instantly preview your layout in different sizes is the big seller for me.

<comment><USER19> IB files are essentially impossible to code review.

<comment><USER20> If you read the storyboard diffs the layout code is human readable, just need to get used to it. Although there is no docs

<comment><USER21> Not in the case where a bunch of views are moved inside a new view. Then the XML diff is really janky, and elements are assigned new IDs.

The constraints are impossible to code review in XML since they refer to elements by IB ID which is essentially obfuscated. I don't understand why IB doesn't let you give the elements their own human-readable IDs.

</comment></comment></comment></comment></comment><comment><USER22> The thing that would've saved me the most time and frustration in the long run for all mobile development (well, all dev period, but mobile especially as they tend to be moving targets):

Ignore the framework. Write your app how you want to write it, then _attach_ it to the framework as needed. Don't restrict yourself to what the framework supplies or how it thinks about things.

It'll dramatically decrease craziness in your core logic in the long run. Framework versions and bugs can lead to strange lifecycle callbacks, weird interactions between the N flavors of how to build UI components, etc, and if your _core logic_ is chopped up to deal with all of this it can become very hard to make important changes. Such as updating to a newer version of the framework so your app isn't removed from the stores.

It'll pretty much always be more up-front code and work, but you'll be left with a far clearer system in the end.

<comment><USER23> With React hooks or android component life cycle its hard separate the framework and logic. How do you do it ? Any recommended books or other resources ?

<comment><USER22> React's behavioral features are relatively difficult, I'll grant, but it's entirely possible to use it as a relatively dumb "render X efficiently for me" target. If you're using hooks heavily, you're deeply entangling your code with the framework - that's your choice, but yeah, it comes with consequences as well as benefits.

Android lifecycles are probably the main target of my comment tbh. They're abysmally complex and make any kind of state management incredibly error- prone.

As a tradeoff for that complexity and losing a lot of control, if (and only if) you go all-in on them, you get decent state _reviving_ after process death, which can do really slick things like "app crashed" -> it just appears to go back one screen.

Instead, you can write your app as e.g. an in-memory singleton somewhere. You can even do that in a different thread if you want, leaving your UI impossibly smooth (at increased risk of "tap x" -> "nothing happens"). Design your own lifecycle that makes sense for your app (which probably looks very little like the Android lifecycle, especially when you throw in fragments...) and trigger/wait on the external world of the Android framework as needed. Odds are pretty good that you'll take multiple things from Android and combine them into one in yours, and potentially vise versa (e.g. multiple actions from your app become view updates in a single activity, rather than multiple activities. or do everything in one activity, it's often far better performance anyway, and much easier to control in fine-grained ways. importantly, _your core logic doesn 't care_, unlike if you put that logic in the activities).

</comment></comment></comment><comment><USER24> I regret not knowing about cross-platform development such as Flutter and ReactOS.

I also regret not buying a book explaining all the concepts in as simple a manner as possible. As a semi-amateur programmer, I feel like most of the documentation is meant to refresh the memories of people who have been developing apps for years; they're extremely beginner-hostile.

<comment><USER5> Agreed. This absolutely kills me when people say "just read the documentation" or "the documentation is very good" as a reason why they don't produce examples or templates or starter kits. Not all of us are CS majors or programmers in large teams or with decades of experience to fall back on. Just reading the documentation isn't enough to get me into a new framework or language. I need to see practical examples.

For mobile development, this is why Expo was so crucial for me to understand how React Native works.

<comment><USER25> Apple _used to_ have a lot of pretty good (not perfect, but pretty good) conceptual/architectural documentation. Most of it has sadly been sunset, and is hard to find, even though it's still largely applicable. And it hasn't been replaced -- hopefully that's just "hasn't been replaced _yet_ ".

<comment><USER26> Apple documentation in the 90s was a piece of beauty. Microsoft's was pretty good too back then with MSDN Library CDs.

</comment></comment></comment></comment><comment><USER27> I regret not knowing that Android API is awful.

Then I regret looking into Nativescript, because it was pretty buggy.

Then I regret not knowing about Flutter earlier.

THEN I regret not knowing that Flutter is pretty buggy as well.

Next step is me trying to learn other frameworks, like Cordova or React Native. I wonder what my regrets will be.

<comment><USER28> Cordova and react native are going to disappoint you for the same reasons.

<comment><USER26> Everything sucks in its own sweet way :-)

</comment></comment></comment><comment><USER29> On Android, that there hasn't been much love for C/C++ and the NDK is full of interesting pitfalls:

Oh your camera gives you NV21 frames, but the hardware VP8 encoder only accepts I420? Makes perfect sense.

Oh, we don't actually let you query what format the encoder expects until a later API than you're using. Just try them in a loop until one doesn't fail, makes perfect sense.

The camera was a party too, added a listener for Camera session events and the app crashed. Yay.

<comment><USER30> The Android camera issues you reference reached all the way up to the higher level Java APIs, at least back when I was doing Android development from 2012 until about a year ago. Dunno if it has gotten any better since then.

All of the MediaCodec APIs were quite powerful, but did nothing to "keep the easy things easy" or hide much of the lower level hardware details from your app.

This is kind of a theme in Android (or was... my experience is slightly out of date right now).

As mentioned by "McDev" in what is currently the top post on this thread it is a good idea to use time-tested third party libraries to do things that you'd kinda expect the OS to handle naively because the OS level APIs don't do a great job at abstracting any of the details away even for things that you'd think you shouldn't have to worry about, like basic image loading with caching and resizing. And that's just still images, never mind when you get into video de/compression.

Hopefully this is something the Android team is working on as they shift more effort toward Kotlin and Jetpack but I haven't had enough recent hands-on experience to know if this is better now.

<comment><USER31> It still is the same theme.

For Vulkan and real time audio they expect you to checkout GitHub repos and compile from scratch, instead of having the tooling as part of the NDK.

Likewise after 10 years they still expect everyone to manually write JNI bindings, instead of providing another productive way for language interop.

</comment></comment></comment><comment><USER32> If you built it, they wont come. Without marketing, the odds of your customers discovering the app (amongst a sea of garbage) are insanely low. I tried a Tennis app in 2009 and even back then it was competing with hundreds of other apps, now its mist likely 10's of thousands. Heart breaking.

<comment><USER33> Sometimes if you build it, they will come. I launched a music app in 2012 (student project), and over its lifetime (6 years), I had 95k downloads and 7 million sessions on the app.

<comment><USER20> Some apps have very low viral aspects like biz apps or Utils, also some standalone single player games. They will be at the bottom of a search result of 100s when first released. Quite demoralizing

</comment></comment></comment><comment><USER31> The years it took to realize how under-resourced the NDK team is, bothering to create my own NDK wrappers to work around the NDK bindings and forced JNI calls, manually dealing with dependencies across NDK projects.

In retrospect, it would have been easier to just rewrite the whole thing in Android Java.

Basically, how little Google cares for game related development workflows on Android.

It just took them 10 years to acknowledge this, go figure.

[https://android-developers.googleblog.com/2019/12/android- ga...](https://android-developers.googleblog.com/2019/12/android-game- sdk.html)

</comment><comment><USER34> Don't underestimate the value of build tools. Just because you know Xcode and Swift or Android Studio and Kotlin (or their antecedent languages) are you done. Finally having a senior dev who knows what he's talking about has done more for me in the past two years than the previous 8 of reading blog posts and hacking. He's shown me the real value of build scripts. Today even my personal iOS projects are dependent on a combination of Swift, Ruby, YAML, and Kotlin to build. It's complicated to set up but I can prove that my code works.

<comment><USER35> Can you explain more? I'd like to learn more about this.

</comment></comment><comment><USER36> Been doing Android development for 8+ years. The main thing to realize is that nobody actually knows what they're doing. You'll have a problem and spend hours and hours just searching for "the answer" but it's not out there. Everyone who has solved it has used their own hacks, and they're not going to be able to transfer the hack to you.

Once you realize this it's somewhat liberating. You focus on the bug/feature and not the method. One time I was trying to solve a particularly nasty layout-at-runtime problem and just realized I could write my own ViewGroup and lay it all out myself, pixel by pixel, faster than fighting RelativeLayout or whatever. And that code is more stable than something where I import some library that's not going to be maintained.

</comment><comment><USER37> I regret it took me 5 years of mobile development (both platforms) to realize I really don't like writing GUI code. I switched to backend and infrastructure work and I've been a lot happier since.

</comment><comment><USER38> Example code is invariably dross from an architectural point of view.

Unit tests are still valuable in a mobile environment.

Most good apps are simple. Simplicity is not easy.

Some aspects of mobile development will become far easier over time (memory management on iOS) while some will remain in a baffling stasis (refactoring tools in Xcode). It's impossible to predict which category an aspect belongs to ahead of time.

There are times to embrace the approach taken by a platform, and times to distance yourself from it.

Mobile as a platform will crush all before it and transform society, while most contemporary technological hopes will remain geek toys.

The remembering self can really help out the experiencing self; you can never learn too much about the past, present, and future of mobile programming.

</comment><comment><USER39> That JavaScript (and prior to that, Java) would work for mobile, one platform to rule them all.

Work = looks and feels native, good performance, good widget collection, development that doesn't fight the platform, and all those available not 10 years after the platform was introduced.

<comment><USER40> I can only agree with that. If you build a web app within a we browser you can use whatever payment method you want and the platforms don't take 20% for every transaction...

</comment></comment><comment><USER41> For android, get good at handling null everywhere in everything checking all the time now, or learn it the hard way later. You'll be spending lots of time tracking down "wait, how could that have ever possibly returned a null?"

Ditto async and observer and livedata type stuff. Never move data between things any way other than async. MVVM and all that, with caching repositories and stuff.

Architecture changes fast enough that you have to be careful not to waste time and effort supporting some ancient version and NIH writing your own implementations of stuff that's newly added in current versions. Yet if you try to ship using cool alpha quality features, that's a whole different headache. For extra fun you can end up with both problems at the same time in different parts of the app.

</comment><comment><USER42> I got pretty good at Android development and made a few apps that don't have many downloads but I'm still proud of and wanted to share with my friends and family.

I regret that all of my friends and family have iPhones.

</comment><comment><USER43> I develop for Android since 2011. Since 2016 I also do more iOS. I mostly regret not looking into new developments faster. Things like Kotlin and Architecture Components. They are great, so at least experiment a bit with them to see what all the fuzz is about. Try to keep up!

Also, I wish I realized that Google Play is giving you a lot of stats and data about your apps (store) performance these days, which in most cases can help pinpoint a issue with your reach/growth.

I also regret everything about Objective C ;)

</comment><comment><USER44> I regret thinking that Xamarin was a good idea.

<comment><USER45> Amen. Management at a company I worked as were convinced that Xamarin was One True Path for mobile development. They were sold the idea that a Windows dev could instantly be productive in Xamarin without needing to understand the underlying platforms significantly.

To be clear, I do think Xamarin remains an interesting idea, but it's absolutely not the first thing I'd reach for when starting a x-platform mobile project.

<comment><USER46> > but it's absolutely not the first thing I'd reach for when starting a > x-platform mobile project.

What would you go with now?

<comment><USER44> Ionic. HTML, JavaScript, and CSS work on (darn near) everything.

</comment></comment></comment></comment><comment><USER47> On iOS:

• Interface builder(especially Storyboards) is inferior to using UIKit straight from code

• Coordinator pattern, which lets you split logic and view controllers. [https://www.hackingwithswift.com/articles/71/how-to-use- the-...](https://www.hackingwithswift.com/articles/71/how-to-use-the- coordinator-pattern-in-ios-apps)

</comment><comment><USER48> On Android: being paranoid about multithreading in all the wrong places before I stopped worrying and love the main thread.

Move actual work off thread whenever possible, but never try to integrate off threat memory access by hand using synchronized and friends, just enqueue your final result plumbing on the main looper.

Be paranoid about multithreading in the right places, particularly when you hand a callback to some black box. A callback that checks the thread it's running on to enqueue itself on main if necessary might become a familiar pattern. You might start to hate all callback methods that don't return void.

</comment><comment><USER49> I can't really say I regret the path I've taken since had I not taken it, I wouldn't be able to form sound evaluations. I'd always sought out cross- platform development tools first on servers, then desktop, and mobile. Flutter/Dart comes closest at the moment but game engines might also work for certain apps. I'm glad I never bought into React-Native the worst of worlds. It's rare for an app to _require_ native widgets and having to deal with two different sets and their idiosyncrasies isn't solving the problem.

</comment><comment><USER50> I started with iOS in 2009. I wish I hadn't used Core Data, and made the decision to store lots of large binary blobs in it. Changing the schema became impossible, because the migration process often crashed or ran out of disk space in production. That, coupled with lots of Core Data crashes that persist (pun intended) to this day. It may have been easier to just use SQLite directly.

My decision to use NSThread for worker threads wasn't optimal either, but there weren't many async options in 2009 (Remember ASIHTTPRequest?)

</comment><comment><USER40> That mobile web apps aka PWAs are a perfect fit for classical data-driven applications. The return on investment for 2 native apps vs. a PWA is far...

<comment><USER51> You're not allowed to use full PWA capabilities on iOS though right?

<comment><USER40> [https://medium.com/@firt/progressive-web-apps-on-ios-are- her...](https://medium.com/@firt/progressive-web-apps-on-ios-are- here-d00430dee3a7)

One can always build a hybrid app from a pwa...

</comment></comment></comment><comment><USER52> I should've started a year later when ARC was introduced (I started learning between 2011 - 2013).

Learning iOS dev with reference counting as a memory management system was really painful. My programming skill wasn't up to speed yet to "just" learn a new language. I only knew some university Java at the time. And while I did write impressive projects with it, I wasn't strong enough in an algorithmic sense.

Learning a framework _and_ learning memory management, and kind of needing to deal with pointers but not really proved to be too much.

When ARC was introduced it was a breeze.

Now, when I read this whole comment, nowadays I'd think: this is such nonsense. Memory management should not be a barrier to learn iOS dev. But when you're in that weird space of that you kind of know how to program (5000+ lines code) but you _really_ need to get into it, and it doesn't feel natural yet. Then, yea, it does matter a lot.

A few years later I learned C and had no issues learning pointers or memory management. To be fair, I didn't need to use any frameworks with C.

</comment><comment><USER53> The whole damn thing. I'm self taught web developer, server management, backend stuff. I love a Rest over HTTP API. X Code and all the sims do not jive with my brain. Swift helped a bit. But only ever able to build a bouncing ball game. The process of launching on an app store alone seems insane. I started by FTP and Perl then PHP. I pay people to write code these days.

</comment><comment><USER54> React Native isn't nearly as good as the hype suggests, and the pain only gets worse as your project grows.

<comment><USER55> Why do you say that? What are some of the issues?

<comment><USER54> The tooling is just unstable in general in my experience. You never know when things will get into a bad state and you have to kill everything and clear your caches and restart. And then in my experience styles don't actually behave the same way on iOS and Android. They also continue to make breaking changes so you always have to be worried about not only your own code but your dependencies handling that appropriately. The debugger itself is also prone to crashing and requiring full restarts at inconvenient times. Overall, I feel like the amount of random bullshit and platform specific workarounds I have to do makes it so I'm not really saving time VS having 2 native apps and I'm less confident about the overall quality of my software. There's also A LOT of valuable things in the native SDKs that no quality wrapper exists for, so you're missing out on a lot of productivity benefits of the underlying platforms.

</comment></comment></comment><comment><USER56> If you think you will ever be cross platform, do yourself a favor and write as much of the business logic as you can in C++ or C. The platform-specific piece should be small and "just enough to make the platform happy". Do everything else portably from the start.

</comment><comment><USER57> To get into mobile sooner. I was tired of the web and burned out needed something different. I'm getting way more work and enjoying myself a lot more. I hope to have a long career programming so maybe I'll change platforms again one day.

</comment><comment><USER58> MVC, the way it's implemented in UIKit, leads to code that is very difficult to test, mixes business logic and view layout and navigation, and leads to massive view controllers. You have to be very careful to avoid it.

</comment><comment><USER20> When doing custom UI animation code that isn't native, expect 2-10x more development, testing and polish, and still won't achieve it perfectly.

</comment><comment><USER59> I built an iOS game using Sprite Kit and had to hack together support for multiple screen sizes later which was kind of a pain. Likewise they make you provide an app icon of like 25 different sizes. Have not done standard UI work yet but unless you use a "reactive" set of layouts I can only imagine the pain.

<comment><USER20> Yeah if you plan the development around different screen sizes in beginning would be best, otherwise architectural changes will prob be needed unless like you side to hack it

</comment></comment><comment><USER60> I wish I had realised that Android app development ecosystem (the dev tools, API, documentation, gradle, dependency management etc) is a shit show and is going to remain a shit show and I should have moved to backend early in my career. Now companies are very reluctant about it.

<comment><USER61> reluctant about what? backend developers?

</comment></comment><comment><USER62> The xcodebuild command line tool is insanely powerful. The one provided by vanilla Xcode is awful.

</comment><comment><USER63> I invested lot of years on Android because it is, promoted as open source etc ... but currently it is just their advertising platform, complete control of it developer (removing developer accounts, blocking apps and devices ) and full monopoly !!

</comment><comment><USER64> Go cross platform as soon as you can! Most folks preaching against it don't have the practical experience. If you're not writing games and writing a non graphic intensive app, it's the way to go.

</comment><comment><USER8> That you need a singleton pattern to ease the gps refresh problem. Totally rewrite the program before submit to Apple store.

</comment><comment><USER65> How hard it would be to Port.

</comment><comment><USER66> flutter.

</comment><comment><USER67> That Apple and Google would move the goalposts so often, and with such vigor, that it'd result in classes of programmers who do nothing BUT support the mobile platform for development.

It has been a nightmare of keeping up with the majors, just to be able to enter their carefully curated arena.

Nowadays when I build an App, I do Linux/Mac/Windows first, and the iOS/Android release, next. Fortunately there is a vast industry out there for toolkits and frameworks for solving The Platform Problem™ which has been shoved down our throats by a ravenous corporate culture which is hell-bent on ensuring that they own the computing platforms of the future.

<comment><USER68> What, you don't look forward to WWDC to find out what syntax got arbitrarily changed with no explanation?

</comment></comment><comment><USER68> On the iOS side, I regret not knowing how horrible Xcode is and how horrible Apple's documentation is. On the Android side, I regret not realizing that no matter what kind of slick new well documented APIs Google releases we will all be writing code for Android 4.4 for the rest of our lives. Also, I wish I knew mobile developers are some of the lowest paid developers other than game industry peons.

<comment><USER69> I have recently looked at surveys in my country and mobile developers are one of the most paid programmers out there, especially the ones experienced with Swift. What does cause the low pay in your country? Logically the sector is ever expanding and there is always demand for hires with any experience.</comment></comment>


Heck of a drive: OC to SF - <AUTHOR>

Just drove up to SF from Orange County.  The team and I are new to the Bay Area. Would love to meet other founders for coffee, lunch, or to go out in town. Will be here until Sunday evening.
Thanks for the help guys...
Meesh <comment><USER2> I see you are more about fishery monitoring but an old friend of mine is big into reef tanks and is a biologist at cal academy and takes care of the big aquariums there. I'll point him to your stuff anyway. How far along are you with your product? Feel free to email me.

PS. Put your email address in the about text field so people can contact you off list.

<comment><AUTHOR> Hey Andy. Will do. I'll shoot you and email.</comment></comment>


Introducing Spark Datasets - <AUTHOR> https://databricks.com/blog/2016/01/04/introducing-spark-datasets.html <comment><USER2> I would be quite interested to see how Dask, Spark and Dato's(or Graphlab's) SFrames fare relative to each other. My hunch is none dominates the other totally in performance and that each would have their sweet spot. Are there any well done, executed_in_good_faith benchmarks available.

</comment><comment><USER3> Does somebody know why these improvements could not be integrated into DataFrames directly?

Why add another very similar layer of abstraction?

They mention:

"Unification of DataFrames with Datasets – due to compatibility guarantees, DataFrames and Datasets currently cannot share a common parent class. With Spark 2.0, we will be able to unify these abstractions with minor changes to the API, making it easy to build libraries that work with both."

Anybody know what those "compatibility guarantees" are?

<comment><USER4> Dataframes aren't strongly typed (while RDDs are).

It's difficult to add strong typing to an existing API.

I certainly prefer using DataFrames generally, but sometimes you need to switch to RDDs because some operations are easier.

Hopefully Datasets bridge the gap well. I haven't used them yet, but the examples look nice.

</comment></comment><comment><USER5> Really looking forward to this dropping! Writing complex data out of spark jobs is super easy, but getting it back into strongly-typed-Scala has been a big pain point.

The experimental release is a bit broken though, encountered a pretty big bug: [https://issues.apache.org/jira/browse/SPARK-12714](https://issues.apache.org/jira/browse/SPARK-12714)</comment>