Thinking This iPad Mini Thing Even Througher - <AUTHOR> http://daringfireball.net/2012/08/ipad_mini_even_througher

<comment><USER3> For anyone wondering why Daring Fireball is able to garner a lot of attention (and for that matter, almost any article pertaining to Apple) I refer you to two studies:

\- When, Why, and How Controversy Causes Conversation by Zoey Chen and Jonah Berger

\- What Makes online Content Viral? by Jonah Berger and Katherine L. Milkman

Results from the first study reveals that controversy significantly affects likelihood of discussion. The second study comes to a similar conclusion but fleshes it out a little more eloquently:

"Importantly, however, our findings also reveal that virality is driven by more than just valence. Sadness, anger, and anxiety are all negative emotions, but while sadder content is less viral, content that evokes more anxiety or anger is actually more viral. These findings are consistent with our hypothesis about how arousal shapes social transmission. Positive and negative emotions characterized by activation or arousal (i.e., awe, anxiety, and anger) are positively linked to virality, while emotions characterized by deactivation (i.e., sadness) are negatively linked to virality. More broadly, our results suggest that while external drivers of attention (e.g., being prominently featured) shape what becomes viral, content characteristics are of similar importance (see Figure 2). For example, a one-standard deviation increase in the amount of anger an article evokes increases the odds that it will make the most e-mailed list by 34% (Table 4, Model 4). This increase is equivalent to spending an additional 2.9 hours as the lead story on the New York Times website"

Apple is well known for controversy and Gruber is known for his snark (though I found this article to be insightful speculation) - the two seem to really complement each other and a lot of their success comes down to their behaviour. So for anyone who feels inclined to write another "Why is Gruber on HN?" post, that's why.

<comment><USER4> Backing your opinions up with studies is great. There sure are plenty of reasons (other than quality, which is the elephant in the room IMHO) that Gruber might sometimes find himself on HN.

But your analysis is more about why _any_ article of his can qualify. Wouldn't it be better to judge this individual piece on its merits instead of pleading the general case?

If you label each of his articles as "Controversial; Pro-Apple" you run a risk of forgetting to read them. Today's piece should count against that label, not reaffirm it.

</comment></comment><comment><USER5> I'm not sure what's gotten into Gruber lately, but not only is this entire essay basically attitude free, he's also got a lot of content, and, dare I say, math/geometry in this piece?

He gives credit to Digitimes of all orgs for the original (March!) prediction of a thin-bezel ipad - and goes out on a bunch of limbs predicting what the new iPad Mini might look like. In particular, his weight prediction, of 265 grams, is somewhat hard to believe - but would be very much appreciated by those of us who spend 2-3 hours a day reading books on our (somewhat overly large for that function) iPad.

I guess we'll know in another 30 days.

<comment><USER6> If you're just reading text-based books, why not go with a Kindle? They're cheap and much better suited to the task.

Graphics-heavy stuff beyond the scope of the Kindle is usually larger format anyway, and even the 10" iPad feels a bit small for that.

<comment><USER7> EInk Kindles can't really do email, or twitter, or skype or angry birds. Right now I tote around three devices (four when I haul my laptop.) A smaller iPad means I get rid of the Kindle and the iPod touch.

<comment><USER8> Really? I find reading on any device for a decent length of time that isn't e-ink a real pain.

<comment><USER7> EInk is definitely better, but I read the entire "Game of Thrones" series last summer on my iPod touch using the Kindle.app.

<comment><USER9> I have used the GoodReader app on iTouch/iPhone and read about 10 MB of txt files so far. (The 2001 triology, all Stainless Steelrat, the Red/Green/Blue Mars triology, a lot of Heinlein, the Ringworld triology)

I find the iDevice very easi to read on. Perhaps e-ink is even better.

</comment></comment></comment></comment></comment></comment><comment><USER10> I'm glad Gruber seems to be writing more of these long form pieces. Short and snarky is not as much of a strength for him as he thinks it is.

On the content: Right on. I will definitely be surprised if the words "thinner" and "lighter" do not feature prominently in Apple's keynote, both vs. the Retina iPad and the Google/Amazon competition.

<comment><USER11> _I'm glad Gruber seems to be writing more of these long form pieces. Short and snarky is not as much of a strength for him as he thinks it is._

My thoughts exactly. His recent talk with Siracusa must have helped.

[edit]

From the show, 1h24m23s: "You haven't done one of those in a while where you do like screen shots and stuff, you used to do that more…"

He also changed his favicon soon after Siracusa remarked that it wasn't retina ready, so he probably listens him. <http://daringfireball.net/graphics/favicon.ico?v=005>

<comment><USER12> He still manages to come up with gems like this:

