1000+ Nokia workers have walked out in protest (in English via Google Translate) - <AUTHOR> http://translate.googleusercontent.com/translate_c?hl=en&ie=UTF-8&sl=fi&tl=en&u=http://www.hs.fi/talous/artikkeli/1135263739290&prev=_t&rurl=translate.google.com&twu=1&usg=ALkJrhgcMoG2wO4B5oGULvdpMwc0RkStCA <comment><USER2> Does this remind anyone else of SGI?

\- Total domination of their own field

\- Resting on laurels while others snatch the market from under them

\- Panic

\- Get a CEO from Microsoft

\- CEO quickly decides that the O/S developed in house is not worth maintaining. And that the right O/S is no other than Microsoft's offering

\- Company continues dive to irrelevance, albeit at a much faster rate than before

Well, the last one hasn't happened to Nokia. yet.

Goodbye old Nokia. You will be missed.

<comment><USER3> _Goodbye old Nokia. You will be missed._

By whom? The old Nokia was a terrible software company, with so many abject failures at creating platforms (Symbian, N-Gage, Ovi, etc.) that I don't think anyone else in this business can compare.

It's a good thing that they're getting out of software and concentrating on stuff they're actually good at.

<comment><USER4> Symbian was not a failure... it was a giant succes for quite a long time. That's like calling MS-DOS a failure.

<comment><USER3> A success by what metric?

As a platform, surely not. The wheels came off by the end of 2008 when S60 5th Edition went touch-only, leaving keyboard devices still shipping with the hopelessly outdated 3rd Edition. Symbian touch devices never gained any platform traction.

Was it a success as a software foundation upon which handset makers could innovate, as had been the original idea behind Symbian? No. Everyone that used Symbian abandoned it for more flexible alternatives. The lack of a unified UI development track didn't lead to the hoped innovation, but merely fragmentation that ultimately doomed Symbian. (It didn't help that the most popular UI layer, Nokia's S60, was so poorly designed and thoroughly mismanaged.)

I actually use a Symbian^3 device, the Nokia N8. It's not bad at all. I love the physical design, and the software works fine for what I do (although the browser is a turd, it's replaceable by the fine Opera).

Still, I can't escape the feeling that this is the OS that Nokia should have had over two years ago. Also, it's a development dead end. Symbian^4 was supposed to be a UI rewrite, but it failed. The promised improvements to S^3 have been slow in coming. (Still no Qt 4.7...!)

How is Symbian a success at this point? What reason would Elop -- or anyone else -- have to believe that the existing software development structure at Nokia could substantially improve this situation?

<comment><USER5> A success by what metric?

how about global market share?

2008: 52.4% of smartphones (RIM 17%, Apple 10%) [1]

2009: 47.2% of smartphones (RIM 21%, Apple 15%) [1]

Android came in at 0.5% and 5% for those two years.

Gartner forecasts that Symbian will remain in the number one smartphone OS position until 2014 when it is contested by Android [2]

Sure, it's in decline now, but it's been a phenomenal success.

[1] <http://www.canalys.com/pr/2010/r2010021.html>

[2] <http://www.gartner.com/it/page.jsp?id=1434613>

<comment><USER6> Comparing market share of Symbian devices to iPhone or Android is like comparing market share of bicycles to market share of cars.

