Show HN: MongiaJS, a library for consuming MongoDB documents - <AUTHOR> https://github.com/triplec1988/mongia

<comment><USER2> This looks pretty similar to the native driver, and not as easy to use as mongoose. How would you compare this to the other node-mongo options out there?</comment>


Introduction to Lisp Macros in Clojure (via HTML Templating as analogy) - <AUTHOR> http://github.com/swannodette/macros-tutorial/

<comment><USER2> Automating the use of Edi Weitz's CL-WHO library in Common Lisp is my standard method of showing how to use macros.</comment>


Offline First – A Better HTML5 User Experience - <AUTHOR> http://www.joelambert.co.uk/article/offline-first-a-better-html5-user-experience/ <comment><USER2> The most useful pattern I know of for offline web apps is the command queue.

Basically, the rendered state of the client is the acknowledged server state plus the client-side command queue.

User actions don't make a server request and then update the UI. Instead they directly append to the local command queue, which updates the UI state, and right away the client begins communicating with the server to make the local change real.

While the client's command queue is nonempty, the UI shows a spinner or equivalent. If commands cannot be realized because of network failure, the UI remains functional but with a clear warning that changes are waiting to be synchronized.

(The API for connectivity status are useful for making sure that the command queue resumes syncing when the user's internet comes back.)

<comment><USER3> You still have to handle cases where the server state has been updated (possibly via another medium, event, ...) and when the user's internet comes back it's not a matter of pushing clients' commands anymore. Instead you have to merge changes (either backend or front end side) before fetching the new state. For example, I try to purchase an item on my desktop, but can't because I lost connectivity. So, I proceed to buy it on my mobile. When the net comes back, did I mean to buy this item two times or just one ? In this case, it's easy to find a workable solution (cancel the second order command), but you get the idea: It's not trivial.

CQRS and ES, are wonderful tools in such situations. Past that point, your web app is far away from the little CRUD mashup it was at the beginning.

<comment><USER4> JSON-Patch [1] can be helpful here. You can maintain a list of changes that need to be applied, such that they only touch the parts of the document that need to change (other changes to other parts can be interleaved). If necessary, you can include tests to assert that some value in the document is what you expect it should be, and the patch can be rejected if that test fails.

[1]: [http://jsonpatch.com/](http://jsonpatch.com/)

<comment><USER5> That's if what's to be changed is a document (which is a big if).

Things get ugly quickly for any more complicated scenario.

<comment><USER4> Yeah, that's true. JSON-patch won't help with all situations. It is still an under-utilized tool, IMO.

</comment></comment></comment></comment></comment><comment> c-smile Wearing my architect cap...

There are four types of applications in that respect:

1\. always disconnected (e.g. calculator)

2\. occasionally connected (e.g. email client)

3\. occasionally disconnected (e.g. messaging client)

4\. always connected (e.g. trading terminal)

First architectural task I am doing when have given an application idea is its classification using these models.

Each particular case requires its own storage/caching approach. "Offline first" is too broad.

<comment><USER6> I'm not sure I get what you mean by "always connected". Because speaking about how stuff _should_ be written, I would expect developer never goes farther in his assumptions than #3. That is, I would hope my trading terminal still works just fine after the whole office goes offline for 10 seconds (or more, doesn't really matter). Actually, I would care quite a bit more about my trading terminal handling such cases, than, say, messaging client.

<comment> c-smile At the age of electronic trading that 10 seconds off-time of your trading terminal makes it almost useless.

<comment><USER7> There are different types of trading. The last few I did involved phoning the bloke at iDealing so he can call the market makers and get back to me a few hours later.

</comment></comment></comment></comment><comment><USER8> Wow, cool to see this resurface again! I wrote this ~4 years ago and the web has come on along way in that time. New features such as service workers are definitely making offline a lot easier.

On the subject of progressive enhancement, I'm a huge advocate and believe it is in general the way todo content sites. As has been pointed out above though, some use cases do require a different approach. For context this was post was written after working on a number of HTML5 apps that were wrapped in Cordova/PhoneGap.

</comment><comment><USER9> Offline is not a mere feature you can bolt on to existing architectures because you are really building a distributed system. Architectures that work well for distributed systems and especially p2p architectures thrive in this environment. Elsewhere in these comments people are discussing command queues, but this idea presumes that servers are somewhat reliable and that all operations need to go through a centralized point of control and failure. Instead, you can take this idea further and implement a kappa architecture (sometimes also called "event sourcing") where you maintain a log locally on every client which is the source of truth, not a server. When a network connection is available, you can replicate the log to a server or directly to other clients. You can build indexes (materialized views) that sit on top of this log to answer queries more quickly than reading the entire log out every time. You can also blow away these indexes and rebuild them from the log whenever your requirements change (migrations).

Unfortunately the web is missing a few pieces that would make it a very good platform for fully p2p, distributed apps. Service workers are a good start, but they have a 24-hour upper cap on max-age of the service worker itself, so users can't trust on first use (TOFU) and then be more secure against kinds of active targeting. The suborigin specification and iframe sandboxes for distributing apps offline and p2p would be much more useful for offline sandboxes if they didn't require that a server send an http header. These will become much more important as the web bluetooth API matures, which can allow distributing user data and application updates in a totally offline environment.

Even without being fully offline, it's very odd that when an automatic update to android or windows comes down the pipe, people in remote areas download the exact same bytes from servers in America over and over again, all over a thin pipe. They could fetch that data from each other and save a lot of money on bandwidth and data caps.

</comment><comment><USER10> tldr: Someone wrote a bunch of paragraphs and LOC around JSON.parse(window.localStorage.getItem(key)).

If you're really interested in learning about creating a workable offline web app, Google has some great documentation. [https://developers.google.com/web/fundamentals/instant- and-o...](https://developers.google.com/web/fundamentals/instant-and- offline/offline-ux)

Last, the Safari team needs to seriously get to work on Service Workers. We will see web apps grow by leaps and bounds once the service worker spec is opened up to iPhone users.

<comment><USER11> > We will see web apps grow by leaps and bounds once the service worker spec > is opened up to iPhone users.

Sounds exactly like what Apple _doesn 't_ want; no 30% revenue cut, no walled garden of control, ...

</comment></comment><comment><USER12> These are basically the same rules for any distributed application, like something using microservices. An app is just the edge node of a distributed system.

In any distributed system, the biggest cost is moving data between nodes, and therefore the biggest failure case is when data is moving slowly or not at all. It's a case you should always be prepared for.

If you write your app in a way that assumes the network is bad, which you should always do, whether it's an app or two microservices, then you'll have a more robust system.

<comment><USER13> > These are basically the same rules for any distributed application

And we've been doing those for like 50 years now. So why is this still so hard? Because new developer were, for all intents and purposes, born yesterday.

</comment></comment><comment><USER14> I get where this movement is coming from but I just fundamentally disagree with it. Making offline first web apps may make sense for certain applications where you expect you users may need to use it offline, but it doesn't make sense for all apps and it can require a fundamentally different way of writing your application which is a waste of time and effort if it's not a likely use case for your users.

<comment><USER12> All mobile apps will be offline at some point. Cell coverage doesn't cover 100% of the planet yet.

The question is, how good of an experience will you be able to deliver when your client is inevitably in one of these places?

<comment><USER14> Of course but if you're writing a web app who's only purpose, for example, is to talk to support staff for your company then having an offline mode is not really useful. If you're offline you can't talk to the staff, so all the app needs to do is fail gracefully. Designing it "offline first" would be silly.

I actually believe that >50% of web apps probably fall into this category, where they really cannot function properly offline because the online-ness s core to their functionality. That's why they are web apps in the first place.

Now if you are designing a web app that is a web version of a more traditional native app like Google Docs or something, then sure offline first makes sense. But I don't think that's the majority of web apps.

<comment><USER2> Offline first basically means that if you send a message while your network is temporarily down, it's just queued and resent immediately once the link is up again, like your email outbox.

Since network links are always flaky, it just makes sense to do it this way. Since they are also always relatively slow, it makes sense to cache data locally in order to give a faster experience.

Not doing things offline-first in an app basically means that you are introducing synchronous requests everywhere: reading a support reply from yesterday is a synchronous request that fails "gracefully" if your 3G happens to be down, etc.

Telegram's web app is pretty nice. The app code is cached offline with a service worker and updated whenever possible, so it loads _instantly_. The most recent messages from your contacts are saved in the client as well. I appreciate all that stuff as a user, and the more stuff works offline the better, because it also means it's faster and more reliable.

For more info:

[http://alistapart.com/article/offline- first](http://alistapart.com/article/offline-first)

[https://developer.chrome.com/apps/offline_apps](https://developer.chrome.com/apps/offline_apps)

</comment></comment></comment></comment><comment><USER15> Anyone using PouchDB + CouchDB in production to solve this type of problem? It is my go-to solution but I'm unaware of problems at scale.

</comment><comment><USER16> Maybe add 2012 to title on HN. As that's from when this post is.

<comment><USER17> I think this is an exception, until we don't have a good offline experience this article will be current.

<comment><USER18> It is missing anything about ServiceWorkers.

</comment></comment></comment><comment><USER19> Isn't it simpler though to just use static HTML + optional Javascript (like we used to in the 2000's eg. progressive enhancement years)? I mean why use M-V- whatever for content-driven sites at all?

<comment><USER20> Maybe I'm mis-understanding but it sounds like your talking about something entirely different?

Some sites just wouldn't work well with HTML+optional JS. Google maps (IMHO) would not work well that way, so using an offline-oriented model would make better sense.

That being said, if your a news site, or a blog, yeah, a simple static page is probably a better solution.

<comment><USER19> Of course true webapps can benefit from an MV* approach (like enterprise-type LOB apps). But gmaps IMHO isn't a good example, as it isn't MV*; rather, it fetches prerendered bitmap or vector graphics from the server.

</comment></comment></comment><comment><USER21> I would throw in some guidance that says "don't trust anything the client side sends to you". Developers used to server side MVC could expose themselves to client-side manipulation that open up some security issues.

I remember some early ecom cart implementations where you could "name your own price" as an unintended feature.

</comment><comment><USER22> I sense a trend of trying to cram everything good about native apps onto the web. Do people who do this stop to think whether the web is actually the correct platform for their app?

<comment><USER23> If you need to build cross-platform apps - and that is mostly the case nowadays - the web is actually not such a bad solution. I mean, what is the alternative?

<comment><USER24> Gtk

Qt

The list is actually quite extensive:

[https://en.wikipedia.org/wiki/List_of_platform- independent_G...](https://en.wikipedia.org/wiki/List_of_platform- independent_GUI_libraries)

\--

For mobile, clean separations also helps. It is definitely possible - and less complex than you'd expect - to have core functionality in a shared library, wired up to platform-specific native GUI toolkits.

But your question illustrates the problem. The pervasive presence of toolkits that add layer upon layer to create "cross platform" are the new norm. People are literally losing awareness that other options exist - much to the detriment of end users.

We have built an entire industry around such tooling - and long ago stopped questioning what value it brings.

<comment><USER25> I'm mainly an app developer that transitioned (a long time ago) from native to web apps, tired of code duplication. I'm well aware of other options.

The web comes with its warts, but I've yet to see an app platform as ergonomic and comfortable for the developer as the web. For 99% of my use cases, anything else is overkill and too much of a hassle. It's not the web's fault that it's a better app platform than actual app platforms.

<comment><USER26> Apple's stuff is actually really nice. Sadly Apple specific, obviously :(

</comment></comment></comment></comment></comment><comment><USER27> It continues to baffle me how much on disk cache is used by web browsers, but won't be used to load a page I know is in the cache if I'm offline.

</comment><comment><USER28> I'm surprised no one has mentioned Meteor[0].

[0] [https://www.meteor.com/](https://www.meteor.com/)

<comment><USER29> Me too. We picked Meteor specifically because it's approach incorporates ideas that make doing offline a lot easier.

</comment></comment><comment><USER30> Doesn't Chome on iOS prevent this because it reloads whenever you re-open a page, even if you don't have an internet connection?

<comment><USER31> I think there is a flag under chrome://flags where you can turn off automatic page reloading if the system is disconnected from the internet.

That being said, doesn't appcache provide the offline page if the browser can't connect?

</comment></comment><comment><USER32> That's nice and all, but no one is going to have all the images/videos/audio available offline for their media sharing social network app.

Web servers exist so you don't have to have all that data locally.

</comment><comment><USER33> I wish more native apps were offline first.

Take the tripadvisor app; when you go to the website you are nagged to go to the app, if you click you end up in the google play store and it loses where you were.

And of course it only works online; utterly pointless.

</comment><comment><USER34> Funnily this site does not wor k well with my crappy mobile connection. It loads 3 paragraphs and strangely the 4th paragraph is cut in half. I waited a minute for it to load.

</comment><comment><USER35> I feel like commenting on the callbacks and variable-bound-contexts, and saying something about the glorious wonder of modern JavaScripts... better not, tho :)

</comment><comment><USER36> How do you write unit tests for something like this? Are there frameworks that make this kind of model easier to deal with?

</comment><comment><USER37> How about offering a HTML experience in the first place?

I'm really tired of "HTML" websites that are actually a heap of Javascript writing to a virtual DOM, with only a few references to scripts, most of it being for surveillance (e.g. ad trackers, surveillance for profit with the side effect of it being available to intelligence services via subpoenas, gag orders and secret courts).

</comment><comment><USER38> very interesting - I'd love to see a feature like "queue / share later" (maybe Buffer etc) to share when you get back online again.

<comment><USER39> You might find [https://developers.google.com/web/updates/2015/12/background...](https://developers.google.com/web/updates/2015/12/background- sync) interesting?

</comment></comment><comment><USER40> Offline First versus Resilient Web

</comment><comment><USER14> Dude, I get it. Stop being so condescending. Maybe you're trying to be helpful by including those links but it comes off as incredibly insulting and pedantic.

I was talking about a real-time communication application.

You can make the argument that the application should try to cope with a sporadic connection, but in the real world this is inefficient for both the user and the staff if the connection is going in and out and they are trying to hold a conversation it might be better to show the user a message that says hey your connection is down try later when you have a better connection or try an asynchronous support method like submitting a ticket.

Regardless that was just an example off the top of my head. My point still stands; web applications are web applications for a reason, and "offline first" doesn't make sense for most of them.

<comment><USER2> I disagree and I explained why. Telling me what the "real world" is like is the same condescension you complain about.

If a couple of links to articles is "incredibly insulting" to you then you shouldn't discuss stuff on the internet.

<comment><USER14> Your example indicates you don't get it. You mention responses "from yesterday". That's not going to fly in an application that's real time that requires staff to keep the conversation open. You're describing a ticket system, I'm describing a live chat system.

I said "in the real world" as opposed to abstract talking about an application; in the real world a staff member would be stuck waiting for the response from this user where you're trying to keep the conversation going despite their sporadic connection. I guess I could have said "in meatspace" or something.

Links to explanations of the topic being discussed is _of course_ incredibly insulting. Come on.

Anyway, whatever man. You are not pleasant to talk to so I'm done.

<comment><USER2> In the real world, network links go down all the time, even if just for three seconds.

As for etiquette... I politely explained how I see things different from you and provided a couple of links for reference. You immediately called me "condescending", "incredibly insulting", and "pedantic".

If you want a pleasant conversation, that's not the way to do it...

</comment></comment></comment></comment><comment><USER41> I see the author's vision, but I have to say that I still favor progressive enhancement over this. Using javascript only assumes a lot about the user even in this modern age of web development.

Also as a nitpick, I would say don't make your data objects SINGLETONS, make them SINGLE INSTANCE.

EDIT: someone deleted their comment but brought up a good point that you can have progressive enhancement with this. Yes, however the author made it clear he favors the JS or nothing approach. And there's even this snippet:

>An offline first approach would be to move the entire MVC stack into client side code (aka our app) and to turn our server side component into a data only JSON API.

<comment><USER10> Here's your user assumption: 99.8% of browsers have Javascript turned on. Creating a fallback version of your app that works without Javascript is basically like developing for IE 5 -- you are completely wasting your time.

Here's another one: mobile browsers make up a majority of web traffic now, and Chrome and Safari are pretty well split in terms of share. Sending HTML tags over the wire is a waste of your users time. The idea of "progressive enhancement" should be thought of more as, "what can we display quickly on our user's screen while we're downloading and parsing the Javascript to make the application work". Note that this doesn't mean loading screens, just an initial state which shows the user progress in building up the app from that initial http connection. Regardless of the negativity around AMP, Google has made us think about what exactly we need to do in order to provide a good experience quickly and a feature-rich experience within a couple of seconds.

<comment><USER41> Progressive Enhancement was laid out clearly actually so that basic content should be accessible to all web browsers and basic functionality should be accessible to all web browsers.

As for google, they also recommend using progressive enhancement and they even removed their ajax SE scheme posting about this wherein they even give a recommended trick for compatibility testing.

[https://webmasters.googleblog.com/2015/10/deprecating-our- aj...](https://webmasters.googleblog.com/2015/10/deprecating-our-ajax- crawling-scheme.html)

</comment></comment></comment><comment><USER42> I disagree rather strongly with the implicit advice here: that HTML5 "applications" ought to rely on client-side processing first and foremost. This usually translates to "shove more Javascript down the user's throat", which is the opposite of "a better HTML5 user experience" IMO. If I trust you enough to want to run arbitrary Turing-complete code of your making, I'd be more inclined to download a native implementation for my platform; otherwise, I generally have better things for my CPU to do than burn cycles on things that should be done on your own servers.

I do agree, however, that the HTML "app" ought to be treated equivalently to native implementations -- that is, it should communicate over the same API (or perhaps an internal equivalent) as native apps. I like to think of this as "middle-end" web development, with the HTML-generating server working to mediate the browser's expectations (HTML and CSS and _maybe_ some Javascript if it's really needed) with the actual business logic provided by the API.</comment>


Apple Poaching Auto Engineers to Build Battery Division - <AUTHOR> http://www.nytimes.com/reuters/2015/02/18/business/18reuters-apple-autos-lawsuit.html?ref=business&_r=0 <comment><USER2> What if the whole deal behind all of this media stuff is just that mainstream journalists have figured out that iOS requires software engineers, and hardware engineers, but they can't wrap their head around the idea that iOS also requires battery engineers?

I'm not saying Apple _isn 't_ making a car. I'm not saying it wouldn't be cool if they were. I'm just saying that if you're at all familiar with the history of how the media has _always_ interacted with Apple - if you read Daring Fireball, for instance - then something that mind-bogglingly stupid might actually seem completely typical, in context.

<comment><USER3> There is definitely a bias in the media to write the most interesting story, even if it is less plausible.

Having a car in the works is more interesting than needing better batteries for existing/announced product lines. Much better batteries would be a strong advantage for apple watch, for example.

</comment></comment><comment><USER4> An anecdote: I recently went to a conference where a senior member of Foster+Partners, the architecture firm close to Apple (the studio behind Apple's new HQ, many new stores), presented the design for an autonomous vehicle, which resembles more the "Apple minivan" concept that is being mentioned by the press, here is that part of the presentation: [https://www.youtube.com/watch?v=0rUH63c1n0c&t=14m32s](https://www.youtube.com/watch?v=0rUH63c1n0c&t=14m32s)

<comment><USER5> I think the minivan concept makes a lot of sense. The demographic that is likely to own a minivan is likely to have their own garage, which makes charging no hassle. A family with a minivan most likely has a second car they could use for long-distance driving, making range anxiety less of a problem. And they are likely to have the disposable income to invest in an electric car in the first place.

<comment><USER6> The size certainly makes sense, if driverless technology turns cars into mobile living rooms.

If you're not driving, the entire "sporty" side of the styling and image are out the window. Limos aren't "sporty" and no-one cares. They care that the limo is comfortable and luxurious.

</comment></comment></comment><comment><USER7> Apple is smart to be grabbing A123 engineers. While people seem to remember A123 for its auto pursuits, it also produced batteries for things like tools from Black & Decker.

The problem with cars was that no auto manufacturer wanted to make themselves dependent on a single source for batteries. If someone built a car around A123's batteries, that put them in a bad position. If A123 had difficulty producing the volume needed, there wasn't an alternative. Similarly, it would give A123 incredible pricing power at the end of the contract term.

For a company like Black & Decker, they could offer a premium tool line based on the batteries, but they would still be selling lower-cost tools with less battery life or more weight. With a vehicle, altering the range or weight is a much bigger deal.

If Apple can increase the power density of the batteries in iPhones or MacBooks, that's a big win for them. "Solving" transportation is a very attractive problem and everyone seems to want that. But better batteries have much easier applications. Apple may be working on a vehicle, but if Apple can increase its battery power density by even 30% that gives them a huge advantage in their core markets (phones, tablets, and laptops). That's a much more modest increase than A123. If Apple's battery efforts work well in their current devices, one can see how an electric car might eventually happen. But hiring people from A123 can directly help the markets where Apple makes so much money today. Maybe electric cars are in Apple's future, but even if they aren't, batteries definitely are.

</comment><comment><USER8> I'm pretty skeptical about the Apple Car rumor (Jean-Louis Gassee wrote a nice debunking piece [http://www.mondaynote.com/2015/02/15/the-fantastic-apple- car...](http://www.mondaynote.com/2015/02/15/the-fantastic-apple-car/)), but when the NY Times suggests that Apple specializes in mobility and electronics it seems to make the car seem more likely.

In "Being Digital" Negroponte made the insightful assertion that the wired / wireless world was flipping -- TVs were becoming wired while phones and computers were becoming wireless (TVs have kind of flipped again since then). The next shift is that we may ourselves become unshackled from our homes.

In _City_ , Clifford Simak has people living in flying houses and they simply park where-ever they want to live for a given period. Well, flying is impractical, but mobile seems to be coming.

</comment><comment><USER9> Battery technology is the #1 problem pervading tech right now. From robots to iPads, we need about 10x battery storage for the same weight as we have now.

Having said that, it's shame to see all of this work in cars. I get the feeling that Apple is just going for a huge "me too" play, hoping to make the car into the next iPad.

But if that's what it takes for us to finally see progress? Count me in.

<comment><USER10> Since the iphone all Apple seems capable of doing is playing the "me too" card. Their innovations have stalled and they've gone from being that awesome company that makes great dev/design laptops and really cool smart phones into Microsoft 2.0. Tim Cook == Steve Balmer??

<comment><USER11> That's pretty harsh and also ignores how Apple creates its products. It didn't just see that everyone was doing smart watches and decided to hop on the band wagon like Samsung or LG. They have been building and designing a product they thought would actually do well in the market. They do purposefully try to become the first to announce just because they can.

The iPad was considered a flop by every news outlet when it was announced. Mocked openly about how stupid it was and how no one would buy it.

They aren't producing as many "market breaking" products, but I am sure they are working on them. Apple needs to be careful to release products that do very well, as sales that would be excellent for most any other company are considered a failure for Apple.

That's not at all to say they haven't been leaving behind a lot of old products. I will be very happy if IOS 9 is focused on debugging the software and improving the overall experience. I just hope the next os x will be doing that as well.

<comment><USER12> They did hop on the phablet band wagon which i believe was mocked just like the iPad.

<comment><USER13> The best ever quarter Apple has had definitely was helped by hopping on the phablet band wagon, started by Samsung. I remember the universal mockery most reviewers had when it was introduced.

Also Samsung (Samsung Chemical) has been involved with battery business for a long time but they recently got rid of it.

</comment></comment></comment></comment></comment><comment><USER14> The key thing to remember is that Tesla's battery competence has its foundation in their work with Matsushita/Panasonic - who are supplying the tech for the battery farm in Arizona. The main reason is that manufacturing and QA of the battery is critical. It will be interesting to see if Apple will work with Panasonic in this space.

That said, Apple of course may be able to sell at higher margin and be able to endure higher manufacturing cost.

</comment><comment><USER15> So is it illegal for companies to approach people about different job opportunities? Or is it the tactics used by Apple that give A123 the right to sue them?

<comment><USER3> No, poaching is legal. Apple also got sued for no-poaching agreements with other tech companies.

I think poaching is good in many cases, since hiring someone away from their current company usually means a higher price for their services. This means that you're moving developers to where they're most productive for the market as a whole.

The problem is this:

> in violation of their employment agreements

It's very possible to break an employment contract by leaving to go work somewhere else. These might not hold up in court (depends on the state), or Apple might just pay whatever fine the court levies.

<comment><USER16> That explains why A123 are suing their former employees, as they individually had contractual agreements. It doesn't explain why A123 are suing Apple, since they apparently had no contractual relationship.

IANAL, but my guess would be that the case is based on Apple allegedly inducing one of the A123 engineers to recruit other engineers into Apple. I don't know if that is actionable, though.

According to [1] the action is in the Massachusetts District Court, Boston. Looks like the details are paywalled inside Pacer.

[1] [http://dockets.justia.com/docket/massachusetts/madce/1:2015c...](http://dockets.justia.com/docket/massachusetts/madce/1:2015cv10438/167626)

<comment><USER17> Your _often_ not allowed to induce people to break contracts. It stems from Lumeley v. Gye and has a lot of caviots. [http://en.wikipedia.org/wiki/Lumley_v_Gye](http://en.wikipedia.org/wiki/Lumley_v_Gye)

</comment></comment></comment></comment><comment><USER18> Rather than evidence of developing a car, one boring possibility: Apple is trying to develop large-scale battery systems to more directly harness its solar farms' ability to power its datacenters.

Or: large-scale battery systems in cars have innovations that might be scaled down for use in computers, phones, and watches.

<comment><USER19> I'd _much_ prefer the latter...

</comment></comment><comment> cha-cho "Around June 2014, Apple began aggressively poaching A123 engineers tasked with leading some of the company's most critical projects..."

June 2014 is right around the time of Tesla's "All Our Patents Belong To You" announcement: [http://www.teslamotors.com/blog/all-our-patent-are-belong- yo...](http://www.teslamotors.com/blog/all-our-patent-are-belong-you)

</comment><comment><USER20> > A search of LinkedIn profiles turns up more than 60 former Tesla employees > now employed by Apple.

I can't tell - is this a lot or hardly anything?

<comment><USER21> And, more importantly, how many of those Former Tesla Employees are actually Former Apple Employees who became Tesla Employees, and then decided they would rather go back to work for Apple?

<comment><USER22> Are you suggesting that they are sent intentionally to join and know the future plans?

<comment><USER23> It could simply be a case of disillusionment at Tesla. Also Apple employees are known to leave Apple, either to start a company or for a sabbatical but then go back to working at Apple once they're done.

</comment></comment></comment></comment><comment> o0-0o From the article: A123 Systems is a pioneering industrial lithium-ion battery maker, which was backed by a $249 million U.S. government grant. It filed for bankruptcy in 2012 and has been selling off assets.

So, they take taxpayer money, go bankrupt, and then attempt to block former employees from getting jobs?

<comment><USER24> That part stood out to me as well. A123 doesn't come out of this one looking very good at all.

</comment></comment><comment><USER25> Why is it when a sports team goes after another player, it us a trade. But when a company goes after an employee, it is poaching? Yeah I get that the sports guy is under contract. But the word "poaching" has a negative conotation and it makes them look like a big bad evil company. When in reality it is a win for the employee.

</comment><comment><USER26> It's considered poaching to hire engineers from a company that's been bankrupt for two years?

<comment><USER27> It was a Chapter 11 reorganization, not a Chapter 7 liquidation, and the major parts of the company were bought by two others.

</comment></comment><comment><USER28> This is pretty rich, coming from A123, since they stole their ideas from Professor Goodenough.

</comment><comment><USER29> No Apple Watch jokes? I'm disappointed in you people.

</comment><comment><USER30> 'Poaching' makes workers sound like slaves owned by a company.

People are not owned by companies, it's the other way around.

They are not illegally hired, so poaching is incorrectly used.

<comment><USER31> "Poaching" in this context does not imply illegality.</comment></comment>


How to Start Android App Development on Android - <AUTHOR> https://palash.tk/Android-AppDev-On-Android <comment><USER2> Just a suggestion to observe and correct small spelling, grammar, and formatting issues with this article.

It's amazing that you are keen to share this knowledge.

However, it is important to remember that how you present the knowledge definitely helps it to be relayed more clearly. :)

<comment><AUTHOR> I'll Keep Your Suggestions In Mind! Thank You Very Much!</comment></comment>


Show HN: Create time-limited links with self-closing tabs to distracting sites - <AUTHOR> https://bato.life/share.html <comment><AUTHOR> Hey HN, really excited to show you my recent project. It's simple - Create and share a link that opens in a new tab. You can setup a maximum time limit and the tab gets closed automatically. Perfect for sharing content on distracting sites</comment>


OSH Park now supports native KiCad uploads - <AUTHOR> https://blog.oshpark.com/2016/06/08/native-kicad-uploads/ <comment><USER2> Might have to revisit KiCad, for the nth time. Last few times I ran away screaming after a few minutes! That mouse-position-dependent-keypress mode just drives me completely crazy. It feels like Autocad from the early 90's.

On the other hand, the push/pull router that has been contributed to the board editor looks too interesting to ignore!</comment>


Web Developers Are Stupid - <AUTHOR> http://mcarthurgfx.com/blog/article/web-developers-are-stupid <comment><USER2> Quick summary: Web developers are not stupid.

<comment><USER3> Quick summary of Michael Braude's blog (the post that article is rebutting): web developers just write HTML/CSS all day, I know nothing about web development on a production scale. I have made the smug assumption that a web startup does about the same thing as Joe's Home Page hosted by Tripod.

I actually take great offense to the original blog post that is referenced. I work at the _other_ big company across the lake from MS (hint: it sells stuff online), and I dare say the work that I've done here is miles more advanced and demanding than anything I've ever done for a desktop app.

And it certainly includes a deep comprehension of compilers, concurrency (oh boy do I ever), inheritance, etc etc.

This guy is just entirely clueless about what it takes to build a production website. His notion of web development is about as accurate as me claiming desktop apps are just drag-dropping controls onto a form in VB.

</comment></comment><comment><USER4> "We despise all reverences and all objects of reverence which are outside the pale of our list of sacred things and yet, with strange inconsistency, we are shocked when other people despise and defile the things which are holy for us." -- Mark Twain

<comment><USER5> Somehow I read it as "we despise all references and all objects of reference..." and had to do a double-take. :-)

</comment></comment><comment><USER6> The guys who carved Petra out of a mountain are arguably better at masonry that the guys who build houses by piling bricks on top of each other, but who's better at making houses?

<comment><USER3> Not a good analogy ;) Petra has stood the test of time for centuries, how long do you think your average brick house will stay standing?

<comment><USER7> Exactly, he pointed out the question isn't about Masonry skill but rather application. Having said that I disagree with his sentiment (web development isn't just building average brick houses).

</comment></comment></comment><comment><USER8> Easy: Majority of the code being written day to day whether it's for the desktop, the web or some other device.

Hard: Running a successful business on the easy part.

I don't care what sort of software you are writing. I'm a business owner. I'm a web developer but my real business is dealing with people, not machines.

</comment><comment><USER9> How are we defining "web developer" here?

This is from our friends at Wikipedia: <http://en.wikipedia.org/wiki/Web_developer>

_A web developer is a software developer or software engineer who is specifically engaged in the development of World Wide Web applications, or distributed network applications that are run over the HTTP protocol from a web server to a web browser._

and

 _Modern web applications often contain three or more tiers, and depending on the size of the team a developer works on, he or she may specialize in one or more of these tiers - or may take a more interdisciplinary role. For example, in a two person team, one developer may focus on the technologies sent to the client such as HTML, JavaScript, CSS, and on the server-side frameworks (such as Perl, Python, Ruby, PHP, Java, .NET) used to deliver content and scripts to the client. Meanwhile the other developer might focus on the interaction between server-side frameworks, the web server, and a database system. Further, depending on the size of their organization, the aforementioned developers might work closely with a web designer, web producer, project manager, software architect, or database administrator - or they may be responsible for such tasks as web design, project management, and database administration themselves._

</comment><comment><USER10> There seems to be a bit of a trend for "$groupOfPeople are stupid" posts - presumably it's just an attempt to be inflammatory to get links and visibility.

People who post "$gOP are stupid" posts are stupid. Read about it on my blog ...

</comment><comment><USER11> I am stupid, but that just means you're too smart to do my job.

</comment><comment><USER12> If I could downvote this, I would.

</comment><comment><USER13> i agree with the point of the article (i.e., web developers are not stupid)

i'd say that the real issue is that there are lots of good web developers, and they are all are under wraps by big companies, doing the things that they like for a big salary. the bad ones need work, so they're very prolific with their presence and marketing.

the most visible web developers are stupid.

<comment><USER14> The _real_ issue is that the original author is having a sour grapes fit over the fact that most development is moving the web, and he's stuck in yesterday's paradigm dutifully churning out his MS desktop schlock while guys without a college education are getting hired to work on highly visible and popular websites and applications.

Of course there are a bunch of talentless hacks out there calling themselves web developers, but that's just a function of the size of the market and the cluelessness of hiring managers.

If the original author was _half_ as smart as he thinks he is, he would know better than to associate intelligence with one technical field or another.

<comment><USER15> _"guys without a college education are getting hired"_

While I agree wholeheartedly with the thrust of your comment, I have to say - I think the age of the college degree is in terminal decline, and nowhere is this more evident than on the cutting edge of IT.

I don't think we're quite there yet that we can declare the college degree to be irrelevant but we're close. In my company it's a "that's nice" thing. Like being a boy scout. Very good for character. Now, onto your demonstrating your ability, and showing you can fit in, which is all we actually care about.

If a school-leaver who wanted to be a programmer asked me today whether he should go to college, I would have difficulty answering him/her. I am leaning towards "don't bother". And FWIW, I went to college.

<comment><USER14> Absolutely true. I don't think a college degree has any correlation to programming skill at all. I completed an MIT-based CS curriculum with all graduate-level classes my senior year. Had I not also been working full time as a web developer, and dabbling in the web since 1993, my degree would have made me virtually unhirable as a web developer.

On the other hand, the CS theory gives a very solid theoretical base that makes me a better programmer in all aspects of what I do. None of this stuff is exclusively available in a CS degree, all this information is available for free online _if you know where to look_. Most decent practitioners will pick up a lot of this stuff intuitively without formal training, but not with the same breadth or formality.

The stuff I did in my CS degree, such as optimizing binary code, writing a (subset of) Java compiler from scratch, and writing radiosity and monte carlo 3d renderers is demonstrative of a certain practical ability to deal with complex subjects that I consider valuable to all types of programmers. Therefore I think a CS degree can continue to stay very relevant, as long as they stick with theoretical CS and don't turn programs into Java and C# farms.

That said, the skills to succeed in a theoretical CS program do not necessarily translate into the ability to get things done in a real world environment, and it would also be a mistake to use it as some sort of litmus test since a college environment is not for everyone.</comment></comment></comment></comment>


President Obama press conference on NSA reforms (live, starting around 3pm EST) - <AUTHOR> http://www.whitehouse.gov/live/president-obama-holds-press-conference-3

<comment><USER5> The four points are:

1\. Vague stuff about 215 ... details - <USER4>

2\. Vague stuff about FISC ... details - <USER4>

3\. Transparency - some real stuff here. Seems like NSA infor will be released. And a website.

4\. Vague stuff about audit from independent comitee ... details - <USER4>

Vague general purpose stuff.

Lets hope he delivers something concrete in the next few months.

Edit: Snowden is not a patriot according to Mr Obama.

Edit2: Putting full employment as priority and admitting inflation is not a danger right now. Some "very serious people" got a stroke right now.

<comment><USER6> Actually lets hope someone in Congress that actually wants real reform delivers something concrete first instead of the transparency theatre that Obama is likely to deliver to us.

</comment></comment><comment><USER7> The executive order that Obama mentioned in this speech is a bit misleading(from what I can tell). First, it doesn't protect those individuals from being charged with a crime, it only protects their job. Here are a few thoughts on this executive order[1] which are my own thoughts though I'm not a lawyer and my interpretation could be wrong.

Here is the opening paragraph for Section A:

"Any officer or employee of a Covered Agency who has authority to take, direct others to take, recommend, or approve any Personnel Action, shall not, with respect to such authority, take or fail to take, or threaten to take or fail to take, a Personnel Action with respect to any employee serving in an Intelligence Community Element as a reprisal for a Protected Disclosure. "

And here is what a "Personnel Action" is defined as:

"The term "Personnel Action• means an appointment, promotion, detail, transfer, reassignment, demotion, suspension, termination, reinstatement, restoration, reemployment, or performance evaluation; a decision concerning pay, benefits, or awards; a decision concerning education or training if the education or training may reasonably be expected to lead to an appointment, reassignment, promotion, or performance evaluation; a decision to order psychiatric testing or examination; and any other significant change in duties, responsibilities, or working conditions."

Which means, Snowden couldn't be fired, however, he could still be charged with crimes, nothing about that. But the next sentence can really invalidate all of that:

"The term "Personnel Action• does not include the termination of an employee pursuant to section 1609 of title 10, United States Code."

There are more caveats to "Personnel Action" but this first one is what caught my eye. Looking up 10 USC § 1609[2]:

"(a) Termination Authority.— Notwithstanding any other provision of law, the Secretary of Defense may terminate the employment of any employee in a defense intelligence position if the Secretary— (1) considers that action to be in the interests of the United States; and (2) determines that the procedures prescribed in other provisions of law that authorize the termination of the employment of such employee cannot be invoked in a manner consistent with the national security. "

The first section of § 1609 is what really gets me: this is basically a get out of jail free card for terminating the person who blows the whistle.

Even then, the disclosure process is absolutely ridiculous and designed to keep the public uninformed. Obama even said himself that if Snowden had gone the "proper" route, then "we would most likely be in the same place now" but he wouldn't have "put lives in danger". Except that the public wouldn't have known about this invasion of privacy and it would have most likely been shot down by higher ups instead of actually being fixed.

[1] [https://www.fas.org/irp/offdocs/ppd/ppd-19.pdf](https://www.fas.org/irp/offdocs/ppd/ppd-19.pdf)

[2] [http://www.law.cornell.edu/uscode/text/10/1609](http://www.law.cornell.edu/uscode/text/10/1609)

</comment><comment><USER8> Time to play 'privacy theater'?</comment>


Amazon ElastiCache Details - Managed Memcache - <AUTHOR> http://aws.amazon.com/elasticache/

<comment><USER2> As a startup guy and recovering sysadmin, I really admire the Amazon Web Services effort. It started out small and ugly, but they have marched ever onward, slowly improving things and adding new features. Five years of steady plodding can get you pretty far.

<comment><USER3> I guess we'll take that as a compliment. I thought that we were racing, not plodding, but I must live in an AWS-induced time dilation field.

<comment><USER2> It's entirely meant as a compliment. There's no way I want an infrastructure supplier to seem hurried. Internally it may have seemed as fast as possible, but externally it was never showed signs of being faster than possible, which is an amazing achievement. For our industry, almost miraculous.

And I think you folks were very smart to start small and improve incrementally. As an example of what I mean, take this Slashdot comment from the EC2 launch a few years back: [http://developers.slashdot.org/comments.pl?sid=329797&ci...](http://developers.slashdot.org/comments.pl?sid=329797&cid=21000749)

Those are all legitimate gripes, and one by one Amazon has knocked them all down. Had you tried solving all of the problems before launching, I imagine you never would have gotten anywhere. The steady pace and it's-ready-when- it's-ready releases are definitely inspiring to me.

</comment></comment></comment><comment><AUTHOR> $68.40/month seems a bit high to me

<comment><USER4> Yeah, you may as well just run an EC2 node with memcached on it...

<comment><USER5> Except running memcached on an EC2 instance is not equivalent to the ElastiCache offering. With ElastiCache you are paying for a redundant, managed service that can be scaled and monitored through a few clicks of a webpage or API.

Outsourcing these type of things is potentially justifiable to a developer whose wallet is full and many hats touch the ceiling.

<comment><USER6> In what way is ElastiCache redundant?

<comment><USER7> > In addition, Amazon ElastiCache automatically detects and replaces failed > Cache Nodes, providing a resilient system that mitigates the risk of > overloaded databases, which slow website and application load times.

</comment></comment></comment></comment></comment><comment><USER8> now I want my elastic mongo and cassandra and we are all set.

</comment><comment><USER9> That is pretty pricey. 1GB of RAM from crucial is $10. 1 GB of Memcache from AWS, (assuming 3 year amortization) $1900.

Obviously there is overhead, but if you have machines already and they are not maxed out on RAM then the $10/GB price is not far of the real cost.</comment>


Don't let TC39 use smoosh or smooshMap - <AUTHOR> https://github.com/staltz/prevent-smoosh <comment><USER2> > The purpose of this library is to prevent TC39 from adding > Array.prototype.smoosh and Array.prototype.smooshMap as replacement names > for Array.prototype.flatten and Array.prototype.flatMap. They usually don't > listen to popular votes, but they do listen to the Web and usages of > JavaScript in the wild. So here's your chance to vote with your code in > production. Put this library in your production large-scale website (it's > very tiny! won't hurt) and we'll have a compelling case for TC39 not to > break backwards compatibility.

Why do I not want TC39 to use smoosh or smooshMap?

<comment><USER3> It's a form of protest. If both flatMap and smooshMap are seen as equally "breaking the web", maybe TC39 will coose the less insane name for the method.

<comment><USER4> Except one is a real problem and the other is an invented problem created only to cause more problems

</comment></comment></comment><comment><USER5> Cool, go back and tell the library authors to stop putting bullshit on native objects, or get them to put namespace prefixes when they do. Don't blame TC39 for doing their jobs: not breaking existing content.

Blame the authors of the frameworks that force js into a terrible corner

</comment><comment><USER6> If you do this they will just use some other ridiculous name like 'squash'. Instead you need to check for the presence of any other TC39 feature and then if any are present, break if flatten isn't present.

</comment><comment><USER7> What is TC39? And what is smoosh?

<comment><USER8> Technical Committee 39 of ECMA [1] is the governing board for the living ECMAScript standards documents, which influence the direction of the language we more often call JavaScript.

There's a current TC39 proposal [2] (at Stage 3, which is the discovery stage to gauge feasibility in browsers) to add officially to the language standard `Array.prototype.flatten()` (to flatten an array like `[[1, 2], 3, [4, 5]]` to `[1, 2, 3, 4, 5]`) and `Array.prototype.flatMap` (to `flatten().map()` as a single operation).

Because browser vendors discovered some libraries in the wild (8+ year old versions of MooTools) install their own incompatible to the new spec version of `Array.prototype.flatten` that does something different from the array flattening above, there is a discussion (as PR) [3] to avoid breaking ancient websites by choosing a new name for the proposed `Array.prototype.flatten`, in the case of the PR `Array.prototype.smoosh`. (For consistency it then renames `Array.prototype.flatMap` to `Array.prototype.smooshMap`.)

Other names are being discussed as well in the PR, and the TC39 committee has not yet actually met on the subject at this time, so nothing is quite set in stone.

[1] [https://github.com/tc39](https://github.com/tc39) [2] [https://tc39.github.io/proposal-flatMap/](https://tc39.github.io/proposal- flatMap/) [3] [https://github.com/tc39/proposal- flatMap/pull/56](https://github.com/tc39/proposal-flatMap/pull/56)</comment></comment>


Rotten Tomatoes shuts down 'Batman' comments after death threats - <AUTHOR> http://www.latimes.com/news/nation/nationnow/la-na-nn-rotten-tomatoes-shuts-down-batman-comments-after-death-threats-20120718,0,2005167.story

<comment><USER2> An online comment section got out of control?

Color me surprised.

Next from the latimes: Youtube comments surprisingly raunchy, posters forced to turn off feedback as a result</comment>


LexisNexis Will Open-Source Its Hadoop Alternative for Handling Big Data - <AUTHOR> http://www.readwriteweb.com/enterprise/2011/06/lexisnexis-open-sources-its-hadoop-alternative.php <comment><USER2> Huh... interesting. Looking forward to more details. Here's some more info:

<http://hpccsystems.com/>

[http://gigaom.com/cloud/lexisnexis-open-sources-its- hadoop-k...](http://gigaom.com/cloud/lexisnexis-open-sources-its-hadoop- killer/)

[http://hpccsystems.com/about-us/press_center/lexisnexis- anno...](http://hpccsystems.com/about-us/press_center/lexisnexis-announces- hpcc-systems)

Edit: Was curious about the license this would be released under... did some poking around, and found that it'll be the AGPL.

[http://hpccsystems.com/products-and-services/Licensing/ce- li...](http://hpccsystems.com/products-and-services/Licensing/ce-license)

I have to admit, I'm not a fan of the AGPL, so I consider this a little disappointing. Kinda wish they had gone with the GPLv3 or ALv2, but still... any addition to the F/OSS world is nominally a Good Thing.</comment>


Declarative JavaScript With Functional Programming Tools - <AUTHOR> https://github.com/azer/declarative-js

<comment><USER2> You need to explain more - for example what do you mean by a "partial"? A quick search for "partial functions" gave me several links to mathematics articles. When I followed the links to the composition modules I got more of the same impenetrable context-less style.

What I did get from the article is something that works a lot like promises:

\- async functions return type of "eventual" data (in your case, a function you pass a callback to)

\- various other functions that can operate on that eventual data type to return more eventual data

What does this style offer that standard promises doesn't?

<comment><USER3> > _You need to explain more - for example what do you mean by a "partial"? A > quick search for "partial functions" gave me several links to mathematics > articles._

The magic phrase you were looking for is "partial application." (Partial functions are a different, even more esoteric thing.) Basically, partially applying a function means you create a new function that calls the original with some of the arguments already filled in. For example, you could write this:

      var getUserList = partiallyApply(jQuery.getJSON, 'http://example.com/user-list');

and getUserList would then be a function that takes a callback and calls

      jQuery.getJSON('http://example.com/user-list', yourCallback)

</comment></comment><comment><USER4> I think this kind of approach can reduce complexity in JS. Witch is for me by far the biggest problem. Will give it a try.

</comment><comment><USER5> Is this from you, combataircraft? Always curious about your style because you always post that EditGrid example :)

<comment><AUTHOR> Yeah that's me and <https://twitter.com/4zjs/status/319970549910614016> :)

</comment></comment><comment><USER6> What about going a little further and writing in a purely functional language like Elm?

</comment><comment><USER7> hi nice work. it's always nice to have functional programming paradigms in javascript.

is there any (technical or political) reason, why this is or will not be part of underscorejs?

<comment><AUTHOR> underscore isn't async as I know. the libraries I use:

\- comp: <http://github.com/azer/comp>

\- andthen: <http://github.com/azer/andthen>

\- join-params: <http://github.com/azer/join-params>

\- map: <http://github.com/azer/map.js>

\- new-partial: <http://github.com/azer/new-partial></comment></comment>


EaRing: A Meta-Literal Machine (high-level dynamic assembler) by Zed Shaw - <AUTHOR> http://www.scribd.com/vacuum?url=http://www.zedshaw.com/repository/rubyenrails2008/build/rubyenrails_2008.pdf

<comment><USER2> Obligatory non-Scribd link:

[http://www.zedshaw.com/repository/rubyenrails2008/build/ruby...](http://www.zedshaw.com/repository/rubyenrails2008/build/rubyenrails_2008.pdf)

</comment><comment><USER3> Is it just me, or is his pseudo-assembly language just a funny way to poke fun at MagLev (and all the rejoicing surrounding its announcement)?

</comment><comment><USER2> So, in essence, Zed has come up with a dynamic front-end for the GNU Lightning assembler?

<comment><USER4> Is this using Lightning? We've done SPARC and x86 in pure Ruby without libraries here (for other reasons). You might be surprised how easy this stuff is to do. I assumed he just emits instructions.

I don't know why he wastes time with an actual parseable assembly language. Ruby and Python are vastly better languages than Assembler. They have all the same textual features that Assembler has, plus a real programming language to do things like virtualized registers.

</comment></comment><comment><USER4> The gulf between what seems like a jit assembler grafted to Ruby/DL and a jit compiler for a language like Ruby seems vast. Cool project. Predicting it isn't going to change the world, any more than Zed's "makefile for printed books".

<comment><USER5> The grandiloquence of the slides was written with the tongue in the cheek. The project page is much more modest. <http://www.zedshaw.com/projects/earing/></comment></comment>


A recommender system in 30 lines of Clojure - <AUTHOR> https://findka.com/blog/rec-sys-in-30-lines/ <comment><USER2> Awesome! A pseudo code of the algorithm would make it easier for someone to understand it better I guess.</comment>


Gravy: Add some sweet sauce to your Gravatars - <AUTHOR> http://jondot.github.com/gravy/

<comment><USER2> Feature request: multiple sizes

<comment><AUTHOR> It's controllable, append s=<size>, which will directly bubble down to Gravatar's s=<size> parameter. Is that what you meant?

<comment><USER2> [http://gravy- demo.herokuapp.com/grainysubhatch/8134f2e2f24cf...](http://gravy- demo.herokuapp.com/grainysubhatch/8134f2e2f24cf73b42d1b751582ba408?s=100)

It seems to scale the gravatar correctly but not the overlay.

<comment><AUTHOR> Thats an intended behavior. You're having a static overlay and mask, and you're fine-tuning the size and position of the original gravatar.

Adding an overall resize should be easy. Do you mind adding an issue here <https://github.com/jondot/gravy> ? it'll keep you in the loop when I've implemented it.

Thanks!

<comment><USER2> <https://github.com/jondot/gravy/issues/1></comment></comment></comment></comment></comment>


15 Page Tutorial for R - <AUTHOR> http://www.studytrails.com/blog/15-page-tutorial-for-r/ <comment><USER2> This tutorial is _much_ more basic and has much less practical _statistical_ applications than the R tutorial posted last week ([https://news.ycombinator.com/item?id=12264360](https://news.ycombinator.com/item?id=12264360)), which _itself_ is out-of-date relative to the R for Data Science book ([http://r4ds.had.co.nz/](http://r4ds.had.co.nz/))

I really am curious why anything "R" and "Tutorial" gets massively upvoted to the Top 3 of HN like clockwork nowadays. I might have to restart my R tutorial screencasts since there appears to be a demand. :P

<comment><USER3> > I really am curious why anything "R" and "Tutorial" gets massively upvoted > to the Top 3 of HN like clockwork nowadays.

Same thing I was wondering. Is it simply that R is gaining popularity among a more mainstream audience, while it hasnt changed that much recently ?

<comment><USER4> Idiomatic R has changed enormously with the growth of Magrittr the ℅>℅ operator, dplyr and now broom. Code by expert users is unrecognisable from that of a few years ago.

<comment><USER5> R still looks pretty much the same to me when I look at the code on kaggle, stack exchange, etc. Can you share where you have seen this expert R use and/or what use cases?

<comment><USER2> Most modern R usage I've seen, even on Kaggle, has used margittr/dplyr since it's orders of magnitudes faster/easier than the base functions. (i.e. I almost quit R in favor for Python without those two)

A quick example of my own notebook which uses margittr/dplyr heavily to process Stack Overflow survey data: [https://github.com/minimaxir/stack- overflow-survey/blob/mast...](https://github.com/minimaxir/stack-overflow- survey/blob/master/stack_overflow_dev_survey.ipynb)

<comment><USER5> Thanks for the example code, it actually has me wondering whether using the pipes has any impact on performance. They are much easier to read than the nested function calls that would be used instead.

However, I mean I just searched for an R script on kaggle and the first I found is this: [https://www.kaggle.com/bpavlyshenko/grupo-bimbo-inventory- de...](https://www.kaggle.com/bpavlyshenko/grupo-bimbo-inventory-demand/bimbo- xgboost-r-script-lb-0-457/output)

From my experience that is a typical example (data.table is very common, but not so much dplyr and the pipes).

I looked through the recent/featured questions on stack overflow and cross validated and saw only "old school" R as well. For example: [http://stats.stackexchange.com/questions/228800/](http://stats.stackexchange.com/questions/228800/)

</comment></comment></comment></comment></comment></comment><comment><USER6> R is essentially a LISP dialect. There is even a library that shows the syntax tree in LISP syntax:

> library(codetools) > showTree(quote(1+2 _3+4_ _5)) (+ (+ 1 (_ 2 3)) (^ 4 5))

See also the R-to-LISP compiler: [http://dan.corlan.net/R_to_common_lisp_translator/](http://dan.corlan.net/R_to_common_lisp_translator/)

</comment><comment><USER7> Another great resource for learning R is Swirl. I can't recommend it enough.

[http://swirlstats.com/](http://swirlstats.com/)

</comment><comment><USER6>
      > a[1-3]
      [1] 1 3
      > a[[1-3]]
      Error in a[[1 - 3]] : attempt to select more than one element

The first line evaluates to a[-2]. I think what the author meant was a[1:3]. a[[-2]] gives an error, a[[2]] is valid R.

<comment><USER8> a[-2] is valid R syntax. A negative index means that element is omitted from the result, so a[-2] is a without the second element.

</comment></comment><comment><USER9> As an aspiring R-learner, I have a few quibbles in the first pages I've looked at:

re: the Assignment operator [http://www.studytrails.com/R/Core/AssignmentOperator.jsp](http://www.studytrails.com/R/Core/AssignmentOperator.jsp)

> _However, there is a difference between the two operators. = is only allowed > at the top level i.e. if the complete expression is written at the prompt. > so = is not allowed in control structures. Here 's an example:_

          > if (aa=0) {print ("test")}
          Error: unexpected '=' in "if (aa="
          > aa
          Error: object 'aa' not found
          > if (bb<-0) {print ("test")}
          > bb
          [1] 0

What in the LOLWTF...This is a bad example because even as an experienced programmer, I have _no idea_ what is _supposed_ to happen, or why this pattern would even be used -- and even then, I was surprised with the result. This is an overly complicated explanation even if it is correct. I prefer Hadley Wickham's style guide:

[http://adv-r.had.co.nz/Style.html](http://adv-r.had.co.nz/Style.html)

> _Use <-, not =, for assignment._

(an assignment operator that _isn 't_ an equals sign is one of the things I miss most when switching away from R)

From the next chapter, Listing Objects: [http://www.studytrails.com/R/Core/ListingObjects.jsp](http://www.studytrails.com/R/Core/ListingObjects.jsp)

> _All entities in R are called objects. They can be arrays, numbers, strings, > functions._

This may technically be the case, but any R tutorial that does not open up with what makes R different from other mainstream languages is doing the reader a major disservice. This Listing Objects chapters shows patterns that use R in ways that I haven't seen used in other R examples (beginner and advanced). Even if it's correct, what's the point in showing esoteric examples unless this tutorial is meant to teach R to someone interested in the design of languages?

Again, Wickham's Advanced R book handles this topic well (in fact, Advanced R is probably the best book you can read if you already know how to program -- it is incredibly accessible) in his early chapter on Data structures: [http://adv-r.had.co.nz/Data-structures.html](http://adv-r.had.co.nz/Data- structures.html)

> _R's base data structures can be organised by their dimensionality (1d, 2d, > or nd) and whether they're homogeneous (all contents must be of the same > type) or heterogeneous (the contents can be of different types). This gives > rise to the five data types most often used in data analysis...Almost all > other objects are built upon these foundations. In the OO field guide you'll > see how more complicated objects are built of these simple pieces._

And this next sentence is the one thing I wished someone had printed out and stapled to my forehead before I started to learn R:

> Note that R has no 0-dimensional, or scalar types. Individual numbers or > strings, which you might think would be scalars, are actually vectors of > length one.

Maybe that's self-evident to other programmers, but even as someone who once programmed in MATLAB, I was stunningly ignorant I was of how every return value I interacted with was a vector, even a single simple string. In retrospect, the interactive shell alludes to this...but I didn't even bother looking up the details about the shell:

             > 2 + 2
             [1] 4
             > 'a'
             [1] "a"

R is wonderfully easy to start up with and produce visualizations with. But skipping over the language's fundamentals was incredibly painful for me. A few minutes skimming "Advanced R" would have easily saved me hours of confusion.

<comment><USER10> wrt assignments: = does assignments too but not eagerly. It's used for late bindings. This isn't a matter of style as your reference to adv-r would suggest but a different use case.

I wish people would spend more time reading the official language reference instead of all these half-baked tutorials.

<comment><USER11> I can see myself and other HN readers enjoy the design of the R Website[0]. But I believe that is not universal.

The HTML documentation is intimidating. Not that these are bad things. Science is complicated, and it needs complicated tools.

These tutorials allow(half-baked or not) a casual insight into to complex subject matter.

[0]: [https://cran.r-project.org/manuals.html](https://cran.r-project.org/manuals.html)

</comment></comment></comment><comment><USER12> I prefer Python

<comment><USER13> Agree. While R's statistical stuff is much more polished, doing anything but running the regressions is a royal PITA.

<comment><USER14> You got it the other way around. Doing anything but model specification (i.e. regression) is royal PITA in python.

<comment><USER15> Regression in sci-kit learn is like 2 lines. It's hard to understand where your painpoint is?

<comment><USER14> That's my point. Specification of the model is not (usually a problem). The other tasks are the problem.</comment></comment></comment></comment></comment>


NectarJS: The first ever JavaScript compiler is launched on KickStarter - <AUTHOR> https://www.kickstarter.com/projects/adrien-thierry/nectarjs-compile-javascript-for-and-from-any-devic <comment><USER2> Looks cool does it really work with WASM or asm.js ?

<comment><AUTHOR> Yes, it can compile JS to wasm, asm.js, exe, elf, arduino firmware and more</comment></comment>


Sortie en mer – A trip out to sea - <AUTHOR> http://sortieenmer.com <comment><USER3> Very nicely done, technically. And the marketing message is both true and useful: Swimming at sea is surprisingly hard, and life jackets make a huge difference.

I was once a very strong swimmer, and back then, I tried swimming 60 feet to shore in water with choppy, 6-inch waves. I wound up repeatedly inhaling water and choking. To combat this, I tried to keep my head high above the water, which was exhausting. After 30 feet, it was clear I was in real trouble, so I called to the rowboat shadowing me 5 feet away and they towed me to shore.

Similarly, cold water will shut me down frighteningly fast—even with a wetsuit and lifejacket, I've been stunned into near immobility after less than a minute of swimming. And I'm somebody who grew up swimming in the Gulf of Maine, which can be frigid (because Cape Cod deflects the warmer Gulf Stream eastward). The actual risk here is cold shock, not hypothermia—rapid vasoconstriction in your limbs will flood your core with blood, causing your heart to work much harder to maintain circulation. It's incredibly draining.

A life-jacket will keep your head above water with minimal exertion. This means that (a) you keep breathing and (b) you remain visible to rescuers. It turns survival from an incredibly strenuous and terrifying athletic event into largely passive floating.

<comment><USER4> Life jacket is good, but in higher seas one of the main problems (assuming the crew remaining on board is actually competent) is visibility - <USER2> investing into something like a dan buoy [https://www.youtube.com/watch?v=BMGWk6s9G4k](https://www.youtube.com/watch?v=BMGWk6s9G4k)

<comment><USER5> Better visibility is helpful but even that doesn't do much in rough conditions or at night. Many of us scuba divers now carry Nautilus radios which include a GPS receiver and 2-way VHF marine radio with distress beacon. I bring mine whenever I go out on the ocean, even when I'm not diving. [http://www.nautiluslifeline.com/nautilus_lifeline](http://www.nautiluslifeline.com/nautilus_lifeline)

<comment><USER6> DSC (digital selective calling), which that radio uses to transmit distress signals with coordinates, is an excellent but sadly under-used technology. Everyone should be equipped with it and be familiar with all the menus and options on their transceivers, and regularly test that the equipment is working by making routine calls. The problem with DSC is that the transceivers are really badly designed and downright user-hostile. The receiver usually gets a loud horn going of in their ears which only trains a reflex to reach for the silence button. It's pretty much only used for tests, and before anyone dares initiate a DSC call they call the receiving ship in advance the old-fashioned way, or they will get yelled at. When the whole point of DSC is that you merely enter the recipient's MMSI number, open a channel and just speak, without cluttering up channel 16 which is should be left for distress traffic only. Think Uhura in Star Trek. This is a huge risk to safety of life at sea that the industry urgently needs to deal with. But yes, do carry the equipment and do use it in an emergency, because it does work and it frees up yours and your rescuers' workload to worry about more important things than trying to get your coordinates across by voice.

I would also suggest getting a SART and an EPIRB. A SART is a radar beacon, which shows up as a distinctive pattern on surrounding ships' radar displays, and requires no special receiving equipment. An EPIRB is a beacon that is locatable by satellite, so that's the fastest and most reliable way to get the attention of a rescue control centre. These three technologies are part of the GMDSS (Global Maritime Distress and Safety System), which means commercial ships and emergency services are by law required to carry and use equipment to receive their signals.

<comment><USER7> In Australia, to call the Rescue Coordination Centre on HF, you HAVE to use DSC: [http://www.amsa.gov.au/search-and-rescue/distress-and- safety...](http://www.amsa.gov.au/search-and-rescue/distress-and-safety- comms/amsa-hfdsc-network/)

> If a vessel wishes to conduct a radiotelephony communication with the > network, it is necessary to make initial contact via a DSC call. For safety > or routine messages a shift to a working frequency is normally required.

When I did my training, they pushed DSC very hard.

Nit: You mention ch16 as being for distress traffic only, but my radio handbook also lists it for carrying urgency and safety messages, and as a routine calling channel (and then you move to a working channel and get out of the way).

Also: What crazy part of the world plays clutters ch16 with music?

<comment><USER6> Yes, that is true, 16 is also for urgency and safety messages, but ideally channel 70 should supersede 16 as the routine calling channel. Of course, for that to happen the equipment has to be made actually user friendly. It would be trivial to implement the software to let the OOW simply click an AIS target on the ECDIS to have that target's MMSI entered into the transceiver and a call initiated. If ships were running on free software someone would have already done that, sent a pull request to the ECDIS software maintainer, have it pass perfectly repeatable and transparent integration test suites to make sure the patch won't make the ship go keel up, and Bob's your uncle. But for some reason people seem afraid of this proposition.

As for music, last time I heard that was in the Java sea, but Americans aren't much better, making securité calls when moving their Bayliners, or the USCG with their incessant babble about irrelevant things.

<comment><USER7> Not everyone's got AIS and ECDIS though. The places where I trained really pushed DSC for fishing and recreational use, by making it relevant to the little guys too: "If you'd just found a good fishing spot or a nice quiet place, why would you go blabbing to everyone about it on ch16? Call your mate up on DSC instead." They also made a point of telling people to spend that bit extra to get a radio that doesn't suck. Buying a cheap transceiver and having to input a MMSI using up/down/enter/back is really annoying and doesn't help take-up at all.

Speaking of AIS, did you see this thing from a couple of years back: [http://blog.trendmicro.com/trendlabs-security- intelligence/v...](http://blog.trendmicro.com/trendlabs-security- intelligence/vulnerabilities-discovered-in-global-vessel-tracking-systems/) ?

<comment><USER6> That's true. But it does help a lot that there's a merchant ship equipped with these things as well as a fast rescue boat if you're ever in distress. Furthermore, writing free software for the big ships will also help the little guys too, even if it means running the software on a laptop for extra situational awareness.

As for security, yes, this is a problem. It's the same in aviation with ADS-B, completely unauthenticated messages that the on-board software will happily digest,[1] whether it's to mislead the pilots or find some vulnerability in the avionics software to exploit. How can this be anything but gross negligence on the part of both the regulatory committees and the industry at large?

1\. [http://www.esecurityplanet.com/network-security/security- fla...](http://www.esecurityplanet.com/network-security/security-flaws-found- in-ads-b-air-traffic-control-system.html)

</comment></comment></comment></comment></comment></comment></comment></comment><comment><USER8> When I was a boy scout we were taught to take off our pants, tie knots in them and fill them with air either by blowing or by throwing them over and down on the water. You can create a makshift life jacket this way. Wet fabric can hold air. It isn't perfect, you have to keep refilling air as it leaks but it does work. I was in a swimming pool and not high seas so not sure how effective it would be in that situation. Definitely better than just treading water though.

<comment><USER9> I was doing laps in college one time when an ROTC class was practicing this. At the same time they were learning how to use their M16s(or something in the family) while swimming.

</comment></comment><comment><USER10> Develop as part of an interactive experience by the agency CLM BBDO for yachtwear manufacturer Guy Cotten and released on Apr 24, 2014. The goal is to remind people to buy and wear lifejackets.

<comment><AUTHOR> Definitely convinced me. I figured life jackets on boats are what seatbelts are to cars. It's a small thing you probably should put on.

</comment></comment><comment><USER11> This looks very interesting. However for those of us with a slow internet connection, the fact that I can't pause and let it load means my experience is cut every few seconds.

<comment><USER12> I had the same issue, someone put it up on youtube here [https://www.youtube.com/watch?v=wQNNgvvVgi8](https://www.youtube.com/watch?v=wQNNgvvVgi8)

</comment></comment><comment><USER13> Having a competent crew helps too.

I'm in the Royal Navy. We practice a man overboard every time we sail and we critique each one. We even restrict movement on the upper deck after dark. We're professional sailors who live at sea - if you take a yacht out with a friend and you haven't been to sea since last summer you need to practice your man overboard drills.

</comment><comment><USER14> That made me very, very uncomfortable. Probably one of the worst things I've ever felt while comfortably sitting in front of my computer, browsing the web.

Well done! :)

<comment><USER15> > That made me very, very uncomfortable. Probably one of the worst things I've > ever felt while comfortably sitting in front of my computer, browsing the > web.

No kidding. I only noticed after it was over how much I was sweating. It was pretty powerful.

</comment></comment><comment><USER16> It seems appropriate to plug this article "Drowning Doesn't Look Like Drowning" : [http://gcaptain.com/drowning/?10981](http://gcaptain.com/drowning/?10981)

</comment><comment><USER17> I want to watch, but can't transfer fast enough. Therefore:

wget [https://s3-eu-west-1.amazonaws.com/guy- cotten/videos/guy_cot...](https://s3-eu-west-1.amazonaws.com/guy- cotten/videos/guy_cotten_experience_master_720p.mp4)

Hope that helps someone.

</comment><comment><USER18> All I get is a black screen with an intro logo, and an endless loop of ocean sounds.

Won't play in a reasonably secured Firefox 35 on Linux. "This operation is insecure" \- main.js:6 Because a huge function is on one line, it's hard to diagnose the problem.

<comment><USER19> Perhaps you have cookies or localStorage disabled? I browse that way by default and it is unfortunate the number of sites that just plain don't work (without any kind of message to that effect).

<comment><USER18> Of course I do. The question, of course, is what _else_ is that site doing that needs cookies or local storage?

</comment></comment></comment><comment><USER20> Please - include an "autoplay" notice in headlines.

</comment><comment><USER21> I made it to 4:30. Is there more to the story (more flashbacks?) if you survive for longer? I got the impression that Charles was deliberately trying to kill Julien. Maybe I'm reading too much into this.

Also, there's a nice double-meaning in the French version of the title. "Sortie en mer" means "sea trip", but taken word-for-word, it could also mean "trip in the sea".

<comment><USER16> Having a trackpoint equipped computer I scroll to infinity with no effort, I tried a few times and the character always drown around the 5 minutes mark.

I suppose the whole thing is well made and everybody gets to see Charles waving goodbye and laughing right before the character drowns.

<comment><USER21> I missed that part, too. In my version, Julien's wife reaching out her hand was the last thing I saw before the ocean floor.

</comment></comment></comment><comment><USER22> I just get the splash page, and then nothing. I assume I'm missing something?

<comment><USER23> The whole thing is a splash page. :rimshot:

</comment></comment><comment><USER24> No pause button and not fully preloading made this unusable on a "slow" (<10Mb) connection.

</comment><comment><USER25> This is exactly why my girlfriend and I always use our PFD's with harnesses when passagemaking and alternating watches. It's a simple thing to strap into the jacklines and all but eliminates our fears about this sort of thing happening.

</comment><comment><USER26> I was doing good until he tore his fingernail off. Yuck!

Is that something that really happens?

<comment><AUTHOR> I think what they were going for is the water can be so cold you loose the sensation in your fingers so trying to get a response combined with decreased body temperature, results in applying too much force to break it off.

Also makes for a good cringe factor to make the simulation feel even more real.

</comment></comment><comment><USER27> This works for a while, then freezes.

</comment><comment><USER28> It would be interesting to see full length feature films developed in this technique.

</comment><comment><USER29> Very well done. At one point I thought I could bob on the surface. Nope.

</comment><comment><USER30> So why didn't the other guy turn back?

<comment><USER31> Same reason he jibed unintentionally. He doesn't know how to sail.

</comment></comment><comment><USER32> i can't get past 5 min. Is 5 min the hard upper limit of how long you can play this game?

</comment><comment><USER33> Who else here waiting for sharks?

</comment><comment><USER34> Was this a Oculus production?

<comment><USER35> I got 3mins 28s before drowning and then it said "you tire faster than you think at sea. Always wear a life jacket." I'm gonna go with it being an interesting PSA.

<comment><USER36> How do you even __try __to stay afloat? I get 0.

EDIT: Ok, you scroll up. For some reason, it didn't work for me last time I've seen this.

5m02s. But you cannot win in this (not)game. Splendidly done.

<comment><USER37> If you've got a mouse with a scroll wheel, scroll "down" constantly to stay afloat

<comment><USER38> I'll bet I could cheat it with WebDriver or something, but I'm not that industrious.

<comment><USER39> I simply did:

        sleep 5; while true; do xdotool click 4; sleep 0.01; done

(The sleep 5 at the beginning is to have time to switch to a different window and put it fullscreen.)

<comment><USER38> Did it work? Does he get rescued? Is bash better than a life jacket?

</comment></comment></comment></comment></comment></comment></comment><comment><USER23> Whenever you go out to sea... well... just don't go out to sea.

<comment><AUTHOR> Plane crashes can be over water. Just be sure you grab your seat flotation device to make treading water somewhat easier.

<comment><USER40> Learn the dead man's float.

</comment></comment></comment><comment><USER41> So, let's see... autoplay, splash screen, a video with no navigation controls. That site's UX sucks in a big way, so why is it #2 on HN?

<comment><USER42> Well probably because that's a very creative way to spread their marketing message. And because it is very well done technically as well: stitching video segments in an order that depends on user action, without any visible transition, means they put a lot of work on that.

So I don't think general UX/video guidelines apply in this case, even if they're valid for most cases for online video.

Sure, they should probably have used an adaptive bitrate video for users with poor connection, because here they can't pause and let the video prebuffer for a while. Other than that this is pretty impressive</comment></comment>


$25M Round of Financing and 400% Growth for Couchbase - <AUTHOR> http://blog.couchbase.com/25m-round-financing-and-400-growth-couchbase

<comment><USER2> Congratulations. This investment makes a lot more sense to me than some of the others in recent times. The Uber one for instance, though I hope they'll give their investors a healthy ROI I can't figure out how they arrived at the valuation they did. In the case of Couchbase that is a lot easier (at least for me...).

<comment><USER3> Very exciting news!

</comment></comment><comment><USER4> Congrats!</comment>


Ask HN: What are things you would change about Linux? - <AUTHOR> <comment><USER2> No problem with the Linux kernel BUT the user space is fragmented.

</comment><comment><USER3> Single click software installation. like .exe or .msi

<comment><USER4> Deb? Afaik also RPM distros have such tools.</comment></comment>


Ask HN: What one idea or lesson has transformed your whole life? - <AUTHOR> <comment><USER2> I figured out pretty early I didn't have the patience to develop deep expertise in a particular field, but that I could get up to competence reasonably easily. When I started to accumulate competence in enough areas, I became increasingly able to succeed in more situations. At 22, I was the most qualified person in a particular specialty in a large metro area, not from deep expertise, but because I brought together competence in 3 or 4 fields that added up well for that task.

It's a lot like how 3 random words make a good password.

<comment><USER3> What fields did you combine?</comment></comment>


How long should you continue a boycott? - <AUTHOR> https://shkspr.mobi/blog/2018/06/how-long-should-you-continue-a-boycott/ <comment><USER2> My boycotts of Olive Garden, Chick Fil A, and Papa John's are permanent.

I've added Facebook to that list.

Microsoft, despite their evil tactics in the 1990s, is not on that list.</comment>


LGPL and the iPhone - <AUTHOR> http://www.loufranco.com/blog/files/lgpl-and-the-iphone.html

<comment><USER2> _To do either of these things, the user would need to be enrolled in Apple's developer program which costs $99/year. These terms are implicitly part of your terms, meaning that it's basically equivalent to you charging $99/year for the user to make modifications._

Not any more than targeting your app at the iPhone requires the user to buy an iPhone, thus being equivalent to charging $700...

<comment><AUTHOR> It is more, because the cost is incurred when you try to exercise your rights. The GPL allows costs to obtain the work in the first place. Otherwise there could be no GPL for software that runs on computers that cost money.

Once the costs are incurred for obtaining the work, there can only be nominal charges for replacing the LGPL covered library (cost of media, for example, is ok).

</comment></comment><comment><USER3> Why don't you just stick a web server on the app and allow the download of the source files?

<comment><USER2> The alleged problem is not in access to source code of the app or library, but is in users inability to recombine modified LGPL piece with the app itself to produce new work. A user who wants to modify the LGPL piece of an app would have to pay the dues to Apple to make use of thusly modified app, and this is deemed to violate the "no fees imposed" clause.

<comment><USER3> No they wouldn't, they'd just need to jailbreak their phone and self sign.</comment></comment></comment>


Yahoo pays software engineer more than Google - <AUTHOR> http://vida.io/discussion/uqctrZDsecBWCWvBv

<comment><USER2> As they should. Google doesn't have to pay a premium to get people to work there.</comment>