[http://daringfireball.net/linked/2012/08/01/nokia-nail- polis...](http://daringfireball.net/linked/2012/08/01/nokia-nail-polish)

He and Siegler come off as partisan hacks and nothing else. Hence mostly only Apple fans seem to think he writes great. I do not know why they have to hate other competing platforms so immensely to love Apple.

<comment><USER13> Even outside impartial observers see the Nokia situation just getting worse and worse, and Windows Phone doing absolutely nothing to pull them out of the hole they're in.

I appreciate Gruber because he's unapologetic about something like that. We can dance around it forever, but judging by sales and in-the-wild presence of WP7, that briefly if crudely summarizes the Lumia & WP7 ecosystem to date. Doing this stupid old world stuff like distributing nail polish that matches your phone isn't distracting anyone from the increasingly untenable situation Nokia is sliding into right now. Moreover, moves like that make it seem like they're treating their situation flippantly.

It's not about "hate", it's about not candy coating things to appease certain groups. We heard for the last two years about how beautiful and fast and revolutionary WP7 is and how nice the Lumia hardware looks. Now it's time to put up or shut up and they just haven't. That's a fact, and I don't see why someone should have to ignore that and paint a happy face on the situation to not be considered a "hack". Moreover, I don't think you can extrapolate from that that Gruber hates Nokia, the Lumia or WP7. It's just a snarky observation.

If your issue is with the joke itself, I'll give you that. It wasn't all that funny or anything. I also agree he's a much better writer when in long form, and his snark does get over the top. I see where he's coming from here though.

<comment><USER14> See, even you managed to write many more words than him. It's not just that one post linked which is bad, it's a whole series of posts especially about Google and Android full of smugness, snark and sneering designed for his target audience, Apple fans and apparently, Google haters. It's like some of his posts are inside jokes at a fraternity club, and frankly are of that quality. It's tabloid journalism and nothing else, frankly.

You think any article by someone calling Ping a brown piece of shit would ever be featured on HN? Hell, even Paul Thurott's Winsupersite is hellbanned on HN.

</comment></comment></comment></comment></comment><comment><USER15> >If you think these stories appearing within a day of each other in the two most-respected business publications in the U.S. — at the same time the Nexus 7 reviews began appearing and the device started shipping to customers — is merely coincidental and not a strategic competitive leak from Apple PR, then I would like to invite you to play in my poker game.

>The angle to these stories is not merely "Apple is set to release a smaller iPad", but "Apple is set to release a smaller iPad and it could squelch the Nexus 7 and any other smaller tablets before they ever really get a chance to take off".

Gruber will apparently even try to spin a "me too" response by Apple as genius.

<comment><USER16> You seem to assume the "iPad Mini" hasn't been in development since well before the Nexus 7.

Given how short a timeframe (4 months) Google gave the development of the Nexus 7[1], and Apple's supposed "don't release until it's 'perfect'" attitude, I wouldn't be surprised if it was indeed the case that the iPad Mini entered development first. If so, does it really count as "me too"? Or just later to market?

(speculation) What if the Nexus 7 was a response to the rumoured possibility of a 7-inch iPad? A way to try and capture that segment of the market before Apple rolled into town?

[1]:[http://www.forbes.com/sites/danielnyegriffiths/2012/08/06/se...](http://www.forbes.com/sites/danielnyegriffiths/2012/08/06/seven- inches-four-months-a-number-one-sales-target-how-asus-built-the-nexus-7/2/)

<comment><USER17> _Given how short a timeframe (4 months) Google gave the development of the Nexus 7_

The Nexus 7 is a rebranded Asus device that was talked about last year. Then consider the Galaxy Tab, and the basic fundamental that Android has never dictated the sizes of devices.

Only Apple so tightly coupled their API with very precise, specific form factors and sizes. It is impossible to view Apple's move (especially after widely criticizing a 7" tablet -- recall the sandpapered fingers nonsense) as anything but a me too maneuver.

<comment><USER7> Jobs used to disparage a product line while secretly working on a superior product. Anyone remember 2009 and netbooks? Jobs dissed them the entire time Apple was working on the iPad.

The "sandpapered fingers" bit was just Jobs saying "small tablets are junk. We're working on the problems so our product won't be junk."

<comment><USER18> I'm being pedantic, but wouldn't the Air be a more appropriate netbook comparison?

As for the sandpapered finger thing, I imagine that you're right, but at the time, I wouldn't necessarily think the sandpapered fingers comment was just blowing smoke.

I'd guess that Jobs was simply conveying his findings at the time. Obviously, this is purely speculation, but the in years leading up to the iPhone and iPad touchscreens and software weren't that great and users weren't familiar with them either. I'd wager that the testing that went into touch-target optimization led to results that made Apple/Jobs uncomfortable with releasing a 7-inch.

<comment><USER7> >I'm being pedantic, but wouldn't the Air be a more appropriate netbook comparison?

The Air predates the brief netbook craze. The netbook was supposed to be the cheap computer you can take everywhere. People were surfing the net from their couch, using it on long commutes, and bringing them everywhere. The iPad pretty much killed the nascent netbook market.

The Mac Air took a couple iterations to get popular, but it's now cannibalizing the college kid/small business person's laptop. The Air might be as light as a netbook, but it's not a cheap compromise, like the netbooks were.

</comment></comment></comment></comment></comment></comment><comment><USER19> I'm not a regular reader of daringfireball, but that blog post is very long on speculation and decidedly short on facts. It's random chance whether any of the resolutions, dimensions, weights, or features he settles on wind up proving to the true. This is firmly in the "Bluray support will be native in the next version of OSX!" sort of speculation.

<comment><USER20> I've started to read DF posts like this with the mindset that he has some inside information. It is very short on facts, but the logic seems mostly sound. Unfortunately it comes across to me as a "I have 75% of the info, I need to create 100% of the story" kind of piece.

<comment><USER21> It's exactly that sort of piece but that's actually why I read Daring Fireball.

Gruber obviously comes from a very specific position when it comes to certain things, but whatever you think about him he's someone who watches Apple very closely and has done for some time.

With someone like Apple where 100% of the information isn't out there, if I'm going to read speculation then I'd rather read Gruber's speculation than most because he's far better equipped to try and fill in the gaps.

</comment></comment></comment><comment><USER22> I wonder if Apple is going to replace the iPod Touch with this.

Think about it: the Touch didn't get a spec bump while the iPhone, iPad and even the AppleTV did, and it sells for the same price of a Kindle Fire, Nexus 7 or Nook Tablet, all popular small tablets in the category where this iPad mini would compete.

PMPs are dead mostly because the same kind of people who bought PMPs are now buying tablets and Apple can't make this new iPad too expensive or it will be too close to the iPad2 and consumers will buy that one instead, nor can it make the Touch cheaper or it will cannibalize the Nano.

<comment><USER23> I've seen it suggested that the Nexus 7 isn't the Android iPad, it's the Android iPod Touch. This makes sense to me, and it makes sense to me that Apple could be moving in a similar direction with the iPod Touch itself, especially if it can hit those weight goals. This would also seem to open up some space for the iPod nano to gain functionality.

<comment><USER24> Alternatively, maybe soon – with the small iPad filling the $249 price gap – Apple will finally kill the iPod Classic and cut prices on the rest of the line. They've been manufacturing the lower quality retina display for the iPod Touch for two years, and costs must be down significantly.

Combine that with falling costs for flash storage, and I could see them going down to $150-$250 for the Touch ($150 for 16GB up to $250 for 64GB), $100/$125 on the Nano, and keeping the Shuffle at $49.

<comment><USER25> I'm hoping they keep the iPod Classic around, regardless of how well they sell. In my mind, it's the seed of the Apple renaissance.

<comment><USER26> There really is a dearth of high-capacity PMPs anymore. I still have my Zune 120 in my truck, constantly plugged into the stereo. I sync it over wifi when I want to add new music, and I have my entire music collection available if a certain song unexpectedly pops into my head and I have to listen to it. 64GB is still too small and too expensive to be feasible for carrying around an entire catalog. With the Zune gone, Apple is the only game in town for high quality, high capacity media players (surprisingly, CNet doesn't include it in their "best hard drive mp3 player" list, only the mediocre Archos 5 at $500).

</comment></comment></comment></comment></comment><comment><USER27> After reading both this and the iMore article, I really feel like Q4 this year is going to be like nothing we've ever seen. There won't be a reason for the average consumer _not_ to get an iOS device. I think we're heading into a time where Apple's dominance will pass the threshold of what Microsoft had in the 90's.

And, if you consider a revamped TV is on the way in a couple years — man, we're talking about iOS in the living room, in your lap, and in your pocket. It's astonishing to think that the iPhone is only 5 years old at this point.

<comment><USER28> Um... So a quarter notable mostly for Apples entry _into a tablet form factor market already pioneered by other competitors_ is somehow a testament to the platform's... dominance?

(I really want to respond to the idea of yearning for another IBM/Microsoft- scale monopoly too, but I'll limit myself to simple snark for now.)

<comment><USER7> Apple's entry into the phone market already pioneered by other competitors is a testament to the platform's dominance.

Also, no one would be making tablets of any size if it weren't for the success of the iPad (introduced January 2010.) If you recall, 2009 was all about the netbooks. Remember them? Nobody else does either.

The Nexus 7 (released at the end of June) is the first non-iPad tablet of any size that has ever gotten a legit positive review. It's hard to see how the unimpressive Android tablets of the past two years and the Kindle Fire constitute successful pioneering. And now Apple looks to introduce a very strong competitor three months later.

Here's my prediction. Unless the iPad mini is an unmitigated turd, Apple's iPad mini will outsell the Nexus 7 five-to-one during the Christmas quarter. That's platform dominance.

<comment><USER29> it will outsell the Nexus 7 just because it has an apple on it's back. I know that like everyone in here.

</comment></comment></comment></comment><comment><USER30> From the standpoint of a mobile developer and a user of one of Samsung's 7" tablets, the 7" form factor is too big for phone apps to really feel right on it, and too small for the big tab apps to be naively scaled down and feel right. So any Apple tablet at that size will suffer from a lack of good software until everyone catches up.

On the plus side, with the entry of an Apple device, there will be a much greater incentive to create workable design paradigms for the form factor, and both Android and iOS devices this size will benefit.

<comment><USER31> You're assuming that an iPad mini screen would be roughly as usable as a nexus 7 screen, but if the rumours are correct they would be very different. The Nexus 7 has a 'letterbox' widescreen aspect ratio compared to the iPad's chunkier 4x3 screen. Also the iPad screen would be 40% bigger. These are not small differences.

</comment></comment><comment><USER32> I do not see how anybody might think it would have iPad-like edges

An edge to place your thumb on must be about an inch wide. A 7 inch diagonal screen is 4 by 6 inch or so. With a one inch edge, the edge would be 16 square inches, or about a third of the area of the device. I do not see how they could sell you that (well, maybe, if they used them for solar cells and managed to power the device from it)

</comment><comment><USER33> This was a very good piece from gruber and I say that as someone who has consistently hated his snarkiness and apple fanboyism in the past. He makes deep analyses of the ipad mini here and dare I say, sets himself apart as a key asset in the Apple tech press. There should be someone as capable of doing in-depth analyses in other tech fields too. I was thinking specifically about android device news. The folks at androidpolice are the best I know. But not of Gruber's calibre.

<comment><USER34> Anand Lal Shimpi of <http://www.anandtech.com> is of that calibre and far less partisan - particularly if you're looking to buy components like motherboards or an SSD.

<comment><USER35> I like Gruber, but Anand's reviews/analysis are of a far higher calibre than grubers.

</comment></comment></comment><comment><USER36> The thinness angle doesn't sound right to me and would be a bad decision to trade it for real features. Thinness is important, don't get me wrong, but nearly all iOS device users use cases.

The thickness of a case can often double overall size and weight in your hand. This that isn't going to change, probably ever.

<comment><USER37> The extreme popularity of the mac book air and now pc clones of that form factor would indicate otherwise. I think Gruber hit the nail on the head with: Don't think of it as an iPad mini but an iPad air.

Once the early adopters flash their iPad airs around with no case (or an extremely thin mag cover), an ipad 3 is going to look fat and heavy. A nexus 7 is going to look bulky and old. Soon it will be a basic expectation that tablets are light as feather computers with no perceivable thickness. Tablets that don't come in this form factor will be seen as clunky relics of the past.

The best way to tell if an apple product will do well, is to ask your self: "Once this product gets wide spread adoption, will this product make its predecesor seem, old, clunky and/or unrefined". From a tactile and visual stand point a iPad air will do this.

<comment><USER36> OK, but everything will still be in a case so still fat and heavy and clunky looking. A shock proof case can only be so thin and only when you can prevent thin glass/metal/plastic from breaking or warping so easily (let's see how long that takes) will that cease to be the limiting factor. And the cases you see around town aren't the mag covers, I'm talking about fully blown folio in synthetics or leather. Mag covers only protect the screen from scratches and provide the auto sleep function. You can't bring the MBA into the comparison. People don't carry them around everywhere they go, whipping them out 100+ times a day and dropping them on a regular basis.

Full disclosure: despite my argument, I hate cases on my devices and refuse to use them aside from a thin tablet screen cover.

<comment><USER38> So they should make it out of rubber because "it'll end up in a case anyway and be fat and heavy and clunky looking"?

There is a severe flaw in what you're saying - Apple didn't design the iPad 1, iPad 2 or iPad 3 with a full case in mind _, in spite of the audience using them lots.

_ Yes I realise they make the smart case. I think of this like the bumper - offering something demanded, but the core product was designed without it. They also introduced it significantly after the iPad 2.

</comment></comment></comment></comment><comment><USER39> For me, ipad with 7.85" screen makes sense. You do not lose screen real estate because it is the same resolution as iPad 1 & 2, it is easier to carry around, apps will not need new versions to support iPad mini. This is real size comparison of iPad 7.85" with iphone 4 and standard ipad: [http://www.sizeall.com/compare/Apple-iPad-7-85-inch- mockup-A...](http://www.sizeall.com/compare/Apple-iPad-7-85-inch-mockup-Apple- iPhone-4-Apple-iPad-2-Wi-Fi/75)

</comment><comment><USER40> This all makes sense to me and I can see this being a successful product. I don't know if its too early yet, but normally when Apple telegraphs a new product people will fall over themselves to hype up the specs and decry it as useless if it doesn't meet expectations. That hasn't started happening yet - <USER2> can imagine Apple hates the over expectations but I wonder if the opposite is worse. Maybe this is just a better understood fit in the market, or maybe it hasn't sparked peoples interest in the same way.

Personally I'll definitely be buying one, but mostly because I'm very money conscious and would love a slightly bigger iOS device.

</comment><comment><USER41> As a Kindle Fire owner I have to say the form factor of tablets this size is great. I just wish there was a better fix to the resolution issues. Limiting to low PPI for app compatibility seems like a hack.

<comment><USER42> >Limiting to low PPI for app compatibility seems like a hack.

What, and give developers another resolution to develop for? No.

The iPad Mini will use the iPhone 3GS LCD pixel density. Then in a year, the iPad Mini will adopt the iPhone 4 pixel density. This means that every "retina" iPad app that currently exists will display natively on the device.

So basically: wait a year and then you'll have that crazy-good iPhone 4+ density.

<comment><USER41> How will that work without having that other resolution you want to avoid? The issue was avoided on the desktop by not requiring everything be full screen.

I understand the issue, but my personal iPad usage would not be affected by more resolutions (I surf, read and watch video) but the greater PPI would be very appreciated. That's why it's frustrating.

<comment><USER43> It's pixel-doubled, so you just need to update the graphics, not redesign the entire app layout.

</comment></comment></comment></comment><comment><USER44> I think retina is very possible still:

iPad 2012 is 264 ppi at 9.7 inches

Gruber got a 7.85 in measurement somewhere (I think from a past article of his).

264ppi / 7.85 * 9.7 = 326 ppi

i.e., if they made a 7.85in iPad Mini, it would have the exact same DPI as a iPhone4/4S. I can COMPLETELY see this as a viable option, as they might be able to use some of the same lines as they do for the phones and they already know 326ppi is possible.

</comment><comment><USER45> ipod touch thin = ridiculously fragile screen, like the macbook air.

<comment><USER46> I haven't heard of anyone's Air screen breaking, they can't be that fragile.

(But I have heard of several people destroying them with coffee or beer).

<comment><USER29> Well I think that if you pour coffee or beer you would destroy any device, Apple or not.

</comment></comment></comment><comment><USER47> > You might need more thumb-rest room on the sides than you do on the iPhone, > but not nearly as much as you do on the full-size iPad.

Why? The iPhone is meant to be held in one hand and manipulated by the other. The iPad has a different use model and hence a slightly different design. How would the use model of the iPad mini be different?

</comment><comment><USER48> Why don't you just wait for it to get released instead of obsessing over it ahead of time!

</comment><comment><USER49> I enjoy reading Gruber quite a bit, but it's not for his snark or his analysis. It's for his perspective. He has lots of readers because he can connect the dots. He finds stories or details that may not seem relevant at first glance, but are signs of where things are headed.

He also loves to call bullshit on trashy link bait.

<comment><USER50> >He also loves to call bullshit on trashy link bait.

By linking to it. On his massive blog.

</comment></comment><comment><USER51> I think the iPad Mini is just a huge misunderstanding. Here's what I think the iPad Mini really is : [http://www.hteumeuleu.fr/wp- content/uploads/2012/08/ipad-min...](http://www.hteumeuleu.fr/wp- content/uploads/2012/08/ipad-minnie.jpg)

</comment><comment><USER52> My prediction: iPad Mini in seven delectable colors for just $299.

</comment><comment><USER53> Who the hell gives a shit?!

<comment><USER54> With 97 comments (as I write this) I'd say many people :-)

</comment></comment><comment><USER55> Um, I think it's supposed to be "more thoroughly". Just saying.

<comment><USER13> That's if you're trying to say thorough, which he wasn't. He was saying through. Different, although similar words.

This post is a direct continuation, picking up where the Thinking This iPad Mini Thing Through post left off. It's "Through-er" both as a joke and to make it perfectly clear it's a sequel to the previous post.

Thoroughly would imply something different, like he wasn't really thinking about carefully it in the first post. That isn't his intent. It's not supposed to supersede the other article, it's just "more".

<comment><USER56> When I read it I also immediately thought of Apple's "funnest iPod yet" line: <http://daringfireball.net/linked/2008/09/09/funnest></comment></comment></comment>


Pitfalls of Data Analysis - <AUTHOR> http://my.execpc.com/~helberg/pitfalls/

<comment><USER2> A really useful article on how to avoid 'lying' with statistics; very basic, covers Type I and Type II errors with a review of some of Tufte's materials. Well worth a look.</comment>


WeKan: Open-Source Meteor Kanban - <AUTHOR> https://wekan.io/ <comment><USER2> I recently built a Kanban board for Github using react:

[https://adewes.github.io/gitboard](https://adewes.github.io/gitboard)

It's fully client-side and doesn't require a server or giving a third party access to your Github account, and it's open-source.

</comment><comment><USER3> Aesthetically, the app looks great. Is it normal for there to be zero test coverage in a meteor app? That concerns me. I did see this thread in the issue tracker: [https://github.com/wekan/wekan/issues/467](https://github.com/wekan/wekan/issues/467)

<comment><USER4> Initially Meteor didn't have any support for testing apps. Since it has always had support for testing packages, teams generally had to split their app up into several private packages to allow for testing (with benefits to modularity too).

The Velocity project [1] was started to address this issue and now supports testing apps with Jasmine, Cucumber, and Mocha. There are also individual testing frameworks for Meteor apps such as Nightwatch (now StarryNight).

Even with Velocity, testing a Meteor app is not as easy to set up as testing a Rails app so I would guess most teams don't make it a priority unless they are going into production.

Packages, however, are another story and my impression is that all of the most popular packages [2] have fairly extensive test suites.

1\. [http://velocity.meteor.com](http://velocity.meteor.com) 2\. [https://atmospherejs.com/packages/most- used](https://atmospherejs.com/packages/most-used)

<comment><USER5> > Initially Meteor didn't have any support for testing apps.

I don't understand what this means... why do you need a framework to "support" testing. Can't you just... write a test using QUnit or Mocha or Tape or whatever you like?

<comment><USER6> The framework can make or break your testing. If it's very hard or impossible to mock parts of the framework, your testing will be significantly hindered.

</comment></comment></comment></comment><comment><USER7> I've been looking for an on-premise Trello for months and WeKan seems to be the best option for now. How would you guys feel about deploying such a project for 300 people? Too soon?

<comment><USER8> I've been using Wekan daily for a while now and I'd say it's pretty solid.

I hope you'll also consider running Wekan on top of Sandstorm (I'm the lead developer of Sandstorm). Wekan's developer is a fan of Sandstorm, as you can see here:

[https://discuss.wekan.io/t/support-exclusively- sandstorm/135](https://discuss.wekan.io/t/support-exclusively-sandstorm/135)

You might find some other apps you'd like to run on-prem. :) [https://apps.sandstorm.io](https://apps.sandstorm.io)

<comment><USER7> I've used Sandstorm when I tried Wekan but didn't really take the time to look into it, couldn't find anything about ldap integration with either Sandstorm or Wekan.

Now I've just read a bit more about it and a centralized app portal sure looks very interesting. I'll contact you guys in the next few weeks for your "Sandstorm + Business" offerings ;)

</comment></comment></comment><comment><USER9> Am I missing the 'kanban' part? This just looks like a Trello clone to me.

Is there anything actually relating to kanban built in? Like limiting the # of items, tracking cycle time, etc?

I can't find ANY settings anywhere.

Also, I can't figure out what a 'Grain' is. I think it might be a 'Board', but when I click on an App, it loads a page w/ boards, that isn't the same page as 'Grains'

So, no tests, no documentation, no settings, so kanban-specific features.

<comment><USER10> The Grain/App thing isn't from Wekan, but from Sandstorm.io which they use for the demo. A "grain" in sandstorm-terminology is an instance of an app (e.g. Wekan) on a sandstorm.io server.

</comment></comment><comment><USER11> I wonder if Maxime has considered using the newly announced Meteor-Electron project to package this as a desktop app - I am really in the market for a simple, open source task tracker that I can run as a desktop app so that I can alt-tab and similar.

<comment><USER12> A simple wrapper like nativefier should suffice...

[https://github.com/jiahaog/nativefier](https://github.com/jiahaog/nativefier)

</comment></comment><comment><USER13> I love WeKan - we use at at Bytemark (www.bytemark.co.uk) for our internal to- do board - high level project tracking across the company with 28 staff.

</comment><comment><USER14> Excellent work.

But why does the browser history get so polluted?

(Every click in the app seems to add an entry in the browser history.)

<comment><USER15> noticed this as well. super cool demo though.

</comment></comment><comment><AUTHOR> src: [http://korben.info/wekan-un-clone-de-trello-a-heberger- vous-...](http://korben.info/wekan-un-clone-de-trello-a-heberger-vous- meme.html)

</comment><comment><USER16> Took me a while to find this but [https://github.com/wekan/wekan/wiki/Install- and-Update](https://github.com/wekan/wekan/wiki/Install-and-Update) contains the instructions to install

</comment><comment><USER17> I can't seem to scroll the homepage.

Latest stable Chrome. Windows 10. Touch screen. Scrolling using mouse scrollwheel as well as trackpad gesture.

<comment><USER8> There's nothing on the homepage under the screenshot. I think it just doesn't scroll.

</comment></comment><comment><USER18> Awesome work. Contrats to all the team involved.

</comment><comment><USER19> It's a nice tools for dev and project management.I will try it at our team.

</comment><comment><USER15> Awesome project, as a total aside, isn't there an issue with using Trello's name on your site?

<comment><USER20> Why would referring to Trello by its name be illegal? They do not make any false statements!wnts about Trello.</comment></comment>


Why OO Languages Need Tail Calls (G. Steele post + interesting comments) - <AUTHOR> http://projectfortress.sun.com/Projects/Community/blog/ObjectOrientedTailRecursion

<comment><USER2> After having SICP as my first programming course it always bothered me that Python was so limiting when it came to stack recursion. In the case presented in this article tail recursion was clearly a powerful tool for maintaining abstraction barriers; I'm curious, how do people handle cases like that in Python?

<comment><USER3> Yes, that's annoying, isn't it? The Python language has an excellent development process IMHO, but, alas, even great processes can produce substandard results now & then. And I think it's clear that leaving TCO out of Python was the wrong decision.

But to address your question: the fact is that OO is rarely taken to this extreme. That's why Cook's article (referenced on this page) had to be written; people just don't think that way.

And even when they do, situations like that in the article are not super common. What we have here is a tree-ish structure in which nodes do computation on their subtrees, and the _way_ in which that computation is done needs to be hidden behind an abstraction barrier. That last is what is forcing the recursion requirement. If it weren't true, then some master function could query all nodes in the tree directly, and an iterative method would work fine.

However, if we are in such a situation, then the fact is that Python just doesn't work as well as some other languages. There is no "way to handle it".

Note, BTW, that TCO is not a complete solution. A function only gets one tail call. If a node needs to query _two or more_ child nodes, then at least one of those calls is not a tail call, and you get stack troubles. The linked page gives an example of just such a situation: the "rebalancing" stuff mentioned in comment #7. See also my comment [#11, id ggchappell]. Guy never responded to it; wish he had.

<comment><USER2> Thanks for the detailed response. The rebalancing situation is interesting.

Another interesting link I noticed was a discussion on LtU that solves the posed question without using TCO, but it does use types which would again be cumbersome to use in Python.</comment></comment></comment>


Do CS depts pretend programming is hard even though it is now easier than ever? - <AUTHOR>

CS depts want to increase enrollment after all...<p>Moreover, I wouldn't be surprised if professors even exaggerate the difficulty of programming in their grant applications. <comment><USER3> Is programming easier than ever?

You're right; I don't want to write scripts to rename a bunch of files in asm. Still, programming isn't easy, as evidenced by how few people there are to look up to in the field relative to the number of participants, many of them themselves somewhat proficient.

Our modern languages let us do things that used to be hard in just a few lines, but that just means that we imagine more ambitious projects - <USER2> ambitious, in fact, that we coin all sorts of terms like "Test-Driven Development," which is itself nothing more than a moniker for "We know that we're not going to get this right the first time, and even if we get it right later, we should frequently verify that something else doesn't break it." Yes - programming is so easy that changes far away still break things, and despite a lot of theories on modularity and the like, we still don't know how to do it in practice.

We all want to figure out how to write better software, but despite all of our languages and methods and collective experiences, we're still not very good at it. That last clause well describes something hard, not something easy.

<comment><USER4> Exatly. We're often at a higher level of abstraction from the hardware now, but that doesn't mean our job is any easier; we're just tackling broader problems.

</comment></comment><comment><USER5> I'm not sure you understand what computer science really is. Perhaps you are thinking of software engineering.

It varies by university, but my program was approximately 75% theory courses and 25% practical (programming, give or take) courses. This seems to be a common misconception among the uninformed. While there is some coding in select theory classes, it is limited to POC implementations. Most mid to upper level practical courses (attempt to) teach about exterior factors in programming such as team management, testing, and workflows.

To say that programming is easier than ever is a naively sweeping statement. There may be truth in some aspects such as increased communities around languages, advancements in frameworks, and pushes for better tools and documentation, but the basis of programming has not changed. If anything, it has broadened and become more complex.

<comment><AUTHOR> I've spent quite a long time in academia (I'm a former academic) and I am well aware about the difference between software engineering and computer science.

The point though is this: the typical web 2.0 app is really easy to build.

<comment><USER5> _The point though is this: the typical web 2.0 app is really easy to build._

Saying that and saying programming is easier and it is making CS departments less relevant are very different things. In accodance with that, building a web 2.0 app may be easy, but building a good web application takes as much skill and talent as ever. Standards change.

<comment><AUTHOR> Frameworks get better all the time. For example, building a scalable web app is now much easier with the google app engine.

<comment><USER5> I agree and made note of framework and tool advancements above, but you are still missing the point. Good utilities make it quicker to create an application, but they don't create good programmers or good code by themselves.

Squeak (<http://www.squeak.org/>) was an interesting advent. It made programming pretty simple. A layperson playing with squeak could "program," but it hardly stands in for even an introductory CS class.

I also take issue with the fact that you treat programming or web app development as if good is a static threshold. A good web app a few years ago hardly compares today, and that can be seen in the evolution of almost any major website.</comment></comment></comment></comment></comment>


How I Defeated LinkedIn's 3rd-degree Profile Security - <AUTHOR> http://osandamalith.wordpress.com/2014/01/12/how-i-defeated-linkedins-3rd-degree-profile-security/ <comment><USER2> Here's the cached version, since the original seems to be missing for some reason: [http://webcache.googleusercontent.com/search?q=cache:9tXSzhj...](http://webcache.googleusercontent.com/search?q=cache:9tXSzhjuVb4J:osandamalith.wordpress.com/2014/01/12/how- i-defeated-linkedins-3rd-degree-profile-security/)

</comment><comment><USER3> An alternative: Use Google to find the person's last name, and then search on LinkedIn using their full name. Their full profile will then be displayed.

<comment><USER4> I actually used this technique myself once. In preparing for an interview, I was able to access someone's full profile. I don't know if this technique would work for every profile, but it served my purpose.

</comment></comment><comment><USER5> tl;dr: playing with the query string lets you see profiles of users three degrees away (which is, apparently, not normally permitted)</comment>


Raspberry Pi 4 Cluster with Kubernetes (K3s) - <AUTHOR> https://www.youtube.com/watch?v=DjpVtNjiXSU <comment><USER2> Am I right in thinking that these clusters are purely for educational use or do these things scale in a commercially meaningful way?

<comment><USER3> They are definitely not efficient for large computing needs. You can a much better dollar per mip ratio in a faster system.

But I think there are definitely some commercial applications for tiny clusters of 2 to 3 Pis where small amounts of local compute is desired with high availability.</comment></comment>


The Millennial Urban Lifestyle Is About to Get More Expensive - <AUTHOR> https://www.theatlantic.com/ideas/archive/2019/10/say-goodbye-millennial-urban-lifestyle/599839/ <comment><USER2> I think Thompson is correct on what's likely to happen at the company level but fails to consider the elasticity of demand at the consumer level.

As an anecdotal example, Uber Eats/Grubhub/Seamless fees are a material portion of total ticket price in DC (which seems to be different in other cities). They are also rarely subsidized for customers here. I am still eating at the same restaurants and probably get take-out just as much as a New Yorker where delivery is way more common - but I just walk over to pick it up.

Similarly, when Uber is surging, I take the bus or the metro.

Part of what makes cities so appealing is the diversity of options. If consumer-tech-based apps get more expensive, there are actually alternatives to literally all of them. I don't need a Peloton - I can just get a gym membership somewhere. Or buy a bike.

100% agree that Millennials are likely about to change their lifestyle options. But not certain that "change" directly equates to "accept higher prices."

</comment><comment><USER3> >Outside analysts will gasp and marvel: This meal-kit thing is on fire! But look closer: If it costs $500 to add a new user, and the typical marginal user—like you—only spends $400 on meal kits, there is no path to profitability. The road leads to the red.

Having worked for a "start-up" called Imperfect Produce, which delivers fresh- ish organic produce to your doorstep, I realize many of these companies (which tend to operate on a $X/mo subscription basis are not built to last). Imperfect Produce is a gimmick that brands itself as a convenience service to reduce food waste. Maybe it's affordable for 2, 3, or 4 months, but once your average consumer finds themselves a bit cash-strapped, the gimmick is the first thing to be cut. And back to the grocery store/farmer's market/Big Lots they will go.

If you want to know whether WeWork, Ubereats, or Wag are built to last, ask yourself whether they've revolutionized something, or if they're a gimmick. People see through gimmicks, especially once their car needs work, or rent's gone up.

</comment><comment><USER3> What's the difference between "urban lifestyle" and "millennial urban lifestyle"? As far as I can tell, "millennial" is just a euphemism for a young, white person who is not a plumber or a welder or a cop, but would probably be a lot better off if they were.

<comment><USER4> I think more generally in this context means a young adult who's been socialized to pass as a upper middle class professional.

<comment><USER3> Great comment. I feel like I've been "groomed" for a successful middle class life but at age 30 still haven't gotten close to anything professional. I feel more like a 30 year old boomer than a millennial.

</comment></comment></comment><comment><USER5> To believe that every individual living in the city who falls between the ages of 23 and 38 would somehow be affected by the shuttering of Blue Apron, Postmates, WeWork, Uber, or Lime completely misunderstands the lifestyle of a millennial living in any urban center in the United States.

So an app doesn't provide me a credit to go eat at a particular restaurant. Do you know how many restaurants, bars, stores, coworking spaces, transit options, and services I have access to living in the city? That's part and parcel why most people in that demographic are moving back into cities...

</comment><comment><USER6> Such a bad example. Just because a company is currently spending $460 on advertising to make $400 doesn't mean they can't one day spend less on advertising. Blue apron is spending so much on advertising so they can become ubiquitous and they don't have to spend so much money on advertising. That's like saying an electric car company can never become profitable because they spend so much money making electric cars. They're going to get cheaper eventually and they need to take losses for a bit.

<comment><USER3> Yes, but they're going to hemorrhage their dirty Saudi-Thiel-UAE money first!</comment></comment>


When Jack Dorsey Met Fred Wilson, And Other Twitter Tales (Book Excerpt) - <AUTHOR> http://techcrunch.com/2010/04/27/jack-dorsey-fred-wilson-twitter-book-excerpt/ <comment><USER2> I'm sure this is a fine book and would be interesting for many people, but having seen part of this story first hand I can tell that it's been white washed and isn't factually accurate. Odeo didn't run out of money for instance. I don't know if the people telling the story were loose with the details or if the writer was, but I don't think this is a retelling that anyone here should pay much attention to.</comment>


Moving from Native Apps to Progressive Web Apps - <AUTHOR> https://medium.com/javascript-scene/native-apps-are-doomed-ac397148a2c0#.p4aazx6vn <comment><USER2> As a web developer, I honestly hope the author of this post is wrong. Performance of modern web apps is simply awful compared to their native counterparts by any measure. They load slowly and consistently feel sluggish in comparison to proper native apps. Slack takes seconds to load and it'll happily sit on over a gig of ram while in use. (And remember, its a glorified IRC client.)

Web apps only have two benefits over native apps:

1\. They're easier to build in a cross-platform way, because you just have to make the app once

2\. Users don't need to install anything

I hope in the long run we solve both of those problems for native apps and move back to writing applications which don't depend on a DOM implementation to run. React-native is a great step toward solving (1). I hope that in time we can have modern (reactish), good looking cross-platform toolkit for native app development.

But the biggest hurdle is (2), which very few people are attacking. App stores have helped a lot, but we need to be able to run native apps without installing anything. It should be as easy as it is on the web. Unfortunately native app authors usually assume all their assets are bundled. Nobody even thinks about how long it takes from the point when a user decides to install an app to when they see the first content. On the web we count that time in milliseconds and on native apps we count minutes. There aren't any hard technical problems there - we obviously manage it on the web, so its easily possible. We need native apps to catch up if they are ever going to be able to compete as a platform.

<comment><USER3> Regarding #2 I feel like Oracle is dropping the ball here with Java for the desktop. They need to provide a lightweight JVM tailored specifically for desktop apps and for bundling into a self-contained install package, so that the app doesn't have to confuse users by downloading the JVM separately. Just pack it all into a single .msi/.dmg/.dpkg/etc, download one file, install it, and you're good to go. The JVM should be local to that app only, not global to the whole OS.

The filesize may be a little bigger than native apps, and redundant if you install more than one of such apps, but in this day and age of high bandwidth and storage that's an acceptable tradeoff. I spent 2015 working on a Win/Mac/Linux app where this would have been the preferred solution, it was annoying that in 2016 it still doesn't exist and as a result we're getting janky Node.js-based platforms like Electron ([http://electron.atom.io/](http://electron.atom.io/)) instead.

Qt and GTK are the only mature enough x-platform non-web-based options it seems, but Qt is not open source and GTK's look is dated.

<comment><USER4> I imagine you are out of touch with Java efforts.

Since Java 8, the JDK offers tooling to package applications, making it standard the way many third party bundlers used to work.

In Java 9 there is a linker, which will allow for an application personalised JRE, coupled with the startup code.

The biggest problem was that using Swing properly required a mix of programming and designer skills, which most didn't bother to learn.

At least on enterprise space of our customer base, we are still on Java and .NET for native applications, no Electron on sight.

<comment><USER5> > The biggest problem was that using Swing properly required a mix of > programming and designer skills, which most didn't bother to learn.

What about JavaFX 1/2? Do you have any information about its popularity and usefulness?

<comment><USER4> Sadly yes.

It is the Java version of XAML, and it is quite nice to use, but the uptake has been on the slow side. There were quite a few sessions at JavaONE 2016:

[https://oracle.rainfocus.com/scripts/catalog/oow16.jsp?event...](https://oracle.rainfocus.com/scripts/catalog/oow16.jsp?event=javaone&search=JavaFX&search.event=javaone)

Probably the place where it has seen more uptake has been in car infotainment systems, like by Volkswagen.

[https://static.rainfocus.com/oracle/oow16/sess/1462531766187...](https://static.rainfocus.com/oracle/oow16/sess/1462531766187001prJx/ppt/CON2609%20-%20Prototyping%20Automotive%20Apps%20with%20JavaFX.pdf)

However our Java desktop native projects are still mostly Swing based, or make use of either Eclipse or Netbeans as desktop framework.

And of course there is the Android Java fork, which doesn't offer any JavaFX compatibility (some guys on the community are porting it though).

</comment></comment></comment></comment></comment><comment><USER6> Native apps are helped by the weakness of HTTP/HTML. For some reason, the tech industry has been slow to admit what seems obvious -- that a technology designed in 1989 to let academics trade documents is a terrible solution for doing modern apps. At least for now, the tech industry has chosen a strategy of incremental improvement (of HTTP/HTML) rather than radical overhaul, but there does come a point when the pain is too much, and a radical overhaul begins to seem like an easier solution.

Consider React, and also Om, and Om Next. These strike me as proto-types for the technology that will eventually replace HTTP/HTML.

If you'd like to build a great GUI for an app that has to constantly interact with outside events/data, then you might expect to have these 4 elements:

1.) inbox

2.) outbox

3.) meta

4.) display

Both React and Om Next have moved somewhat in this direction. But both still struggle with the limitations imposed by HTTP/HTML. A particular limitation is the old notion of a "markup language", with its roots in SGML. Markup languages are great when academics exchange documents. But markup languages are terrible for GUIs for apps.

Also worth noting, of the 4 items I listed above, consider how much they map to what Joe Armstrong wrote about modules in Erlang, and consider how much thought and research, over the course of decades, has suggested that these 4 ideas, bound together, are important for building resilient systems.

At some point the tech industry is going to get rid of HTTP/HTML, and something like React or Om Next is going to become the dominant paradigm for building a GUI for TCP, that is a GUI for an app that interacts with events over the network.

Until that happens, native apps will continue to thrive, at least because they are built with tools that give sane options for the GUI.

<comment><USER7> Two questions:

1\. What's wrong with HTTP that hasn't already been addressed? I think we can agree on HTML having some limitations.

2\. What do your four elements represent? I haven't seen this exact breakdown before.

</comment></comment><comment><USER8> > From now on, I won't be building any more native apps

It looks like the author blogs exclusively about JavaScript. What native apps has this author built?

<comment><USER9> Well, at least it won't be too difficult for him to commit to this.

More seriously, this kind of comment seems to almost entirely come from javascript devs.

<comment><USER10> The article is by probably the worst blogger in the JS community. Full of hyperbole, biased if any research, always trying to sell his courses, and strange sources (dude quotes himself fairly often).

<comment><USER11> If everybody likes you, you're not being honest enough.

</comment></comment></comment></comment><comment><USER12> Reading that post feels like sincere but wishful thinking. Both major mobile platforms provide the developer with sandboxed access to a more or less complete unix machine. This means complete access to things like underlying network interfaces (via sockets), Full File API access to local storage (inside the sandbox), threads, memory management (via JVM/ObjC or at a lower level in Native C), Graphics hardware via OpenGL just to name a few.

Just because there's now the web standard has some half-hearted attempt at notifications doesn't change the fact that the HTML/javascript based machine available in web applications is a severely crippled platform for app development and always will be.

<comment><USER13> Yes, the web platform has more limitations, but it's a bit like when people wrote software for DOS (or bare metal) because Windows didn't give them direct access to _all_ hardware features. They weren't wrong, but how many bare metal software do you see today? Eventually the platform provides support to the needs of 99%+ of software, and more unrestricted access becomes a special case, not the default.

All of the things you've pointed out are either mostly available (File API, WebGL, ServiceWorkers, memory management using Typed Arrays like asm.js does) or will be soonish, and when all you can point to is stuff like CUDA, native apps will become the new "bare metal".

<comment><USER4> I see it everywhere.

On my computers the only web based software is related to online travel agencies, discussion forums not based on email and news sources.

When there is a native alternative, it gets installed.

<comment><USER13> Sure, and I use Debian on all my machines, and read my email with Alpine over ssh. But I don't think that tells me much regarding the overall tendencies of software development and use.

<comment><USER4> Well, the last three years I have gotten lots of nice projects coding greenfield native applications.

Outside the HN bubble not everyone is sold on web.

</comment></comment></comment></comment></comment><comment><USER14> This is something I've been thinking about for a while, why not make apps not require to be installed, and put them behind URLs?

Something similar to the way Blizzard does their games with the Battle.net client, e.g. you click "Install", and the game is playable after only a few megabytes, and then as you play things progressively load.

That could really disrupt the mobile scene, and Apple is well positioned to accomplish that.

<comment><USER15> Google are starting to do some work on this front with Android 'Instant Apps': [https://developer.android.com/topic/instant- apps/index.html](https://developer.android.com/topic/instant-apps/index.html)

<comment><USER16> I hope Apple does something similar and we can all move towards this direction, which seems to be the best approach, in my opinion.

</comment></comment></comment><comment><USER17> Native apps will die to hybrid apps but probably not to full web apps. There are some functions for apps that are much better done natively than through support wrappers and such that overly complicate the whole scenario. Hybrid apps are great for providing a UI that can be drastically overhauled with relative ease. They provide ways to make web feel native. Any app that is installed should feel like a native app. Hybrid apps are the way forward for small developer teams but large app devs should stick to native for the power and performance.

</comment><comment><USER18> Is it really that hard to build native mobile apps? No it is not. It does require learning something new. I don't hear any of my non technical friends complaining that this app isn't a web page or that I had to install a new app. I mostly hear developers who want to utilize their web development skills make the argument that native apps are bad. Is the native vs web argument actually just laziness?

<comment><USER11> They don't complain. They just don't ever install or use the app. The average user installs less than 3 new apps per month. [https://www.tune.com/blog/no- the-average-american-does-not-d...](https://www.tune.com/blog/no-the-average- american-does-not-download-0-apps-each-month/)

App install friction is much higher than website visit friction, and with PWA's, coming back is enough to prompt the user to install the app to their home screen with a single click.

Learning something new is not the big obstacle. The big obstacle is investment vs return on investment. If you have to write the same app 3 times, that is a significantly larger investment, and potentially much smaller return if what you end up with turns away most of your users.

Each click in the install process reduces the number of successful installs by 20%. So, start with 1,000 interested users. If the user has to click six times to install the app, you end up with only only 262 installs. And then you have to activate them to keep them using the app. Data shows you'll lose an average of 80% of your users after install if you fail to activate. That means you end up with 52 out of 1,000 potential users.

VS PWA. Once click means you start out with 800 instead of 252, so then you just need to activate them, which gives you 160 activated users.

3x the users for 1/3rd the investment. I don't know about you, but these are pretty compelling numbers for me.

</comment></comment><comment><USER19> I'm a web developer, and excited about progressive web apps. But until we have access to sensors and video streaming that isn't subpar, and sweet/easy camera APIs - this idea is good but simply not great- and that's a big difference when it comes to making an amazing UX on your crappy little phone. At least today: * service workers only on chrome * the install prompt is totally not a native browser feature * mobile web browsers are straight up slower at rendering

</comment><comment><USER20> I am building native webapps using PWAs at the moment. They are not there yet.

He touches on navigation, but misses talking about the Android hardware back button, which in PWAs hooks up to the same mechanism as it does in the browser: it goes back. This quickly stops making sense when you're making an application, as you want that button to go "up" rather than back. Imagine you are viewing a list of contacts and you: tap on a contact, tap edit to get the editable version, make some edits, tap save to get the change read-only version. In an Android app, you'd expect hitting back at this point would take you to the contact list. Here, it will take you back to edit mode for that contact.

There is also little to no support for apps that want to use large or arbitrary amounts of storage (imagine spotify with offline support as a PWA), or a framework to allow users to deal with that. With a native application I can store as much data as I want, and the user can see what data I'm using in the app list, and clear my data to remove it, or simply uninstall my app. With a PWA you're limited to some confusing arbitrary amount that is unpredictable to the application, the user cannot see this amount anywhere, let along aloneside normal apps where it should be, nor can they reasonably clear the data.

We are currently solving both problems, ironically, by wrapping our app in a native android app: solving the former by overriding where the hardware back button navigates to, and the solving the latter by (no joke) shipping a patched version of chromium with the obtuse quotas patched out.

<comment><USER21> > This quickly stops making sense when you're making an application, as you > want that button to go "up" rather than back.

Did you try to use the history API [1] for this ? Not straightforward but with either replaceState or the onpopstate event maybe you could achieve with JS what you are looking for.

[1] [https://developer.mozilla.org/en- US/docs/Web/API/History_API](https://developer.mozilla.org/en- US/docs/Web/API/History_API)

<comment><USER11> This is the correct solution to this problem in web apps.

</comment></comment></comment><comment><USER22> Native Apps Vs Web Apps is settled and Native Apps won. Web Apps offer compromised UI and performance and shall always remain a security threat - Cross Scripting, Link baiting, CORS my... . We are going to app less economy now - and contextual interactive interfaces that route to/from headless services based on advanced intelligence is the future.Apps are dying, long live the apps.

</comment><comment><USER23> Well, the idea is useful, but the examples at "[https://pwa.rocks/"](https://pwa.rocks/") don't work too well on desktop. They run in Firefox 49, and a service worker is created, but the browser console is full of error messages. There seems to be a tendency to write these "apps" like webcrap pages, with lots of ignored errors.

The Washington Post app loads "js/offline-analytics.js", some Google code which apparently snoops on you're doing while not connected and periodically sends the reports to the mothership.

"Inbox Attack" works fine.

</comment><comment><USER24> One thing the article does not touch on is monetization options for web apps. This is where the App Store makes everything orders of magnitude easier.

<comment><USER25> Except that these days it's more common to offer the app for free and then the user chooses or not to get premium content via in-app purchase. A web app or website can quite easily offer an upgrade to premium content if the user is already using that service.

More than monetization, the app store provides stronger discover-ability than web apps.

</comment></comment><comment><USER26> push notifications from web apps isn't even supported yet on iOS

<comment><USER27> Personally, I'm thankful for that. I can see how some might find them useful. I personally disable them whenever the browser presents me with the request dialog. I'm glad I'm presented with the option.

<comment><USER28> It was useful on Facebook until they decided to try and strongarm everyone into using Messenger.

</comment></comment></comment><comment><USER29> The author seems to really struggle with reconciling the click-baity title with the rather dull conclusion that native apps aren't that doomed just yet (if at all), within the last couple of paragraphs.

A better title would have been: A collection of highly useful resources for getting started with progressive web apps.

</comment><comment><USER30> Hard to take this article seriously when it practically ignores performance topics.

<comment><USER11> See this comment: [https://news.ycombinator.com/item?id=12943936](https://news.ycombinator.com/item?id=12943936)

</comment></comment><comment><USER31> You can't do push notifications on iOS from a web app. But apart from that there's a category of apps for websites that never should have been made, if that's the kind of apps you have been building in the past 5 years it's OK you realise it's time to stop making apps nobody uses. I've built some of those apps in my time but the majority of my apps couldn't be done without sacrificing or completely preventing functionality as a web app.

<comment><USER11> You can with Cordova. I've worked on several hybrid apps in recent years that took advantage of native features through a thin native wrapper.

But there are a lot of apps that don't need those features at all, and those apps are a great fit for PWAs.

<comment><USER31> Yeah but that's not what the author is talking about. Cordova applications still go through the very Apple specific tooling pipeline before end users can use it.

</comment></comment></comment><comment><USER32> Hey! This is more then a rant, it's a guide on how to make your web app usable without a Internet connection. This has been possible for a decade using application cache, but service workers will give more granular control and allow stuff like push notifications!

</comment><comment><USER33> I prefer the "Native Apps Are Doomed" title the HN link originally had.

Yeah, it's a little click-baity, but it matches the article and better tells me what it's about. Everyone knows what a native app is, but I would have never inferred by name that a Progressive Web App had any relationship to native development.</comment>


Compare Bitcoin and Litecoin prices with exchanges in China - <AUTHOR> http://www.coined.com/

<comment><AUTHOR> We just added a Litecoin arbitrage table to coined.com. Let us know if we should add any other LTC exchanges! We love feedback and are actively adding features to the site.

We used node.js, socket.io, and Semantic UI to create coined.com.</comment>


'Big Bang Signal' Could All Be Dust - <AUTHOR> http://www.simonsfoundation.org/quanta/20140921-big-bang-signal-could-all-be-dust-planck-says/

<comment><USER2> Perhaps this should be "Big Bang Gravitational Wave Signal" could all be dust.

From the headline, I was expecting something more shocking about cosmic microwave background radiation[1] generally. That would be THE Big Bang signal in my book.

[1] [http://en.wikipedia.org/wiki/Discovery_of_cosmic_microwave_b...](http://en.wikipedia.org/wiki/Discovery_of_cosmic_microwave_background_radiation)

<comment><USER3> I was thinking the same thing :))

</comment></comment><comment><USER4> Having spent my previous career studying the effects of interstellar dust (though not in this wavelength range), it's amazing how often I would be the buzz kill by arguing that something that someone saw actually probably could be explained by dust. It has major effects on the radiation we receive and its effects are sensitive to the exact details of how it's distributed and what it's composed of.

</comment><comment><AUTHOR> This is the Planck analysis on the arXiv: [http://arxiv.org/abs/1409.5738](http://arxiv.org/abs/1409.5738)

</comment><comment><USER5> I like that this is funded by a mathematician turned hedge fund billionaire. :-)</comment>


The Kopp-Etchells Effect - <AUTHOR> http://www.michaelyon-online.com/the-kopp-etchells-effect.htm

<comment><USER2> A couple of theories (static discharge, piezo-electric effect, burning metal) here: <http://www.pprune.org/archive/index.php/t-88213.html></comment>


The iPhone Is 5 Years Old -- How Has It Changed The World? - <AUTHOR> http://www.businessinsider.com/the-iphone-is-5-years-old-2012-6

<comment><USER2> The article points to a lot of crazy facts about the iPhone, but what it does not do is bring an argument to the table that suggests it actually "Changed the World".

Unfortunately the author believes generation of profits and revenues for a rather select group of companies has revolutionized something, or been significant in some way.

We have more and more people that are able to buy tech like the iPhone and Apple has managed to garner a significant portion of that trend. It has pushed Capitalism, Commercialism, and what I like to call "Brand"ism, but it has not been proven to have unto itself done anything significant.

Has Apple through the iPhone reduced the number of hungry in the world, improved global environmental stability (most likely the opposite due to the manufacturing process.), or in any real way done anything altruistic in nature for humanity?

So while it has sold a shit tonne; it has fueled what amounts to probably a 100 billion dollar economy it has not changed anything.</comment>


Soufflé – Logic Defined Static Analysis - <AUTHOR> http://souffle-lang.org/ <comment><USER2> Based on the license this is under (Oracle's UPL) I'd recommend passing over this project until it's relicensed to one of the big 5, like the GPL, or MIT.

</comment><comment><USER3> Several pages on that site refer to an 'EDB' and 'IDB'. What do they mean?

<comment><USER4> I found a definition of EDB on [http://souffle- lang.org/docs/execute/](http://souffle-lang.org/docs/execute/) :

 _The Soufflé permits facts to be sourced from tab-separated input files to separate Datalog programs from their data. In Datalog literature the tab- separated input files can be seen as the extensional database (EDB) of the program._

I assume that IDB refers to the intensional database that allows to derive facts from other facts.</comment></comment>


Steve Perry Walked Away from Journey. A Promise Finally Ended His Silence - <AUTHOR> https://www.nytimes.com/2018/09/05/arts/music/steve-perry-journey-traces-interview.html <comment><USER2> If Perry's new album sounds half as good as his old stuff, it'll be the best album of the year.

</comment><comment><USER3> Cancer is the biggest mothertrucker of all. Fuck cancer.</comment>


Ask HN: How are Unix tools composable? - <AUTHOR> The second rule of UNIX is to make applications that can work with each other. All the stuff I read have to do with using text streams. My question is, even if it's a text stream, don't programs need to parse the text stream to get some semblance of a data structure they can work with? So if it can be any arbitrary text stream, how do they ensure composibility? <comment><USER2> Yes. Read [http://web.mit.edu/~simsong/www/ugh.pdf](http://web.mit.edu/~simsong/www/ugh.pdf) Then read: [http://www.catb.org/esr/writings/taoup/html/](http://www.catb.org/esr/writings/taoup/html/)

You are responsible, as programmer or script writer, to ensure that the data you give to some tool is compatible!

But notice also that the pipe is not the only IPC mechanism available on unix; there are a lot of other ways unix processes can communicate, from shared memory to external files, thru pipes, sockets, semaphores, signals and others. Each of these IPC mechanisms can be used to compose tools, as long as they are designed to use those mechanisms. In all cases, you need to document the specifications of the interfaces and data format.

</comment><comment><USER3> Most of them assume records separated with a record separator (typically \n) and fields separated with a field separator (often a comma, tabs, space.)

That might not be a universal data model, but it is close enough for rock and roll.

If you need more complex data structures than that, take a look at jq.

</comment><comment><USER4> > So if it can be any arbitrary text stream, how do they ensure composibility?

You got the composability thing wrong. The tools are composable because you feed them on STDIN or in command line arguments. You still need to do plenty of work to convert one format to another, and that's what awk, grep, sed, and other tools are for. The only two common (and just _common_ , not _universal_ ) things are to split fields on whitespaces and to split records/entries on newline.</comment>


Bitcoin's Lightning Network Alpha Release - <AUTHOR> http://lightning.community/release/software/lnd/lightning/2017/01/10/lightning-network-daemon-alpha-release/ <comment><AUTHOR> ELI5:

Lightning is a protocol built on top of bitcoin that allows the trustless transfer of Bitcoin without settling to the chain. These transfers don't need to be individually mined and don't take up capacity on the main chain.

The main drawback is that it requires locking up collateral in a "payment channel" between two peers.

IMHO lightning could be the backbone of some interesting micropayments/exchange architecture in the future.</comment>


Build System Rules and Algorithms (2009) [pdf] - <AUTHOR> http://gittup.org/tup/build_system_rules_and_algorithms.pdf <comment><USER2> So many build systems have regressed in that they don't have incremental process built into their core functionality, like Make did. Ant, Maven, Grunt, SBT, Gulp, Gradle...basically everything sucks at this compared to Make. Awful.

But anyone interested in a next generation scalable build tool, check out Google Bazel. [https://bazel.io/](https://bazel.io/) (Ex-Googlers built similar build tools elsewhere -- Buck and Pants -- but I'm most optimistic about Bazel.)

Like Make, Bazel uses incremental tasks at its core. But where Make uses timestamps, Make hashes inputs, allowing for shared caches. It's also been optimized to work with Google-scale build definitions. In beta now, 1.0 planned for end of 2017.

<comment><USER3> What do you mean that Ant/Maven don't have "incremental process"? They don't do incremental builds at all?

There is an additional distinction between "top down" and "bottom up" incremental builds as mentioned in this article about tup.

NEITHER Make or Bazel do bottom up builds. They are top down. That means that incremental builds requires O(n) stat() or hashes. You have to check if ANY input is out of date.

In contrast, tup does O(1) work for incremental builds by using inotify.

In practice, I'm not sure how much this matters, but it is interesting -- and it is the central point of the linked article. Ninja has a reputation for being fast, and it also does top-down builds. As I recall the Linux kernel is quite good at caching inodes for stat() calls, so you can basically stat millions of files in under a second. (Windows may be a different story.)

But if you are using hashes rather than timestamps, the work to check if any of a million files are out of date is much larger.

<comment><AUTHOR> inotify is only available on linux so `tup monitor` doesn't work on all OSes. But other platforms have similar libraries so it's possible to port it.

<comment><USER4> Are there such libraries for Windows? I can't find my notes on this, and all I remember is that `strace` looked the most promising (for a non C programer).

I actually switched from Windows to Linux because of Tup—although to their credit, they have fixed the issues that I filed.

I still use Tup on Windows for production at work, and in place of `tup monitor` I use a service based on .NET's file system watcher, and just tail monitor the log.[0] The config looks like this:

        <job at="%HOME%\some\project">
          <watch>
            <path>script/*.js</path>
            <path>stylus/*</path>
            <path>src/**</path>
            <path>tools/**.cs</path>
          </watch>
          <do>tup --no-environ-check</do>
        </job>

It's not foolproof, since I have to maintain that list, but it's better than the alternatives (whatever they are).

[0] [https://bitbucket.org/gavinpc/reactor/](https://bitbucket.org/gavinpc/reactor/)

<comment><AUTHOR> [https://msdn.microsoft.com/en- us/library/windows/desktop/aa3...](https://msdn.microsoft.com/en- us/library/windows/desktop/aa365465\(v=vs.85\).aspx)

Best I can find. I was referring to kqueue and FSEvent though for free bad and macOS.

Sorry traveling and phone only.

I wonder if the Linux on Windows stuffs will make it easy to use inotify on Windows? I've only heard of it. Haven't researched how that works.

</comment></comment></comment></comment></comment><comment><USER5> I guess the only gripe I have with make is that it has a rigid syntax (that includes tabs). Since what a Makefile eventually is, is a graph, I'd be happy if that graph is specified as a JSON file, which automatically gets converted into a valid Makefile.

Has anyone attempted that approach? simply put a JSON wrapper around make?

<comment><USER6> I agree that Make's syntax isn't ideal, but JSON doesn't seem like a move in the right direction. If you're going to give Make a new syntax, why not pick a more pleasant syntax?

<comment><USER7> Curious what you mean by pleasant. JSON is not really "pretty" but it is simple, and powerful imo. Is it the boilerplate that puts you off?

<comment><USER8> You can use mk, the successor to make, which does not have the TAB requirement (you can use TAB or spaces interchangeably).

Regarding JSON, it is more verbose than Make. You need to use quote around strings, commands, everything. Compare:

foo.o: foo.c gcc -c foo.c

with

{ 'foo.o' => ['foo.c'; 'gcc -c foo.c'] }

<comment><USER9> { "outputs": ["foo.o"], "inputs": ["foo.c"], "command": ["gcc", "-c", "foo.c"] }</comment></comment></comment></comment></comment>


Show HN: Hacker UI – a React design system for developers - <AUTHOR> https://hacker-ui.com/ <comment><AUTHOR> Copied from my reddit post: [https://www.reddit.com/r/reactjs/comments/f3pb73/in_the_past...](https://www.reddit.com/r/reactjs/comments/f3pb73/in_the_past_30_days_i_made_an_open_source_design/?ref=share&ref_source=link)

About a month ago from today, I started working on a design system for my own personal projects. I wanted to create my own design language because the rest of them just felt too complex, too outdated, or too branded (for example Bootstrap is too old, Material UI is too Google-y).

I wanted a design system that wasn't too complicated or special but just something that's unbranded and aesthetically pleasing.

Anyway 30 days from realizing that, I have a design system I'm ready to share!

It's called "Hacker UI" and I'm currently pitching it as "the hacker's go-to design system" (similar to how Bootstrap was a go-to).

Features:

\- 25+ components \- 25+ codesandbox examples \- New CSS-in-JS solution \- Composable styles by default \- Full Typescript support

There's still a lot to be done with this library (optimizations, SSR support, CI and testing, animations etc) but I'm still super excited to share.

Please let me know what you think!

[docs at hacker-ui.com]([https://hacker-ui.com/](https://hacker-ui.com/)) [github repo]([https://github.com/ricokahler/hacker- ui](https://github.com/ricokahler/hacker-ui))

<comment><USER2> Thanks for sharing it! I'm not an expert, but this could use some basic accessibility enhancement. Keyboard navigation doesn't seem to be well supported in your Simple Menu component. When I click to open the Simple Menu, I can't tab around inside the opened menu. When a modal is opened, I can still tab around the rest of the UI (focus should be trapped within it). I highly recommend reading through [https://www.w3.org/TR/wai-aria- practices-1.1/](https://www.w3.org/TR/wai-aria-practices-1.1/). It's an incredibly useful document and is a good starting point.

<comment><AUTHOR> I'll definitely take a look. Thanks for sharing!

</comment></comment></comment><comment><USER3> Looks great!

Reminded me a lot of BaseWeb ([https://baseweb.design/](https://baseweb.design/)) when I first looked at the components. But this looks a bit lighter-weight to use which makes it more accessible IMO.

</comment><comment><USER4> Not the easiest of sites to navigate on mobile, one thing Bootstrap does pretty well. Plans there?

<comment><AUTHOR> definitely! mobile friendly docs are marked very important: [https://github.com/ricokahler/hacker- ui/issues/6](https://github.com/ricokahler/hacker-ui/issues/6)

</comment></comment><comment><USER5> Really nice, do you have any plans to support Vue?

<comment><AUTHOR> In the future I would be very open to the idea but for now I'm trying to keep the scope limited: [https://github.com/ricokahler/hacker- ui/issues/8](https://github.com/ricokahler/hacker-ui/issues/8)

</comment></comment><comment><USER6> This is really cool. Nice work!

</comment><comment><USER7> Great work!</comment>


Ask HN: Use location history to build a predictive rating of Covid-19 potential? - <AUTHOR> I would absolutely be willing to share my location and contact history and even OK with a government agency having taken a copy of my history to build a model to understand current infection potential on a per person basis.  Clearly there's many assumptions to make with regard to contact proximity, virus load, incubation, but as data is gathered with the onset, the backfill can correct assumptions and "clean" the model thus resulting in a model that continues to improve clarity and hone in on people who are likely to be infected.
These people should be prioritized to quickly get tested and then continue running down the list as tests become available.  This seemingly appears to be the only way to get out in front of it.  I do believe lockdown efforts will slow down the spread, but if we can't afford to have every single person take a test within a short period of time, we should be making a very educated guess as to who we should be ensuring aren't infected and if they are, are staying isolated.
Is anyone working on this? <comment><AUTHOR> [https://www.usatoday.com/story/tech/2020/03/18/could-your- ip...](https://www.usatoday.com/story/tech/2020/03/18/could-your-iphone- android-location-data-help-fight-coronavirus-privacy-concerns/2862932001/)</comment>


Secret Huawei enterprise router snoop 'backdoor' was Telnet service - <AUTHOR> https://www.theregister.co.uk/2019/04/30/huawei_enterprise_router_backdoor_is_telnet/ <comment><USER2> I long for the day when security is the default state. I wonder if legislation could help address the never ending stream of things like this.

<comment><USER3> A efficient legislation would be to ban chinese made electronic ... Not sure how realistic this is</comment></comment>


Researchers see health effects across generations from popular weed killer - <AUTHOR> https://medicalxpress.com/news/2019-04-health-effects-popular-weed-killer.html <comment><USER2> This is huge, even though it is a mouse study space we should really be examining glyphosate more carefully given how prevalent it is in our food.</comment>


Elixir – Erlang didn't change, the world did (2017) - <AUTHOR> https://tomjoro.github.io/2017-01-31-world-changed/ <comment><AUTHOR> I'm not a user of Elixir or of Erlang. I stumbled upon this article, and I'm now thinking about giving it a try. The "guns" analogy was an interesting take, and I wanted to hear what HN thought.

<comment><USER2> The author does have a point. Data immutability is nice and it does make your program safer. But that "guns" metaphor is cliché. One may also say that Erlang is more dangerous because it is not statically typed. I don't think crediting/discrediting a language based on simply one language feature is justified. (Actually, Erlang has mutable data too if you use mnesia, ets or the like, but you may just opt not to use them.)

In the article's chart, the author also classifies Go as one of the most dangerous languages. Now I'm a novice Elixir programmer and I don't know Go, but if Go were really so dangerous, I should have heard many horror stories about it (you see, Go is a vastly popular language, much more so than Erlang and Elixir combined). Yet, while you can find a significant number of articles criticising how primitive Go as a language is, those "shoot yourself in the foot" type of complaints are surprisingly few (especially if you compare the situation with C or C++). I think this tells us something about Go's safeness.

And he says that "To an Erlang programmer Haskell is an impractical language". I wonder how many Erlang programmers out there would be so snobbish. I have only dabbled with Haskell, but my impression is that Haskell is an unbelievably clean language (at least when compared to OCaml or Elixir), to a point that if I write a Haskell program, I would be very confident that what I've written is exactly what I intended in mind. How is that impractical?

If you really want to see some in-depth discussions about Erlang, I recommend the following two interviews:

1\. Joe Armstrong and Simon Peyton Jones discuss Erlang and Haskell ([https://www.infoq.com/interviews/armstrong-peyton-jones- erla...](https://www.infoq.com/interviews/armstrong-peyton-jones-erlang- haskell))

2\. Ralph Johnson, Joe Armstrong on the State of OOP ([https://www.infoq.com/interviews/johnson-armstrong- oop](https://www.infoq.com/interviews/johnson-armstrong-oop))</comment></comment>


Thompson, Ritchie and Kernighan admit that Unix was a prank (1989) - <AUTHOR> http://www.stokely.com/lighter.side/unix.prank.html <comment><USER2> I'll always remember a backhanded remark Mary Shaw ([https://www.isri.cmu.edu/people/core-faculty/shaw- mary.html](https://www.isri.cmu.edu/people/core-faculty/shaw-mary.html)) made about AT&T Bell Labs at a talk she gave about Computer Architecture as the "New Jersey School of Computation."

</comment><comment><USER3> This looks like a good place to link the Unix Hater's Handbook[1]

[1] [https://web.mit.edu/~simsong/www/ugh.pdf](https://web.mit.edu/~simsong/www/ugh.pdf)

<comment><USER4> 360 pages?!

<comment><USER5> It's Volume 1.

</comment></comment></comment><comment><USER6> The copyright on the page says 2013, but I think this was actually written in 1989 ("20 years ago", "1969")

<comment><USER6> also really classy to put their own copyright notice on a document "found on usenet and the author could not be determined"

<comment><USER4> probably just a standard footer that wraps everything

<comment><USER6> Yeah, probably, but that still doesn't make it right.

</comment></comment></comment></comment><comment> java-man "At one time, we joked about selling this to the Soviets to set their computer science progress back 20 or more years."

Hilarious. Ended up selling it to everybody.

But seriously, given the long history of failures (i.e. search CVE database for buffer overflow), this joke does read like a true story.

</comment><comment><USER7> > This piece was found on Usenet. This is fiction, not reality. Always > remember that this is not true. It's really a joke, right? -- Editor

<comment><USER4> Nah, I refuse to believe it. Death to the author. Poe's Law and all that.

</comment></comment><comment><USER8> "Two of the most famous products of Berkeley are LSD and Unix. I don't think that is a coincidence."

Nice. Does this mean to be a successful Unix Admin you also need to be an accomplished psychonaut?

</comment><comment><USER9> >Dennis Ritchie said: "What really tore it (just when ADA was catching on), was that Bjarne Stroustrup caught onto our joke

Lol.</comment>


When will people realize that ideas aren't as important as they believe? - <AUTHOR> http://washingtondc.craigslist.org/nva/cpg/1746825290.html

<comment><USER2> He's a marine. So maybe he knows certain niches very well and may have some interesting ideas that regular hackers don't have? Who knows.

<comment><USER3> Still its absurd to assume someone is going to make your entire idea for you for free in exchange for vague promises of compensation if it becomes big.

<comment><USER4> Well, you can talk to him and make it clear you're only in if you get a _significant_ piece of the action. He's not likely to find anyone good on other terms, and in the discussion you should be able to figure out if you want to work with him at all.

</comment></comment></comment><comment><USER5> These kinds of postings MUST be fake.</comment>


China is paying Twitter to publish propaganda against Hong Kong protesters - <AUTHOR> https://thenextweb.com/twitter/2019/08/19/china-is-paying-twitter-to-publish-propaganda-against-hong-kong-protesters/ <comment><USER2> Previous discussion here:

[https://news.ycombinator.com/item?id=20734808](https://news.ycombinator.com/item?id=20734808)

</comment><comment><USER3> As does everyone who buys ads.

<comment><USER4> Maybe we can agree that propaganda used to get someone to buy Pepsi over Coke isn't exactly the same as pushing a political agenda?</comment></comment>


Tell Google: Don't show me ads for cat food - <AUTHOR> Dear Google, you can see every photo I've taken in the last 2 years - only one photo is of a cat. Furthermore you can see from my location history that I never go to the pet food isle of my supermarket.<p>From this you should know I don't have a cat. So why do you show me YouTube ads for cat food? <comment><USER2> They know that the cat food people were willing to pay the most to show you that ad, and that's all that matters.</comment>


Tell HN: HN Search isn't indexing anything newer than 5 days old - <AUTHOR>

Not much to say really but for all popular keywords I've just tried the newest item is 5 days old. And none of the current front page items seem to be visible either.
For example, there are posts about Ruby almost every day, but..
http://www.hnsearch.com/search#request/submissions&q=ruby&sortby=create_ts+desc&start=0 <comment><USER2> Sorry guys - one of the parsing scripts died and didn't get restarted automatically. Normally we would have noticed the problem earlier but we've been away at a conference this past week. The script is back up and the index should be up-to-date within the hour.

</comment><comment><USER3> I would also like to add that it only does exact string matching. HN could use a better algorithm. The search could, say, even crawl the website linked. That would make HNsearch a much more powerful search engine, its advantage being the huge amount of vote data collected from an awesome community. Instead of Google's back-link information, instead of Aardvark's social graph nearness algorithm, HNsearch could be a search based in the level of intellect contained in the links, and discussions. All it needs is some sophistication in the algorithm, maybe some LSA, LCS, etc...

<comment><USER4> I don't understand why hn needs its own search engine. What are the advantages of using hnsearch compared to using google with 'site:news.ycombinator.com'?

<comment><USER5> ...because Google doesn't offer site specific options such as sort by date/points?

<comment><USER6> Google do offer sort by date but it doesn't work terribly well IME.

You could also do a rough number range search ("100..1000") that might help capture higher value comments but in practice is probably too rough to be useful.

</comment></comment></comment></comment><comment><AUTHOR> This is probably a good time to give my thanks and appreciation to HN Search, however. I use it a lot and it's a very useful tool. I appreciate whoever does all the work on it.

Feel free to leave similar comments as it might give someone a smile while they're being hassled to fix this over Thanksgiving.. ;-)

</comment><comment><USER7> I asked the Octoparts.

<comment><AUTHOR> Thanks, I did e-mail and tweet the @HNSearch account as well but thought it'd probably do better here.. :-)

</comment></comment><comment><USER8> Maybe it mimics twitter in this behavior? What is now is the only relevant stuff. Present doesn't see beyond 5 days time horizon.

<comment><USER9> Well, actually it seems that HN search has taken the opposite approach ( _NOT_ indexing new items).

</comment></comment><comment><AUTHOR> This has now been resolved! Thanks everyone involved :-)</comment>


Y Combinator W15 March Madness Bracket - <AUTHOR> https://www.youtube.com/watch?v=Gfdi-9y56QA

<comment><USER2> This show has improving so much.

<comment><AUTHOR> Thanks! I'm the guy on the right and this is my first youtube show. Suggestions and constructive feedback appreciated. (There's also an anonymous feedback form linked in the youtube comments.)</comment></comment>


Privacy versus Efficiency - <AUTHOR> http://dilbert.com/blog/entry/privacy_versus_efficiency/ <comment><USER3> Scott Adams imagines a future in which the end-user is reaping all the benefits of modern technology. But the end-user is the weakest link the chain. That world could only come about with heavy government regulation. The technological surplus is far more likely to be skimmed off at another point in the chain.

More likely is a world where your smartphone broadcasts your location and identity at any given moment... and Verizon gets paid a great deal of money by marketers for access to that information, and you can't turn it off (sorry sir, it's standard on all Verizon phones, and after they bought AT&T, there's not too many other carriers left). Your phone dings fairly often as you walk around with coupons for 25 cents off at the nearest Starbucks - <USER2> the "silent" setting doesn't silence these dings. The NSA is rumored to store everyone's location, forever, and be cross-indexing terrorists, liberals and other enemies of the state to see if they have EVER been in the same location as each other.

The new Verizon Wing of the Capitol building is renowned throughout the world for its excellent design and tasteful branding. After all, Verizon knows where legislators go in their time off, too.</comment>