Symbian OS has several version. The version that ships in volume powers devices like Nokia C1-01 [http://store.nokia.com/webapp/wcs/stores/servlet/productdeta...](http://store.nokia.com/webapp/wcs/stores/servlet/productdetail_10500_10101_-1_10000740) or worse. It's not the same product as iPhone or Android or even the old Palm OS shipped on Treo.

The share of Symbian OS devices shipping a version comparable to iPhone or Android is a blip on the radar. A drop in the ocean. And a peasant among Kings.

<comment><USER3> No, that's a misunderstanding. The C1 and its ilk are not Symbian devices.

Most of Nokia's cheap phones are on the Series 40 platform, which is a closed "non-smart" OS (that has nevertheless grown some fairly smart features recently, like QWERTY keyboards and a HTML browser).

Symbian by Nokia comes in three flavours:

\- Symbian^3, the latest and greatest -- e.g. the E7: [http://www.forum.nokia.com/Devices/Device_specifications/E7-...](http://www.forum.nokia.com/Devices/Device_specifications/E7-00)

\- Symbian^1, the previous touchscreen Symbian version (a.k.a. S60 5th Edition): [http://www.forum.nokia.com/Devices/Device_specifications/C5-...](http://www.forum.nokia.com/Devices/Device_specifications/C5-03)

\- Symbian S60 3rd Edition, still used on keyboard devices: <http://www.forum.nokia.com/Devices/Device_specifications/E72>

</comment></comment></comment></comment></comment></comment></comment><comment><USER7> Let's see

1\. Hire someone from Microsoft to run the company

2\. He says "our platform is burning, we have to do something drastic" which most people interpret as "prepare to come up with a strategy and fight like hell to win".

3\. Guess what, he already had something in mind! It was "throw out our current reasonably successful development efforts and become a licensee of Microsoft's failed platform instead". And piss off all our QT-based app developers at the same time.

What could possibly go wrong?

I seriously wonder if this guy might not end up having to leave and not set foot in Finland (or the EU) again for fear of arrest. I have a feeling some Finland business regulators will be going through his emails with a fine- toothed comb.

<comment><USER8> It's amazing how hyperbolic people are being about this, presumably out of blind Microsoft hatred.

Pretty much everyone agreed that Nokia's Symbian/MeeGo strategy was a failure, that Nokia were quickly losing marketshare and that they needed a new OS.

The only options were Android and Windows Phone 7. WebOS would have been a better fit than either, but that option had already been and gone.

I think there are compelling reasons why Nokia would choose WP7 over Android.

There is a competitive advantage in being the flagship manufacturer of a platform, they won't have to play catchup against much more established competitors, or have to directly compete with cheap Chinese phones from companies like ZTE in the low-end. That's without going into the favourable terms that Microsoft no doubt offered.

<comment><USER9> I'm not sure everyone here fully appreciates just how bad things are at Nokia. It's been a LONG time coming. Their software development structure, from top- to-bottom, is just awful. You can see it in Symbian (which was developed independently but with much the same issue).

I have to tread lightly here, as I don't want to get anybody in trouble... but I can assure you that the new CEO is doing very much the right thing. Software development is not a core competency (or even a competency) at that company. It's just not. I'm not surprised that about half of tampere left, they are going to be hard hit by this. They should be.. the quality of the work just hasn't cut it.

Their best hope to survive today is to tie themselves to a much healthier eco- system. I would have thought Android to be the very logical choice... but the Microsoft move certainly makes sense.

<comment><USER3> _Software development is not a core competency (or even a competency) at that company. It's just not. I'm not surprised that about half of tampere left, they are going to be hard hit by this. They should be.. the quality of the work just hasn't cut it._

That's the honest truth. When Nokia opened the Symbian code three years ago, it offered a peek into their software development process... And it wasn't a pretty sight.

I used to spend a fair bit of idle time browsing through the Symbian Foundation wikis and forums (all now offline). It seemed that there were basically two kinds of people working on the operating system. The guys in England, who used to work for Symbian Ltd, were pretty smart but arrogant; in old-school programmer style, they were only concerned with managing some extremely narrow domain and couldn't take any criticism.

Then there were the Finns at Nokia, who were either completely uninterested and oblivious to the world around them, or just obviously incompetent at the job they'd been given. An example of the latter was the "Direct UI" proposal in 2009. It was supposed to outline a completely new touch UI paradigm to ship in Symbian^4. All there was was a few pages in broken English that essentially said "it should be like iPhone because touching stuff is cool".

Unsurprisingly, Symbian^4 was canned last October after years of development. I'd like to know who had made the decision to put the same people who had mismanaged the previous S60 user interface in charge of creating the replacement... But that's how it went at Nokia. No one ever lost their job for screwing up the software -- until now.

</comment></comment></comment></comment><comment><USER10> Whether it was Android, Microsoft, or slowly dying, people working there would be affected, so I'm not sure the choice of Microsoft changes things too much from that point of view. With Android, perhaps they could have kept more people on board to hack on it and customize it, but still, the axe was going to fall.

Should be interesting to see how this is handled in Finland. Stock is down, layoffs, and some "arrogant foreigner" in charge would be a recipe for even more change in some places.

<comment><USER11> Nokia had been moving towards an open-source culture. Those are the types they've attracted the last several years.

This is a very radical departure from their previous path.

<comment><USER12> Yup, I started liking Nokia again because of their Maemo/Meego engagement. I'm an iOS developer but in private I use a Maemo phone (the N900) which fulfills my geek needs.

I hoped for a cool N900 successor with a cap. touch screen and a little more power but ... well ... I guess Nokia will make something half assed.

Meego phones (which run a real linux - not closed bullshit like android) would have been an awesome alternative to iOS and Android. At least for the more geeky consumer. :/

Good bye, Nokia.

<comment><USER13> Hear hear. An open O/S for my phone named the same as a Lovecraftian monster...

I was starting to read the Qt docs, Gnome/Mac user and all. :-(

<comment><USER14> Knowing a little Qt isn't a bad thing, and it's kind of fun to prototype stuff on a desktop and have it run in an embedded environment with a quick recompile.

</comment></comment></comment></comment></comment><comment><USER15> If I interpret the page correctly, somewhere between 1000 and 1500 employees at this location ALL worked on the Symbian OS.

THAT might have been part of the problem. 1000+ people for a mobile OS? And people wonder why Nokia can't innovate fast enough to keep up with iOS or Android?

</comment><comment><USER16> It's exactly this sort of tech expertise revolt that happened at the largest Smalltalk company at the time -- when out of touch management announced the company was going to go the direction of Java/JVM.

This is not an indication of mismanagement. This is mismanagement (of employee expectations, culture, and perception) plainly visible in public.

Nokia needs to figure this out right now, or they are going to bleed intellectual and technical assets.

<comment><USER17> In Finland, where are they going to bleed to? What options do the regular (under 80th percentile) Nokia employees have? If a company of that size were to lay off 100's of technical people here in the Netherlands, that'd be a large supply to absorb for the industry, and especially those with 10-15 years of highly specialized skills (antenna design, phone chipset design etc).

<comment><USER16> It doesn't matter if the employees leave for startups or other companies, or if they just don't cooperate wholeheartedly. In either case, resources they used to have access to are lost. Management needs to do something, or they'll bleed intellectual captial.

 _If a company of that size were to lay off 100's of technical people here in the Netherlands, that'd be a large supply to absorb for the industry, and especially those with 10-15 years of highly specialized skills (antenna design, phone chipset design etc)._

If their jobs were based in something technical and had significant value, they'll be able to find employment elsewhere. This was also true of former employees of the Smalltalk vendor.

The thing to remember here, is that your most valuable employees are also the ones that can find new jobs fastest.

<comment><USER17> What I meant was, people may not be running so fast if they have no options.

Re: the last sentence, yes that's exactly their problem and why I said 'under 80th percentile'. The best employees know the fat days are over and are moving out asap, leaving the hanger-ons to run the place. The rest can't get other employment so will just sit there hoping for a miracle.

But yeah, bottom line: Nokia is still screwed.

</comment></comment></comment></comment><comment><USER18> I guess its a ballsy move, but it was much needed. Going with Android would have killed Nokia anyhow as they would be just another face in the already crap filled Android market ( and before anyone shoots me down, for every decent Android handset out there, there are 3 other really crappy ones)

Think about it though, what do they have to lose. The company was dying rapidly, There are relatively few WP7 products on the market, so they can stand out in the crowd, Microsoft have absolutely 0 to lose and everything to gain as Nokia may just pull this off.

But then again, I actually thought that Paul Thurrot had a good idea when he suggested that Microsoft and Nokia merge. Its not quite a merger but if this move actually works I think a merger is in the future.

</comment><comment><USER19> If I understand the garbled translation, the Nokia workers took advantage of extremely flexible work time to stage a coordinated, but totally non-rule- breaking walk out. I've never heard of this sort of half-strike method, but it's interesting. Is this something that is common in Europe or Scandinavian countries where a more flexible work schedule is common?

<comment><USER20> Workers in the United States sometimes stage "sick outs" where everyone calls in sick on the same day, especially if they're in jobs where they are prohibited by law or contract from striking.

Coordinated work slow-downs are another example of a "half-strike"

</comment></comment><comment><USER21> Am I the only one happy that WP7 is NOT dead?

I very much prefer a threesome! Every mobil user will benefit from this. And this is not like Desktop. Everybody will have to bring their A-Game.

<comment><USER22> I think the reactions are split into camps:

1) "Windows Phone is cool":

Think of all the people that like the tech (.Net) or the visuals (Remember the recent "No chrome in the UI" thread). That want this platform to succeed. I guess if you're in this camp the news are great: WP7 gains a very experienced hardware vendor. You can expect a couple of good/decent handsets soonish, pushing WP7 (with a lot of marketing and money) and thereby solving the chicken and egg problem (platform <-> apps) with cash.

2) "I liked Nokias history", "I'm a QT/maemo/MeeGo fan"

In this case the news are bad: Nokia changes direction. How much only time will tell, but the company that over the last couple of years slowly started to adopt open source is now going for a closed platform. QT and MeeGo are more or less declassed in the press release (research..? N770, N800, N810.. They did that in the past, the devices were unusable for non-hackers. I know, I own one). In this case you don't care much about WP7, you basically moan about the loss of plans that YOU had for that company/platform. That's what I see alot around now.

I understand both points, but the latter seems both easier to understand (I've got a bunch of maemo shirts, the N810 hardware etc..) and at the same time completely irrelevant (Seriously.. While mom and dad might have heard about Windows Mobile and that a new version is coming, who around you cared about MeeGo to succeed?). I'm quite sure this is the death sentence for MeeGo handsets. But we haven't even seen one of those yet. How do we know that we lost something of value? Please - no ideology (while I'd probably be with you, that's not something a company of that size should care about in a self- crisis) based answers about being open etc..

</comment></comment><comment><USER23> No PR campaign can save Nokia from this well-deserved disaster.

Btw, NOK is down 15%

<comment><USER24> Better than continuing with Symbian and having to lay off all the employees in a few years time.

<comment><USER25> The stock market appears to predict otherwise, believing that this move _lowers_ the net present value of the company. Of course, stock markets aren't necessarily accurate prediction markets, but given suitable efficient-market hypotheses they're an approximation of such a thing.

<comment><USER26> The stock market isn't predicting anything. It just believes given the current information and Nokia's decision, $NOK's value deserves to be lower _now_ than what it was prior. It's just a current snapshot - no indication of the company's future whatsoever.

<comment><USER27> Well technically a company's stock value is supposed to represent the discounted present value of all future profits. So you can interpret a reduction in stock price as an indication that the market expects profits to be lower in the future.

<comment><USER28> PR scandals do that. They also frequently have little bearing on a company's profits, unless it's sufficiently nasty to warrant significant numbers of boycotters for longer than the average consumer memory is.

Stocks are nowhere near that deterministic. When people _think_ others will jump ship, they try to jump first, to lose the least money. When people _think_ others will want buy, they buy first or sell higher, because they can get away with it. There's more games theory than future prediction if you ignore long-term investors, as they make up a microscopic amount of the daily trading and thus the daily prices of stocks.

</comment></comment></comment></comment></comment></comment><comment><USER29> Human-translated version: [http://www.hs.fi/english/article/More+than+1000+Nokia+employ...](http://www.hs.fi/english/article/More+than+1000+Nokia+employees+walk+out+in+Tampere+in+protest+at+Symbian+phase- out/1135263743059)

</comment><comment><USER30> Well maybe if Symbian wasn't a total piece of shit they wouldn't be shutting it down. Seriously, I owned an N97 for a while and that was the flagship product of Nokia for sometime, the OS is complete shit. Hardware was awesome but the OS was almost as bad as the old Windows Mobile OS.

</comment><comment><USER31> The Nokia n900 (Maemo) albeit with some flaws, is the greatest phone I will ever own. Allow me to explain.

I live in Canada. We get a lot of snow over here. Last winter, I lost my Nokia phone. I remember it was a night we had a huge snowstorm, and I stayed in drinking hot chocolate by the fireplace only to wake up the next day stressing out because I couldn't find my phone. After an hour of searching, I came to terms that I must have lost it in the mall the day before.

I end up leaving later that day, and find it on my driveway buried in snow. Snow plows came twice and cleaned my driveway and they must have driven over it with the plow part of the truck. Not only that, it was completely submerged in snow for over 12 hours. I picked it up, brushed off as much snow as I could, and tried using it.

It still worked. It didn't even have any scratches (1 minor one). I've owned many phones in my life, and most of them break in the stupidest ways. Nokia is the rambo of phones.

<comment><USER32> I like the WP7 UI so I'm looking forward to that combined with Nokia's build quality

</comment></comment><comment><USER33> I wonder what was the reaction if Nokia would have decided to adopt Android?

</comment><comment><USER34> This kind of behavior makes me wish at-will employment was the norm throughout the world. If you aren't happy, quit. Change was clearly needed and change was made. Work hard for your company or find a different place to work that'll make you happier. Everyone thinks they could make better decisions.

<comment><USER35> This kind of behaviour makes me wish golden parachutes for executives weren't the norm throughout the world. If you can't make money for the company, quit or be fired.

Isn't it amazing how "at will" seems to apply to both employees and management, but somehow management's version of "at will" is considerably lower risk than the employees, even though the manager has considerably more influence over their future.

<comment><USER36> I don't really know the answer, but are golden parachutes really the norm for many executives? We hear about certain extremely-well-connected CEOs of very big companies, but that's hardly a representative sample of executives.

</comment></comment></comment><comment><USER37> Nokia share price has a 15% drop (<http://www.google.com/finance?q=NYSE%3ANOK>).

Time to speculate?

</comment><comment><USER38> I'll miss Series 40 phones. A basic, no frills dumb phone OS with a UI that made sense. I'll miss the flexibility of Python for Series 60, even though the Series 60 OS was crud.

</comment><comment><USER39> The end of the last ten years of Nokia's downhill: a quiet disappearance into a puff of irrelevance.

</comment><comment><USER40> I guess we won't be seeing a RIM, Microsoft merger any time soon then.

</comment><comment><USER41> Heh heh, try to back-button yourself out of that page.

<comment><AUTHOR> Although it works for me, I'd imagine that's a Google Translate issue.

Here's the original article URL: [http://www.hs.fi/talous/artikkeli/Nokian+ty%C3%B6ntekij%C3%A...](http://www.hs.fi/talous/artikkeli/Nokian+ty%C3%B6ntekij%C3%A4t+protestoivat+ulosmarsseilla+Oulussa+pel%C3%A4t%C3%A4%C3%A4n+satojen+ty%C3%B6paikkojen+puolesta/1135263739290)

</comment></comment><comment><USER42> Regardless of whether you agree with the CEO's position I think it's pretty childish to walk out on your job.

<comment><USER22> If you are afraid that this decision means that your job is in danger it's quite okay to show protest in my book.

And - they even did it on their own free time (using flexible working time), not 'stealing' paid time for their protest.

I like that move a lot.

<comment><USER42> I apologize for not fully reading the story before I commented. Using your own PTO is quite admirable. I was under the wrong impression.</comment></comment></comment>


The Great American Bubble Machine - <AUTHOR> http://forums.somethingawful.com/showthread.php?threadid=3159732&pagenumber=1

<comment><AUTHOR> Article's a bit hyperbole, but I think it might be interesting to HN for its description of the dot.com bubble:

"The basic scam in the Internet Age is pretty easy even for the financially illiterate to grasp. Companies that weren't much more than pot-fueled ideas scrawled on napkins by up-too-late bong-smokers were taken public via IPOs, hyped in the media and sold to the public for megamillions. It was as if banks like Goldman were wrapping ribbons around watermelons, tossing them out 50-story windows and opening the phones for bids. In this game you were a winner only if you took your money out before the melon hit the pavement.

It sounds obvious now, but what the average investor didn't know at the time was that the banks had changed the rules of the game, making the deals look better than they actually were. They did this by setting up what was, in reality, a two-tiered investment system - one for the insiders who knew the real numbers, and another for the lay investor who was invited to chase soaring prices the banks themselves knew were irrational. While Goldman's later pattern would be to capitalize on changes in the regulatory environment, its key innovation in the Internet years was to abandon its own industry's standards of quality control.

"Since the Depression, there were strict underwriting guidelines that Wall Street adhered to when taking a company public," says one prominent hedge-fund manager. "The company had to be in business for a minimum of five years, and it had to show profitability for three consecutive years. But Wall Street took these guidelines and threw them in the trash." Goldman completed the snow job by pumping up the sham stocks: "Their analysts were out there saying Bullshit.com is worth $100 a share."</comment>


App Rot - <AUTHOR> http://www.marco.org/2014/07/28/app-rot <comment><USER2> Seems like the centralized app store model with week-long reviews and free-to- play IAP-addiction-reliefs has lead to a proper race to the bottom. When you have to peddle your wares in a crowded spot next to a million clones which are free or $1-2, with no proper way to do trials or paid upgrades, and you also have to take the full risk of development upfront with a chance for being rejected during final review, it seems like everything is conspiring against indies wanting to invest a lot of effort into a project they really care about. It appears you either have to be a AAA megastudio or a cheap copycat to have a chance to make a profit in 99.99% of the cases. Or be someone like Facebook who can invest a bunch of effort into a super polished product like "Paper" just for fun.

For example: Imagine spending 6-12 months on your own dime developing a really neat bitcoin wallet app that you'd like to offer for perhaps $20-30. It'd be completely crazy. Who knows if "virtual curriences" are banned or allowed in the app store review process in 12 months?

<comment><USER3> Why aren't developers choosing to build PC apps instead? Stardock said that their worst-performing PC game earned more revenue than most iOS or Android apps for which they could obtain revenue numbers.

On PCs, it is still possible for developers to sell from their own website, without paying a 30% fee to a platform app store.

PCs may be a numerically smaller (hundreds of millions vs. billions of devices) market, but customer perceptions of software value are reflected in an order of magnitude difference in price expectations.

<comment><USER4> I know some indie game developers.

Plenty don't develop for any particular platform. You write your code in Unity3D, and then build for all the platforms it can (Android, IOS, etc) then you build your app for Steam where you make it run on all platforms (ie Windows, Mac and Linux) which is easy because it is almost just a button in Unity.

Then you hope that enough people buy your game to earn the development cost back. You don't develop just for one platform because it is unlikely that you will make enough money to get it back.

<comment><USER3> Does the Steam ecosystem provide any support for marketing and discovery of new games, or are users relying on word of mouth networking?

[http://en.m.wikipedia.org/wiki/Steam_(software)](http://en.m.wikipedia.org/wiki/Steam_\(software\)) mentioned Steam Greenlight for estimating demand for new games, but it is apparently being phased out.

Is it limiting when a platform (Apple, Valve, Amazon, etc) owns the customer relationship? Seems like it would be difficult to apply conventional marketing techniques to learn about customers, if the platform provider owns the user's contact info.

<comment><USER5> An interesting recent article about publishing on Steam: [http://gamasutra.com/blogs/BurakTezateser/20140717/220624/Dy...](http://gamasutra.com/blogs/BurakTezateser/20140717/220624/Dynamics_of_Steam_as_a_Sales_Platform.php)

Generally, you still have to do your own marketing. There's no great meritocratic system out there for discovering games (and pretty unlikely one can arise IMO - it's impossible to objectively class a game as good or bad).

<comment><USER3> Found a comment on an article linked from the one above: [http://kotaku.com/i-think-gabe-has-mentioned-this-before- man...](http://kotaku.com/i-think-gabe-has-mentioned-this-before-many-times- hed-1577259744)

"I think Gabe has mentioned this before many times, he'd like to get rid of Greenlight to leave developers open to place their game on steam.

Then, users would curate the titles through their own customized storefront. This would drive word of mouth and generate free adverting for the companies that really on the steam digital store.

So think of it as following your favorite youtube channel/ store front because it has niche titles that are in line with what you like. You wouldn't have to dig for titles if that's not your thing.

This way, the devs of said niche title appears directly to its audience and yet still leaves the choice to the end user if they want to dig into the onslaught of new releases.

I really hope Gabe follows through on this idea because it keeps options open and doesn't give you a force fed walled garden that Sony, EA or MS is so dead set on controlling and manipulating end-users/devs with."

</comment></comment></comment></comment></comment></comment><comment><USER6> Its interesting that it seems Apple has really shied away from doing the bare minimum to improve things on the app store (until recently with videos and bundles). Not having the store be significant revenue is a double edged sword. I think there are some really interesting hacks that would have been better for consumers AND developers. In another comment (years ago I think...) I mentioned how I wish the top charts _wouldn 't show me apps I already own_. There were years where Angry Birds, for me someone who already owned it, represented the top 10 being an effective top 9. It knows I've already bought it, there's nothing I can do with that being there - even Rovio is only indirectly helped by this since I can't go and buy it again, it just serves as some weird hypothetical billboard on my phone for "other people". If instead I got a custom top 10 that was the top 10 apps I _don 't own_ I would be very much incentivized to buy more apps. This is of course not even entering into the actually interesting domain of suggesting better purchases for me.

App Store revenue not being Apple's bread and butter is a double edged sword. My point here is not that the above idea would "save" the app business, but to notice that the app store today is effectively the same as it was _6 years ago_. Experimentation in that space doesn't seem to be in their DNA.

<comment><USER7> What would your list look like with apps you owned removed?

         8. FartApp
        10. Flashlight

or

         8. FartApp
         9. Flashlight

In the first, with 9. Angry Birds removed, it looks like the data hasn't loaded properly.

In the second, Flashlight has been promoted from number 10 to number 9, falsely inflating its ranking.

You could solve this by leaving a gap or indicator where 9. Angry Birds should have been but then the user's wondering "what isn't it showing me in that gap?".

So maybe you should just call the Top 10, "Your Personalized Top 10". But then it's not personalized really, all they've done is remove apps you already own. The user thinks, "Why are Apple showing me fart apps? Don't they think I have taste? Can't they see I only download Twitter clients and podcast apps?".

For the marginal benefit of not showing apps you already own, which are indicated as such, you are opening a whole can of UI worms.

<comment><USER8> > In the second, Flashlight has been promoted from number 10 to number 9, > falsely inflating its ranking.

This is a concern that goes away in a user-centered design process. The "ranking" does not matter to anyone but app developers or journalists keeping score. The only reason a user looks at those lists is to find new apps to download.

Consider Google SERPs, which are now highly customized. Who obsesses over whether an item is at #7 or #9? No one but the people who own those links. Everyone else just wants an answer to their question.

<comment><USER7> The App Store has search results pages too. Top Charts are not search results pages--they are rankings of apps.

Top Charts is a popularity-based browse mechanism. Search is an answer to "what can i play podcasts on?".

You could argue Top Charts should be removed from the store or demoted. But you need some kind of browse functionality because people are often not aware that a certain type of app exists to search for.

<comment><USER8> My point was not that the lists are the exact same thing as search results, my point is that users don't care about the tiny details of whether a particular app is #7 or #8.

If you conducted a survey of App Store users and asked them to give you the numerical rank of a given app ("was it 8 or 9?"), I would surprised if many could remember, and shocked if any cared.

Why do users view those lists? As you point out, to browse for new apps. The precise numerical ranking does not help them very much to do that; therefore a user-centered design process should not care very much about how precisely accurate the displayed rankings are.

Edit to add: Users have no way to independently verify rankings anyway, so the concept of a "false" shift from 9 to 8 has no meaning to them. They don't know what's false, only what's useful.

</comment></comment></comment></comment></comment><comment><USER9> Really interesting.

Anecdotally, I'm seeing people starting to abandon their iPads and go back to laptops (generally macbooks/ultrabooks) in meetings and the like. I think the keyboard is just too useful for most people. Smartphone usage is definitely not following a similar trend, though.

<comment><USER4> That is going to change with the new IOS 8 keyboards. Believe me as an Android user it makes a world of difference in regards to how fast you can type.

<comment><USER10> I wonder how useful the keyboard is with iOS software?

Windows can be fully operated with just a keyboard and ~90% of OS X is operable via keyboard, but I don't see that being the case with iOS or Android.

</comment></comment></comment><comment><USER11> I use my iPad at least an hour a day before falling asleep, and I am pretty happy with the apps.

The YouTube app seems to be under heavy development, and while they often break little things, they also fix and add stuff quickly. I really enjoy YouTube on the iPad and I spend a lot of time there.

Likewise, the Google Maps app is great on the iPad. Most of what I said for YouTube applies to Google Maps.

Twitter and Tweetdeck work great. They don't change much, but they don't need to.

Twitch seems to be under active development. It works fairly well, and I use it a fair amount.

Kindle and Amazon Instant Video don't change much, but they just work.

<comment><USER12> do you have an iphone? In my (sample size me, so 1) survey (=P), tablet usage plummeted after I got a nexus 5 and my phone screen wasn't so damn tiny

<comment><USER13> Yes. I don't think I've turned on my Nexus 7 since I got my Nexus 5. The phone is more comfortable to hold and the screen is plenty big for anything from Netflix/Twitch viewing to ebook reading.

I always felt the original iPad 2 was too big and heavy to use comfortably for very long, too. 5"-7" seems like the sweet spot.

</comment></comment></comment><comment><USER14> > Top lists reward apps that get people to download them, regardless of > quality or long-term use, so that's what most developers optimize for.

Actually, that's where the in-app purchases come in. As every free2play game developer will tell you, the key to good monetization is updating your app and engage the community. Produce new content, throw seasonal promotions and sales, fix bugs, keep the game alive.

That's exactly because you care about the overall LTV of the user, not the download event — and, as free2play developer, my task is not to lure the user to pay $1 to download it, but to convince the user to pay while he's already in it. There are developers that buy installs for $10 a piece from a certain sources, and they make a great profit out of it — just because once the user gets there, he'll pay more. Not because anyone will force him to; it's impossible to force the user to do anything, we don't a gun to his head — but because he wants to.

May be the app developers, too, will finally go to the same route?

</comment><comment><USER15> I simply hate the appstore - it's so full of useless bad quality apps - don't even get me started on games. i have only oppened it a couple of times in the past two years. They killed discovery for me, i'm not even interested in checking out new apps (still no trials?!).

<comment><USER16> A friend of mine runs a great magazine dedicated to uncovering the best games in the App Store. You might find it valuable: [https://itunes.apple.com/us/app/app-gamer-magazine- ultimate/...](https://itunes.apple.com/us/app/app-gamer-magazine- ultimate/id670097598?mt=8)

</comment></comment><comment><USER17> It's interesting that the trends Marco says are inevitable:

1\. Use platform conventions over custom widgets

2\. Favour responsive layouts over layouts tailored for each screen

have long been the norm on Android. And since Holo - (1) has been far from a handicap. Apps that stuck to Holo (and now 'Material design') conventions were usually the most attractive.

With regard to (2) - the way this has forced Apple's hand in hardware choices has been fascinating. Having to double resolution via retina rather than grow incrementally and the long delayed and slightly painful transition to a new aspect ratio for the iPhone 5.

</comment><comment><USER18> As a user I like the pay-once model, but for apps that provide continuous upgrades, a subscription model would make much more sense and I think Apple & co would do well to start actively supporting that model for apps. The ultimate guitar tablature iPad application does it via an in-app payment and I'm more than happy to pay the yearly fee. I could imagine doing the same for many other apps. The counterpoint here is that, as a user, I would then feel entitled to frequent and substantive updates which would increase the load on an indie even more.

</comment><comment> pi-err The article is not about the growing share of obsolete apps in the App Store (as I thought). It's about the coming of age of the iOS app market - ie: more contenders, more competition, lower exposure. And the lack of perceived value of ipad development (says the author).

I understand this as: people are leaving our craftsman market in city center to stop by the big retailers in suburbia and are happy with it. And the craftsmen can't make their shops attractive enough vs big retailers.

I find Marco is pessimistic here (ad hom: as often).

1/ even matured and commoditized, the App Store is the largest money transfer to software vendors _ever_ , with a favorable cut going to indies/small makers. Even if less affluent, the small city center is still getting tons of attention.

2/ still on the craftsman metaphor: city centers are actually thriving again _along_ big suburbia retail thanks to a very intimate, qualitative experience. There's an exploding market fed by a better information flow. So yes, x% buyers are currently buying from an App Store "top list" \- what about all other sources of traffic towards an app? Pretty sure you've lost if you bet on a top list from the start (just like buying a sign off an highway for an artisan). There are other leverages as well.

And 3/ from a consumer perspective, software is so different than devs imagine. In my mind, real people see 3 very different types of app: \- give me fun (news, games, many social apps) \- improve me and help me (smart home, smart features, assistants, productivity, work etc) \- talk to people (many social apps)

The "fun" and "talk" apps are totally commoditized. Freemium at best. Yes, that's were the attention is, so what?

The "improve" market is just starting. It's harder to crack because people want a perfect experience with it- it's intimate. That's why I see it as a perfect opportunity for indie app makers.

Actually that's why I hope to launch an app studio next year to make it easier for EU devs to build and integrate their apps.

Side note, hopefully Apple also removes soon enough the thousands of apps left unattended for >3y. I don't thing Apple needs to hold that much to the total app figures by now, can remove 50% of the old crust.

</comment><comment><USER19> Top lists are also free marketing, every time someone makes millions on the app store, it makes headlines.

Those stories reinforce the message: develop for the app store and be a millionaire, attracting both more developers and more customers to the platform.

Apple has little incentive to change.

</comment><comment><USER20> This blog post, and those referenced are mostly about (the lack of) marketing. You can't expect to hole up in your apartment for 12 months, build an app and then have it take off or even sustain you. Replace the word "app" with business and it all makes more sense.

Everyone wants to be a "founder" or "start-up ceo" but besides writing code, there's a whole ton of good old business stuff that contributes to a successful, profitable business.

It's not Apple's job to promote your app, they simply run the marketplace.

</comment><comment><USER21> I always thought this was an interesting topic. I think it really leaves the door open for developers. I remember thinking a few years ago that most of the app ideas I had were already implemented, but now when I look for those apps I see that a lot of them have grown stagnant and opened the door for new players in the same space.

On the OP though, I think it is unfair to bash apple so much. Most of the apps I find are from curated groups like "Best New Apps", "Hot Puzzle Games", etc.

<comment><USER22> Those apps are abandoned because its increasingly hard to reach any visibility (and thus success) in the App Store, even if you sell for a ridiculously low price. The risk on not even making back what you invested in time to create a really good and polished app is immense when looking at the stats. So yeah, there is room for new guys to find out its not a sustainable business these days, unless you have a superb app and get really lucky.

<comment><USER23> > _Those apps are abandoned because its increasingly hard to reach any > visibility (and thus success) in the App Store, even if you sell for a > ridiculously low price._

Not necessarily. Lots of very celebrated and nice selling apps are abandoned just as well. This, for example, was a top seller in its day, and was all but left to rot:

[http://blog.chasejarvis.com/blog/2009/09/the-best-camera- iph...](http://blog.chasejarvis.com/blog/2009/09/the-best-camera-iphone-app- book-community/)

I have lots more example of similar abandonment. Some developers went in for cashing out, and couldn't bother afterwards.

</comment></comment></comment><comment><USER24> It's funny, regarding the "indies can't be profitable anymore aspect of the article" I read a very similar article 10 years ago entitled, custom web development is dead... then five years ago entitled 3rd part web design is dead, now it's app development. My guess in a couple years we will be reading iOS extension development is dead...

That's just the world we live in. Init? There is no standing still in the IT industry.

</comment><comment><USER25> This is interesting and it begs the question: is now (finally) the time where HTML5 app development makes sense - at least for some applications?

The technology is pretty good, and the single code base for iPhone, iPad, Android and Web makes it as tempting as it ever has.

More importantly, now it lets you diversify your sources of revenue. That wasn't important when it was easy to make money in the AppStore, but - maybe - now it is?

<comment><USER23> For some applications, maybe. Mostly apps that are glorified web views.

For anything that needs to tap to the full power of the CPU / sensors, etc, that's a non starter.

> _The technology is pretty good, and the single code base for iPhone, iPad, > Android and Web makes it as tempting as it ever has._

Unless if we're talking about an established service, like Facebook etc, it's not like anybody made much (or any) money on the web version of their apps. If you're a startup you might even hurt yourself from offering a subpar (non native) Android and iOS experience.

</comment></comment><comment><USER26> I really wish there would be a section in all app stores which shows a randomized list of "good" apps. I am not sure about exact criteria, but thede should be a good way to discover good and often downloaded apps which are not in the top 10.

<comment><USER20> What you're describing are "featured" apps, plucked out of the pile from Apple editors. I do wish there was more of this editorial work, and less reliance on "top lists" for app discovery.

</comment></comment><comment><USER27> There is a lot of trash on paper(magazines, USWeekly, Celebrities,...), on tv (Jerry Springer, TMZ, etc...) online (websites, web apps), on desktop (software), why did we think mobile was going to be different?

</comment><comment><USER23> TL;DR;

1) In a store with close to 1 million apps, a lot of them aren't actively developed anymore or updated to the latest iOS. (DUH!)

2) Hard work and effort are not automagically rewarded with large sales. (DUH!)

3) Not all hundrends of thousands or millions of app programmers competing with each other can live by their app income alone. In fact, few can. (DUH!)

<comment><USER28> > 3) Not all hundrends of thousands or millions of app programmers competing > with each other can live by their app income alone. In fact, few can. (DUH!)

This doesn't deserve your "DUH!". It reflects the fact that making these apps is easy. If it were so difficult or time-consuming that hobbyists starved trying to get an app done, everyone in the app store _would_ be living on their app income.

<comment><USER29> And yet not a single person proficient in Brainfuck lives off that knowledge.

<comment><USER28> You're missing the point. Doing something hard doesn't automatically bring you income. But if making apps required so much that you couldn't support yourself on the side, everyone who wasn't supporting themselves in the app store would leave.

<comment><USER29> I was only half-making a joke, but I agree with with you, in a way.

The model you are proposing is the J2ME that Nokia had, and the result was an utter flop.

</comment></comment></comment></comment></comment><comment><USER30> With all the app charts bashing going on, one might think that it's regarded as a developer's right to have their famous 15 days with every product. Did anyone expect or aspire anything else than a development towards a Billboard Top 100 or NYT Best Sellers mentality in a matured market that's a 24/7 popularity contest? The app phenomenon has probably created more one-man army millionaires in a very short time than any other industry, so stop complaining and get creative.

Bonus:

[https://medium.com/message/you-are-not- late-b3d76f963142](https://medium.com/message/you-are-not-late-b3d76f963142)

<comment><USER29> I'm already feeling better that someone I never met stroke gold. I'll kick myself, don't bother.</comment></comment>


The enemy of progress is complexity - <AUTHOR> http://scripting.com/stories/2010/10/17/howToDoAStandardPart3.html#disqus_thread <comment><USER2> Why not link to the actual item?

[http://scripting.com/stories/2010/10/17/howToDoAStandardPart...](http://scripting.com/stories/2010/10/17/howToDoAStandardPart3.html)

Why did you link to the comments?</comment>


iPhone Graphing Calculator App - <AUTHOR> http://www.iphone-calc.com/wp/

<comment><AUTHOR> Apologies for the self-comment...

I was going through some old boxes and found my TI-83 calculator and realized that if someone created an iPhone app version with a nice programming language, it could be a serious contender to TI's business. After a quick search, I found this and it looks like a beautiful start.</comment>


Two common mistakes when using databases - <AUTHOR> http://caml.inria.fr/pub/ml-archives/caml-list/2008/02/b75fe4f240d3a3985e50f9bd23013579.en.html?submitted_two_years_ago

<comment><USER2> A well thought-out post and a good read, but both of the author's points about the limitations of relational databases are a little misleading.

The first, "Every single element in a relation (aka table) has to be exactly the same type" is true in many relational databases, but isn't necessary: SQLite, for example, is implemented with a nice form of dynamic typing where individual columns can take on multiple data types.

Second, "SQL isn't even Turing-complete" is sort of a folk theorem in computer science that isn't necessarily true anymore, especially with all of the proprietary SQL dialects in existence: the original standard, SQL92, is basically equivalent to relational algebra, which has the expressive power of first-order logic - it's so weak it can't even express concepts like graph reachability. But constructs like recursive queries have been added to the SQL standard since SQL92 which may make even standard SQL Turing Complete.

<comment><USER3> PL/SQL and T-SQL are certainly Turing complete.

<comment><USER4> AFAIK PL/SQL is not "Oracle's SQL". It's executed by a different engine and you get context switches when you execute SQL Code (don't know about T-SQL).

But Oracle's SQL is by itself Turing complete since the introduction of the "Model" clause (see here: [http://www.adellera.it/investigations/nocoug_challenge/index...](http://www.adellera.it/investigations/nocoug_challenge/index.html) how you can compute the FFT using it).

Moreover, I read somewhere that the engines that implement the "recursive with" are also Turing Complete, but can't recall where.

</comment></comment></comment><comment><USER5> This seems like an aimless rant. Rails (and Hibernate to my knowledge) uses SQL for exactly what he recommends: filtering, aggregation, and joining. The RDBMS is a very real and concrete concept in ActiveRecord. If you don't know SQL, it's going to make it difficult to get beyond the most basic ActiveRecord functionality.

<comment><USER6> ActiveRecord and Hibernate can certainly do everything SQL can do. But the modeling and data access patterns they encourage are inconsistent with the strengths of relational databases and the relational model.

The point of using a relational database system is to think in sets of tuples because doing that makes life simpler (for some types of tasks). You apply one of a handful of set operations to a set and you get back another set of tuples.

Once you start assigning types and custom operations to particular combinations of attributes, you lose this recursive transformability and hence the simplicity of the model. What you get is a horribly complex monster.

The whole OO idea is a tangled mess. ActiveRecord and Hibernate do their best to help you view the database as a tangled mess as well.

<comment><USER7> Well.

I've written at length about this in the past, and basically my opinion comes down to there being two ways to approach this. One is driven by the application, the other is driven by the database.

The application-driven approach is, I believe, the vastly more common use case: you have some _things_ in your code (objects, data structures, whatever) and want some way to persist them and fetch them back later according to their properties, so you use a SQL-based DB because, hey, you can get them for zero monetary cost (PostgreSQL, MySQL, SQLite, etc.), every language has ways to speak SQL and every developer on your team knows SQL.

The database-driven approach is, in my experience, less common: you start with the database, design it meticulously, take full advantage of the relational model and the features it and your DB offer, build as much as possible in the DB layer and then let people write applications which talk to it.

Both you, and the author of the reply in the email this thread links to, seem to inhabit the latter use case. And that's fine; I know people who do that stuff and I respect it. Where the problem comes in is that you have a tendency to assume that _your_ use case and _your_ approach are or should be the _only_ use case and approach. Which is, frankly, wrong. There are plenty of situations where the application-driven approach does just fine and will take you a very, very long way (and when it breaks down, it probably will not break down because you need to switch to the database-driven approach; it'll break down because of other things), and where the database-driven approach really isn't a great fit (for various reasons).

<comment><USER6> I don't disagree with your application driven vs data driven distinction and I agree that it's impossible to say in general which one is better. My experience is that it is rare for an application to stand on its own for long. Data has a longer life span than application code, but anyway, both scenarios do exist and both are legitimate.

But making this distinction says little about what are good design principles in order to reduce the complexity of a system. My opinion is that data and relationships among data items should be represented uniformly on the application level as well as on a broader data management level.

Creating one API per combination of attributes leads to a combinatorial explosion, an increase in coupling and unnecessary mental load. It makes generic transformation of data and querying very difficult indeed. We need to work with few general purpose data structures that are easy to reason about.

And no, I'm not assuming that my approach should or even could be the only one. But I think the standard reply of "one size doesn't fit all" or "use the right tool for the job" has become all too fashionable. There are many tools for the same job, so I have to have an opinion and I have to choose. I'm not an authoritarian person at all, so I don't care the least if you make a different choice ;-)

<comment><USER7> Except you're falling right into that worldview.

You seem to be arguing for databases which exist and are structured independently of any applications which happen to access them. Personally, I think this makes about as much sense as arguing for, say electrons to have well-defined properties independently of anyone trying to measure them, which is the same as saying that there is no such thing.

You also seem to have trouble accepting that there may be lots of situations where there is exactly one application, and if that application goes away, then so does the company (or the department, or the project). In those cases, I don't see much value in trying to make the database be independent of the application; the database exists to serve that application, and if they happen to be tightly coupled to each other, so be it: sometimes that's how you get something to work.

</comment></comment></comment></comment></comment><comment><USER8> I liked the OPs reply to this message:

>Thanks for your reply. It was quite interesting, though I get the feeling you used my question solely as a trigger to share with us a long-held dissatisfaction with the current state of affairs concerning the use of databases, regardless of whether it actually applies to my particular problem.

</comment><comment><USER9> For beginners, this is definitely good advice. Particularly the first point - if you're using a relational database, and don't structure your data around its strengths, you'll take a profound performance hit. And sure, don't pass around data structures if you don't know what you're doing, and MySQL is a pretty crummy place to put them.

However, once you're doing real work, sometimes translating to XML and back is extraordinarily expensive.

The best approach is a hybrid. Use the database to store things relationally if possible, and using defined APIs for sure. And if your translation stage is expensive, use something like memcached to make sure you do that translation as infrequently as possible. _This_ is the layer that it's appropriate to store serialized data structures at. It's not permanent storage, you can blow it away when you change the internal structures, and nobody external is relying on it. But you end up, in most programs, with even more speed benefits than if you'd stored it in the database like this to begin with - the initial build can be expensive, but then you're reading basically from memory. (Not all data is well suited to this approach, but if your data is read frequently and written to infrequently - there's few things you can do to increase performance more than this.)</comment>


US Expected to Withdraw from UN Human Rights Council - <AUTHOR> http://thehill.com/policy/international/392418-us-expected-to-withdraw-from-un-human-rights-council-report <comment><USER2> I don't understand United State's extreme support for Israel. No one ever explains it. You just get either accused of antisemitim or that it's because of AIPAC money. But there has to be more to it than that, there is strong bipartisan support for Israel. Why is it so much in our interest? I'd love to get the real realpolitk explanation.

<comment><USER3> Supporters of Israel, principally Israeli Americans and Evangelists, are extremely well organised. They donate. They go to meetings. They call their Congresspersons. And when they vote, they treat this as a single issue.

More broadly, Israel is an advanced democracy and technological jewel with which we have a close economic, military and political alliance. You stick with your friends through the bad times.

<comment><USER2> Some friends, other friends like Canada can apparently be beat up no problem.

<comment><USER4> Yeah, until the very moment Canada elects a right-populist/neo-fascist government. We all know what Trump and his administration are up to.

</comment></comment></comment></comment><comment><USER5> UNHRC happens to be the one entity whose bad reputation is somewhat justified, although I guess the US President just made it his point that talking is always better than not talking?

There are other UN institutions far more useful, and also far more liable to be harmed by a US boycott. UNHCR would be first on that lis. They are currently caring for millions of refugees, helping both them as well as the western countries that would be overrun by asylum-seekers without these efforts. They do so on a shoestring budget (something like $2 per person/day).

</comment><comment><USER6> So at a high level, what's the path to recovery for Western liberal democracy?

There seem to be many long-term structural problems that we aren't really dealing with. Climate change, unfair accumulation of wealth, the change in labour and employment requirements; decaying infrastructure, corruption, increasingly adversarial and fact-free politics, to name a few.

I would like the world to be a better place for everyone. I always thought that a balanced mix of well-regulated markets and targeted state involvement, backed by a transparent and accessible democracy, would be the way to achieve that. But it seems to have faltered, at least in the Anglosphere.

Is it just done for? Does the future look totally different? It seems like such an intractable problem that I have no idea where to start.

<comment><USER7> What's the connection you see between this article and this question?

Leaving the UNHRC (not to be confused with the UNHCR as someone noted below, they're not a bad choice AFAIK if you are looking for a charitable organizations helping refugees to give to) doesn't seem to be a sign of the decline of western liberal democracy.

The council has issued more condemnations of Israel than it has issued condemnations of every other country in the world combined. Leaving is about rejecting that set of priorities. Not to say that those priorities are wrong, but obviously the US leadership does not agree that Israel should be the subject of so much of the councils time.

</comment></comment><comment><USER8> Isn't the UN HRC run by a prince from Saudi Arabia and a number of other representatives from undemocratic and repressive states?</comment>


Demoting A Loyal Friend - Ben Horowitz - <AUTHOR> http://allthingsd.com/20120423/demoting-a-loyal-friend/

<comment><USER2> > Those are some powerful emotions, so get ready for an intense discussion. > Ironically, the key to an emotional discussion is to take the emotion out of > it. To do that, you must be very clear in your mind what you've decided and > what you want to do.

Just had to do this, and this part nails it on the head. There cannot be any air of doubts or opportunities for the individual to feel they can change your mind. They won't change your mind. And it's better for all that there is not this ambiguity left in the situation.</comment>


Jeff Atwood on PHP - <AUTHOR> https://twitter.com/#!/codinghorror/status/167388945506766848 <comment><USER2> Right, and if I left alone everything that sucked in tech, I might as well be living on a farm without electricity.</comment>


Here's the guy who unwittingly live-tweeted the raid on Bin Laden - <AUTHOR> http://eu.techcrunch.com/2011/05/02/heres-the-guy-who-unwittingly-live-tweeted-the-raid-on-bin-laden/ <comment><USER2> See also <http://news.ycombinator.com/item?id=2505309>

</comment><comment><USER3> The awesome power and incredible limitations of Twitter, all summed up in one series of tweets.</comment>


Route View - Traffic cameras along your route - <AUTHOR> http://routeview.honolulu.gov/

<comment><AUTHOR> code @ github <https://github.com/codeforamerica/route_view></comment>


Google's Project Soli radar is sensitive enough to count paper and Lego bricks - <AUTHOR> https://www.theverge.com/2019/1/4/18168083/google-project-soli-radar-hardware-applications-radarcat-solinteraction-university-of-st-andrews <comment><USER2> This is one of those projects for which most people don't see the huge potential.

Hopefully, some of this makes it into a watch or smartphone soon.

<comment> david-gpu Can you elaborate on its potential? To me it looks slightly more convenient than a touch screen, assuming its error rate is comparable.

<comment><USER2> VR, AR with a touchscreen? Aren't we looking for a different method of input?

The screen on a watch is quite small. More gestures.

You can add a third dimension rather than simply slide a touch screen.

My AirPods could also have more gestures.</comment></comment></comment>


Can a Java app look and work this good? - <AUTHOR> https://gumroad.com/l/IMaX

<comment><USER2> This is a Java app, well done. Could you let us know what web framework you used if any and on what it is deployed (Tomcat, ....)

<comment><AUTHOR> I use a custom application engine built from ground up to create beautiful Swing and Java2D powered apps, i also use a very fast DB engine called H2, that's pretty much it honestly, this is the accumulation of around a year's work creating the back-end and front-end all on my own</comment></comment>


How I hacked modern vending machines - <AUTHOR> https://hackernoon.com/how-i-hacked-modern-vending-machines-43f4ae8decec <comment><USER2> This reminds me of how in the '90s my university gave out smartcard student IDs that had a little cash account on them for vending machines and dorm laundry rooms.

They installed readers into the soda machines, and they put a central panel in each laundry room with a reader and a keypad for you to indicate which washing machine you wanted to activate.

We found out that the vending machine hardware would query the card before selling you an item, but wouldn't debit your account until dispensing it, in case the vend failed. If you timed it just right and removed your card after it was interrogated but before the item dropped, you'd get it for free.

The smartcard project was only a 2-year evaluation and the university decided to move away from it, so the smartcard company came and took away all their hardware.

When they did this, they took the panel down out of the laundry rooms, but did not fully clean up the wiring coming out of the back of each washing machine. One of my roomates got curious and discovered shorting the leads of that wiring to a battery would mimic the signal the smartcard panel would use to tell the machine it's been "given" a quarter. Do that 3x and you got a 75 cent wash for free.

<comment><USER3> Real-world race condition! In the same period I remember the copiers in my college library would debit their magstripe cards about 1-2 seconds after the 'copy' button was pressed. A frugal / amoral user could easily eject the card, reinsert, copy the next page, eject, reinsert...

</comment></comment><comment><USER4> Val Kilmer did the same thing to a coffee vending machine in the movie _Real Genius_.

Instead of using Android, he used a freezer and a small hacksaw to section off coin-sized slugs from a frozen rod.

Have to give the points to Kilmer's character because in addition to doing it first, his crime left almost no trail and didn't come with felony exposure (most juries would not believe ice slugs are counterfeiting)

Making a daily habit of getting free hacked coffee could result in felony convictions and imprisonment in many countries for violating electronic data laws. I know FBI agents happy to bring charges for matters this trivial. This is where they'd rather spend their time instead of pursuing big league criminals.

Still a great article to read.

<comment><USER5> >I know FBI agents happy to bring charges for matters this trivial.

Just curious, what does one need to do in order to network with FBI agents and have them divulge what they're willing to charge people with?

<comment><USER4> Be very unlucky. Then the networking happens against your will.

The divulging comes in the form of an indictment, or, if you decide your integrity is not for sale and you turn down a plea offer, multiple days of hearings, trial, and sentencing.

</comment></comment></comment><comment><USER6> I guess plenty of people are going to come in here to wave their e-peen and comment on how trivial and obvious this "hack" is, but that's kind of the point. Us developers could learn a lot from this - mainly how _not_ to design any kind of payment app.

<comment><USER7> "Never trust the client" is a lesson every developer learns at some point. Incredible how an entire company missed that, but I'd put this down to "bosses want this out by DATE? Alrighty..."

<comment><USER8> Vending machines could be in buildings that blocking cell reception. I bet one of the requirements were that app should work offline.

And there you have it. Most people don't understand security. The business can say they are MVP and "secure enough".

<comment><USER9> If they are actively blocking it the building is doing something illegal.

<comment><USER10> It could be passive though. For example, underground parking lots both have vending machines and block my cellular reception.

</comment></comment></comment></comment></comment><comment><USER11> We had one connected vending machine in the building. Its credit database was on a remote server, so such hacks would not work.

However, if you unplugged its ethernet connector and buy something, then somehow your would get your food/drinks and your transaction was stored into a buffer until the machine went online again.

That buffer being in volatile memory, unplugging the power cord of the machine was enough for it to forget you ever bought something.

</comment><comment><USER12> Fun stuff!

The article has an old vibe of hacking articles published in the '90s/'00s (in a good way).

> obviously, it was password protected

Not obvious at all. Last time I checked, WhatsApp or Telegram didn't password protect their database (that was a while ago admittedly). And obviously, it doesn't actually provide that much protection if the key is on the phone, as the article demonstrates.

</comment><comment><USER13> "One day I decided to interrupt seasoning myself in the bat-cave and direct to my hometown to get some sunlight..."

What?

<comment><USER14> I was laughing at that myself. Guessing this is something that sounds way better in the author's native language.

<comment><USER15> Yeah seasoning in italian never means "adding spice to some food" but only "keeping it in a cold/dry place and wait for it to be ready" (usually months, sometimes years).

<comment><USER16> Good to know, thanks! I guess the term in english would be "maturing"

<comment><USER17> Curing?

<comment><USER18> aging?

<comment><USER19> marinating.

</comment></comment></comment></comment></comment></comment></comment><comment><USER20> I don't understand why the vending machine would trust the client to tell it how much credit the user had without first verifying from an upstream centralized db. This is bad design in my eyes...

<comment><USER21> AFAIK this is how Felica works which is the system for many of the transit systems across the world as well as a payment system built into feature phone since 2005, Android since 5-6 years ago and iPhone since iPhone7 in Japan and 8 everywhere else.

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

I don't know for a fact that it works without a DB but I do know that they exist in places that don't seem to access to a DB and they work instantly (no long pause like credit cards).

<comment><USER22> It works without a DB as far as I know, and there are handful incidents where people knowingly blocked a connection to the payment system to charge the card with no money spent. Primary security measures against fraudulent transport cards had been blacklisting, which seems to work well enough as there are not much hacked cards.

</comment></comment></comment><comment><USER23> These are the types of things that keep me worrying about self driving cars and if an entire system can be hacked to do the opposite of avoiding obstacles by malicious forces.

</comment><comment><USER24> Would a simple backup/copy of the "charged" database have sufficed? e.g: backup the db with a 5$ charge, use the credits, restore the database...

<comment><USER25> Absolutely. I've seen these vending machines before, naive me assumed they had a server-side database. I was completely wrong..

<comment><USER26> Still, is it worth stealing a 1$ coffee to potentially be criminally charged with theft?

<comment><USER27> Is there any duty of care for the vending machine software vendor towards the owners of the vending machines? Are they not playing the role of a virtual clerk that allows shoplifters to walk out of the store unchallenged whenever they yell out "It's okay; I've already paid for this!"?

It's worth stealing a $1 coffee to expose the extreme negligence behind the virtual clerk software. The software is essentially turning the vending machine into an honor box, and presumably the owner of the machine actually wanted proof of payment before vending anything, or they wouldn't have bought the machine. They could have put up a mains-powered samovar with a coin box bolted to it and a sign reading "1 euro per coffee. Call (+39) 355 5555555 to report problems."

It's not even clear to me who is being stolen from. How does Argenta determine how much they are to pay the machine owner? How do they determine how much to pay the machine servicer? If Argenta pays for the coffee, and the owners and servicers are unharmed, potential theft of coffee becomes an incentive to repair their software. Otherwise, you'd just be screwing some vending machine operator whose only failing was to trust Argenta over a dumb(er) coin and note validator.

</comment></comment></comment></comment><comment><USER28> Much simpler hardware hacking: slightly bend the control panel and/or the door with a small lever (a coin might be sufficient). On some models, opening the door starts the "admin mode" where you can control each spire, do tests, change prices etc. The sensor for door opening can be fooled by the slight bend, hence allowing you to take whatever you want.

<comment><USER29> Sure, also lockpicking the door open would work, and if you had the possibility to bring the vending machine at home and disassemble/study it you would probably also find another three different ways, what gives?

Still, you would need to perform some "unusual" physical action on the physical machine and you might be noticed by people passing by or by a surveillance cam, this app hack is instead "clean".

And it makes you think about the reliability of any similar app based paying system, in this case is "their" money[1] that "you" can "steal" (by drinking and eating for free), but what if it was "your" money?

[1] so before or later the vending machine firm would notice

<comment><USER30> Yeah, I pictured the victim too. A friend of mine owned vending machines. He paid rent for each location, and any loss of product came from his own pocket. Similarly, I remember reading a letter to my local newspaper by a woman whose husband managed the newspaper vending machines. She pleaded for people to stop taking extra copies, because her husband had to pay for them. I always thought the newspaper ran those machines, but they're serviced by independent contractors here.

</comment></comment></comment><comment><USER31> This feels like a 2600 article, in a good way.

<comment><USER32> Yep, really solid and you could apply a lot of the steps (creating a debuggable APK) to other projects.

</comment></comment><comment><USER33> This is great. I love the step by step guide. I didn't know you could modify code and just resign the APK in order to flip the debug switch.

</comment><comment><USER34> So in the end he informed the company, and they fixed it? I wasn't clear on the ending with 'hogus bogus', maybe I missed something.

Pretty neat project to undertake. Kudos :D

<comment><USER35> I took the stock photo of coins to suggest that they disabled the App, leaving the only means to pay as the old fashioned method.

<comment><USER36> This is why I so love the millenials' habit of communicating via hieroglyphs when we have perfectly good words.

<comment><USER37> What do millenials have to do with it? You think baby boomers don't use emoji too?

Relax and have some fun. ;)

<comment><USER38> Speaking as a millennial, millennials as an age group have a lot to do with it. Have you actually communicated in writing with people of varying age groups? It's blatantly obvious to anyone with "millennial" / "Gen Y" (loosely: born after 1985) family or friends that emoji use is heavily driven by younger users.

Further reading: [http://time.com/4834112/millennials-gifs- emojis/](http://time.com/4834112/millennials-gifs-emojis/)

</comment></comment></comment></comment></comment><comment><USER39> Fantastic article. This is the stuff I like to see on HN.

</comment><comment><USER40> Most of these systems are inherently insecure. Tbh, I cannot think of a simple way to make this really secure that doesn't require a somewhat more sophisticated system, especially if you don't want the machine to stop working if network connectivity drops, or servers of the vendor are down. If you come up with a really robust system, you're probably gonna charge quite a bit more than the company offering this system, and I'm pretty sure most customers just don't care or take this seriously.

The other point is that often times these machines that support an app get set up in companies for their employees, where you can be reasonably sure that everyone will play by the rules. We have a coffee machine at work that uses RFID tokens to handle credit with no security or encryption, and it works, even though we're all IT folks. A university with a CS department and its respective students is a different story though. :-)

</comment><comment><USER41> As a reward for his finding, did the company gave him a .db file with 500 credits in coffee?! :)

</comment><comment><USER21> On the one hand it's interesting to see the machines get hacked. On the other hand I love living in a country where the machines generally don't get hacked or vandalized because it means we get to have the convenience of more machines.

<comment><USER42> My favorite vending machine moment in college occurred when the person stocking the soda vending machine forgot to lock it. We all enjoyed free soda and, most impressively IMHO, no one took advantage and tried to take all of the soda from themselves. People just treated it like a refrigerator and would grab a soda when they were so inclined.

<comment><USER43> I remember my mind being blown when I saw a newspaper dispensing machine in Canada for the first time...

That would absolutely not work in South America.

You can clearly see which tourists are from our part of the world in Europe where paying for transport is "optional"...

</comment></comment></comment><comment><USER44> Almost felt like security through obscurity. Because this modify the app hack was huge for cheating in some games on jail broken iPhone years back. I would increase my coins and keep playing. I was under the belief developers stopped it years ago by making purchases done server side. So to see that this app it is done locally on the device was a big surprise to me and I would have not guessed it possible(in the sense that it would be crazy to ever build a payment app that way as this abuse has been done with games for years)."

</comment><comment><USER41> Honestly, what did the company say when he reported the security issue?

</comment><comment><USER45> Curious how the disclosure was handled here. Was it responsible? I can easily see a black market of accounts popping up at this university. It takes a long time to develop hardware stuff, and a month is probably not reasonable to expect changes to be made.

</comment><comment><USER41> I don't want to be that guy, but....

He didn't hack the vending machine. He did hack the app. It was very cool and such, but not what I was expecting from the head line.

<comment><USER46> The vending machine trusts the app without any checks, therefore its security posture depends on how secure the app is.

</comment></comment><comment><USER47> Does this require a rooted device, or will any Android device work?

</comment><comment><USER48> Probably could have boosted the "walletFreeVend" value also.

</comment><comment><USER49> How I hacked a totally insecure android vending machine wallet app would be more to the point, but nice anyway.

<comment><USER50> Do you guys also feel like many people started to become too high level, not getting satisfied with simple app hacks? Hello future.

<comment><USER49> Sorry didn't mean it negative. But "hacking a vending machine" sounded much more like touching the real hardware. Teaches an important story about app security, in any case.

<comment><USER50> I really mean baseline is just getting higher among devs, that wasn't case before the smart phones were that popular (ive read your comment as 'challenge' is there, not negative)</comment></comment></comment></comment>


Techie to tech lead: My five biggest mistakes - <AUTHOR> https://www.thoughtworks.com/insights/blog/techie-tech-lead-my-5-biggest-mistakes <comment><USER2> Very insightful. I am a new to the industry. So, this advice could be really helpful to me down the lane. Actually, could you also give some pointers on how to manage upwards and be effective at it.</comment>


A Visual Guide to What's New in Swagger 3.0 - <AUTHOR> https://blog.readme.io/an-example-filled-guide-to-swagger-3-2/ <comment><AUTHOR> (Note: I'm the author, but have nothing to do with the Open API Initiative)

Swagger 2 (current version) got really popular the past few months as a way to document your API. Now, Swagger 3 (er, Open API Spec 3 as it's now known) is about to launch. I had a hard time finding what was new, so we made an example-filled guide that will help with your migrations.

tl;dr: Swagger 3 isn't ready for use yet, and is way more complex but solves a lot of problems with 2.

<comment><USER2> The idea of a standardized API documentation format is great. However, the community that surrounds it can't mature with this amount of churn in the standard. Who is going to write a language-specific client generator if the work is obsolete a few weeks later? It would be interesting to know what was so wrong with Swagger2 that we need a new standard.

<comment><AUTHOR> I'm personally not a huge fan of Swagger, however I don't think you have to worry. Since 2012, there's only been two new versions. It's not exactly a fast-moving spec that will be out of date in a few weeks.

I do believe that Swagger 3 (and the rename) will splinter the community, however I think fixing some of the fundamental issues with Swagger (many of which are enumerated in the blog post) is very important.

<comment><USER3> It's worth adding that Swagger 2.0 documents will be losslessly convertible to OAS 3.0.

</comment></comment></comment></comment><comment> frant-hartm I guess every generation of developers has to do its own mistakes..

[http://www.omg.org/spec/CORBA/](http://www.omg.org/spec/CORBA/) [https://www.w3.org/TR/2007/REC- soap12-part0-20070427/](https://www.w3.org/TR/2007/REC-soap12-part0-20070427/)

<comment><USER4> The one distinction that I think is worth making is that OpenAPI describes HTTP APIs using the semantics of HTTP. Corba and SOAP attempted to be protocol independent. That's much harder to do well. Another good aspect of OpenAPI is that most people who are using it, are starting towards using the definition as the primary design artifact and then letting tooling work on that. Almost no-one designed WSDL or IDL by hand. Focusing on an OpenAPI as a design contract helps developers produce solutions that are more independent of tooling. And that's a good thing.

<comment><USER5> There's nothing wrong with just "tunneling" SOAP or anything else over HTTP POST. Tons of APIs do this and work just fine.

Now maybe it's easier on clients when you can just curl -XDELETE something but I'm not sure it's that big of a difference in the end. Especially if you have auto-gen'd client code.

<comment><USER4> It makes it hard to take advantage of HTTP caches. There is also some redundancy because SOAP has headers and HTTP has headers. Which to use? It also is handy to be able to make idempotent requests, especially over flakey networks.

<comment><USER5> HTTP caching is a good benefit. But you can get it just by using GET and shoving the body in the querystring.

Headers: Use the SOAP ones, you're just tunneling SOAP messages.

Idempotentcy requires the app to implement it that way. HTTP doesn't really help there.

</comment></comment></comment></comment></comment><comment><USER6> > Lastly, you're no longer allowed to define a response for GET and DELETE > (which matches how RESTful APIs work).

I get that part about the DELETE, but no response for GET sounds odd. As I couldn't find anything in the spec RC: Is there further information available regarding that?

<comment><USER7> Total guess, but they may mean request bodies instead of response since GET and DELETE normally don't have request bodies.

However, I'm not sure there is a definitive answer on if that's true from an HTTP perspective. I also couldn't find it in a skimming of the OpenAPI 3.0 spec.

In the end, REST [1] itself does not prescribe either condition and the HTTP 1.1 [2] spec doesn't either.

> A payload within a GET request message has no defined semantics; sending a > payload body on a GET request might cause some existing implementations to > reject the request.

[1] [https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arc...](https://www.ics.uci.edu/~fielding/pubs/dissertation/rest_arch_style.htm) [2] [https://tools.ietf.org/html/rfc7231#section-4.3.1](https://tools.ietf.org/html/rfc7231#section-4.3.1)

<comment><USER8> I tend to agree with the interpretation given here: [http://stackoverflow.com/questions/978061/http-get-with- requ...](http://stackoverflow.com/questions/978061/http-get-with-request-body) \-- that if a GET request contains a body, the server should ignore it in order to stay compliant with the spec.

</comment></comment></comment><comment><USER9> "Over the past few years, Swagger 2 has become the de facto standard for defining your API." \- LOL. I stopped reading here.

<comment><USER10> What do you use for defining & documenting your APIs?

I ask because this is something the UK Government is looking at - [https://github.com/alphagov/tech-and-data- standards/issues/3...](https://github.com/alphagov/tech-and-data- standards/issues/31)

<comment><USER11> The best part about Swagger is there's a lot of good open-source tooling for it (though this depends on the language).

One alternative I find super interesting lately is defining APIs with grpc and then exposing them with the gateway proxy: [https://github.com/grpc- ecosystem/grpc-gateway](https://github.com/grpc-ecosystem/grpc-gateway)

In this way, you get strongly-typed interfaces and Swagger is autogenned for you.

</comment></comment></comment><comment><USER12> Wtf is "git flavored markdown"?

Do you mean GitHub Flavoured Markdown? It concerns me that people writing software somehow mix up Git and GitHub as being the same thing.

<comment><AUTHOR> Whoops, fixed!

</comment></comment><comment><USER13> After writing a lot of long swagger specs I tried RAML which although not that widely supported feels much more pleasant to write. Any toughts?

<comment><USER11> Write swagger in yaml and it's just as pleasant.

<comment><USER14> How so? At least in my experience, Swagger doesn't have anything equivalent to traits so there's no way to DRY out your docs. If you have 50 endpoints with pagination, you have to document how that works 50 times. If you change how pagination queries are structured, then you have to change your docs in 50 places. With RAML, you would just change the trait and then all of your docs and your automated testing against them will be updated.

Swagger does have $ref, but it's a much weaker abstraction than RAML traits and resourceTypes.

[http://raml.org/developers/raml-200-tutorial#traits](http://raml.org/developers/raml-200-tutorial#traits)

<comment><USER15> [http://stoplight.io/](http://stoplight.io/) lets you use traits in Swagger. I've really enjoyed using a visual tool to build the API definition, though I don't find it helps with writing documentation.

</comment></comment></comment></comment><comment><USER16> Goddammit why are they still calling it swagger (Pardon my french), i thought they came to senses and decided to use "OpenAPI"

<comment><USER17> Just read the first paragraph: "...Since then, it's been moved to the Linux foundation and renamed to Open API"

</comment></comment><comment><USER18> Got all excited and awash with nostalgia when seeing the word "swagger" again. Clicked hoping it was about the old "swagger" Pascal snippet library that used to get passed on floppy disk in playgrounds in the 90s.

Googling finds this: [http://swag.delphidabbler.com/](http://swag.delphidabbler.com/)

</comment><comment><USER19> Swagger, OpenAPI, RAML, JSON Hyperschemas, toml/yaml/json ...

I don't see how proliferation of ad-hoc syntax contributes to interoperability, which surely should be the goal of an API spec?

My take is that JSON has "won" over XML as RPC or REST serialization format because browsers support it OOTB and there's no schema needed. It simply is the way of least resistance. And since a browser front end is traditionally tied to a web backend anyway, there's no need for a formal "API" (protocol spec, actually) spec as an external artifact most of the time.

Once you try and impose typing on JSON, this very benefit turns against you, and is getting absurd IMHO. Every JSON typing regime needs to work around the fact that JavaScript isn't statically typed. Consider JSON Schema: it is reminiscent of a markup schema of sorts, when a more rational approach would IMO be to represent JSON payloads as an RPC/IDL function signature-style schema.

</comment><comment><USER20> Is there any plan to expand the support for runtime polymorphism in 3.0?

<comment><USER4> OpenAPI V3 now supports AnyOf and OneOf constructs from JSON Schema.

</comment></comment><comment><USER21> I hope it's better than Swagger 2. I really need something like it, but trying to use Swagger -- after seeing that Kubernetes was using it -- has been a disappointing experience.

I'm particularly frustrated with the lack of good documentation generators. That's more important, in my opinion, than using it to generate clients and servers.

<comment><USER3> I assume you've tried Swagger-UI[1] already? We just put out a new version (complete rewrite), you can see it in action here[2].

If you're not a fan, please feel free to open a ticket to give us some feedback.

Disclosure: I was contracted to build Swagger-Editor 3.0.

[1] [https://github.com/swagger-api/swagger-ui](https://github.com/swagger- api/swagger-ui) [2] [http://petstore.swagger.io/](http://petstore.swagger.io/)

<comment><USER21> Yes, I'm familiar with it. And I'm sorry to say that I don't like it at all.

Some things I dislike:

* It's just a flat list of endpoints. You have to click on each to get a description, and it has this sluggish animation that opens up. I want to browse.

* Way too much wasted screen real estate. The _huge_ , wide table that shows when an endpoint is "open" is ridiculous.

* For any given type, have to switch between "Example Value" and "Model", which is awkward. There's a missed opportunity there, too: Consider the "PUT /user/{username}". Why is the "type" of the body not User? Why couldn't it be a link to the model? I.e. "PUT" takes a User and returns a User. Swagger-UI uses so much empty space to represent this very simple protocol.

* Whatever is being used to display the model is hard to use and read. You have to click on the little arrow to expand each level, and the font sizes are very inconsistent.

etc.

I do wish I had something vastly superior to give as an example, but I can find a lot of faults with every single API documentation site out there that I can think of. I do know some decent ones, though:

[https://stripe.com/docs/api/curl](https://stripe.com/docs/api/curl)

[https://www.twilio.com/docs/api/rest/sending- messages](https://www.twilio.com/docs/api/rest/sending-messages)

[https://plaid.com/docs/api/](https://plaid.com/docs/api/)

This is the level of quality you at _least_ have to reach before my interest is piqued.

I like that these include runnable client examples in multiple languages, and includes more than just dry reference documentation; there are descriptions of actual semantics. Moreover, the documentation is presented in an organized way, by topic, and let's the user consume the information linearly without lots of clicks.

As a simpler example, years ago a colleague of mine made a simple autogenerated documentation browser with built-in request running (screenshot [2]), which turned out pretty good. It's simple, but still miles ahead of Swagger-UI in terms of usability. I sometimes wish I'd spent some effort working it into something reusable.

[1] [https://stripe.com/docs/api/curl](https://stripe.com/docs/api/curl)

[2] [http://i.imgur.com/x5g1s2R.png](http://i.imgur.com/x5g1s2R.png)

</comment></comment></comment><comment><USER22> Wow, I was expecting the price for a service like this to be around $20/month but $199/month (custom header/footer) for a service like this seems a bit of a stretch.

<comment><AUTHOR> $199 is just our most expensive plan! You should be able to do everything on the lower plans. And, we do much more than just host Swagger :)

</comment></comment><comment><USER23> The example showing how response bodies are specified (media types, content) unfortunately is attached to a GET operation - please use a POST to demonstrate request bodies.

</comment><comment><USER24> What's the advantage of OpenAPI over json hyperschema?

<comment><USER25> I'm also curious -- my guess would be the quality and availability of tooling depending on which snowball continues to grow.

I only have experience with hyperschema (from an API design perspective). Would love to hear a current perspective from someone who had experience with both.

</comment></comment><comment><USER26> Is there a version of swagger-editor for OpenApi? I can't find anything. Similar experience for OpenApi would be a minimal requirement.

<comment><USER3> The current Swagger-Editor supports Swagger 2.0 (aka OpenAPI Specification 2.0). OAS 3.0 will be supported some time after 3.0 is finalized.

Source: I maintain Swagger-Editor. Check it out, we just finished a rewrite last week!

<comment><USER11> Can swagger editor load and save with a file dialogue yet? I remember that being the most annoying missing detail when trying to use it.

</comment></comment></comment><comment><USER27> No one using API blueprint here? [https://apiblueprint.org](https://apiblueprint.org)

</comment><comment><USER28> How does Swagger work with Odata and the Graph

<comment><USER4> We have been having numerous conversations within Microsoft to figure out how to describe Graph API using OpenAPI. The new Links capability helps a lot. Also, the AnyOf support will help with describing URLs with Expand. There are still a bunch of issues to work out.</comment></comment>


Simple Language Implementation Techniques for the 21st Century - <AUTHOR> http://stefan-marr.de/papers/ieee-soft-marr-et-al-are-we-there-yet/

<comment><USER2> Sometimes I wonder if using rpython is a good meta language for this tracing JIT technique. I don't know if there would have been any benefit if the meta langage was specifically designed for the purpose of implementing dynamic interpreters with the meta jit magic.

Adding explicit static typing to the meta language (i.e. replace rpython) could at the very least remove the long type analysis, and translation times, while providing better error messages.

<comment><AUTHOR> RPython is certainly not perfect, and the PyPy/RPython community is also very much aware of RPython being something that developed over time. But, RPython was from the start 'designed' as a language for implementing dynamic languages. The problem is that it took multiple iterations to identify meta- tracing as a foundation that works. And those iterations left some cruft here and there.

Compared to the Java-based experiments I did, sometimes I miss the ability to be explicit about types, and have to use RPython's assertions instead, which is a clumsy way of telling RPython about types. But overall, RPython isn't the worst toolchain I have ever worked with. And, typically, if the error messages are really bad, the community is very helpful and eager to improve them.

</comment></comment><comment><USER3> My take from the data presented in the article is fully different: both of the "acceptably fast" techniques use JIT to make the executed code fast. And the author avoids to consider what the JIT does. JIT means that effectively, at the end, the JIT engine produced the _native code._ The same code your real compiler would produce. All the processing before that phase is just to allow the clumsy "too dynamic" languages to be able to balance between the "do at least something" and "do something fast enough" (the second happens after the "tracing" code detects something is repated often enough. And the code that is actually important has to be run as often as it can).

But if you write the code that is from the start less "dynamic," you can get the quality code without all the engines in between and all the overheads that are incurred.

The "asmjs" achieves the speed because it is a protocol which allows the JIT to simply compile the whole big chunk of program to the native code at once, without all the tracing etc. And to have such a code at the first place, you need some less dynamic language, like C, as the source.

On another side, the programmers don't like to have to be "too specific" but recently more languages that gain popularity demonstrate that the types can often be inferred in the compilation phase and that such a code can be convenient enough for a lot of developers but fast too.

So, no, I don't think that the future is in PyPy. It exists only because the Python language "specification" (and the reference implementation) is too clumsy to allow clearer type inference. In my opinion, the future is in the type inference and the real compilation, not the clumsy-big-overhead virtual machines. Obviously, the developments that actually move in the direction I like are obviously: asmjs, Swift and Rust. Disclaimer: I know I'm biased in preferring, whenever possible, the compiled code to the interpreted or the JIT-ed. YMMW.

<comment><AUTHOR> The one issue you seem to consider as not relevant at all is the effort it takes to implement a 'fast enough' language. With RPython as well as with Truffle+Graal, you can implement a language in less than 10k lines of code and get performance within reach of state of the art VMs.

Sure, if you prefer more static languages, you can probably move the point of optimization from runtime to compile time. However, I would like to see that you can achieve the same degree of performance by using LLVM for a small language also in the range of 5k-10k LOC. I am not aware of any similar experiments in that field. Rust, Go, or Julia seem to be all larger and more complex languages, so a direct comparison isn't really fair. Would be interested if there is something out there I have missed so far.

<comment><USER4> This paper was an interesting read! And thank you for the exceptionally well- selected references: I think I will enjoy reading several of those.

I'm not sure about the others, but as far as Julia goes, the main parts of the language implementation are: parser and lowering in about 5000 lines of Scheme; type inference is 3k lines of Julia; and codegen to LLVM is about 6000 SLOC of C++. (and then there are a few tens of thousands of LOC of runtime and library code in C and Julia). I suspect it would be possible to implement a nice, smallish, LLVM-backed DSL using the Ocaml bindings in well under 10k lines, but I am likewise unaware of such an experiment. On the other hand, implementing Julia in Truffle or RPython would be a neat project.

<comment><USER3> As far as I understand, Julia is the language that will certainly be a worthy replacement of Python once it gets enough library functionality (I admit actually didn't follow how much it gets, I'd appreciate if somebody writes the current state). It's really nice that it was designed from the start to be fast.

<comment><USER4> It really depends what libraries you need. You might be interested in: [http://pkg.julialang.org/pulse.html](http://pkg.julialang.org/pulse.html) (also a searchable package list).

</comment></comment></comment></comment></comment><comment><USER5> Inspiring even for novice like me.</comment>