Isofarro

Oh hello, it's by Damien Katz. Who did CouchDb, and yonks ago worked on the storage engine underneath Lotus Notes.

Thinking of it as an app install feels like an anti-pattern. Like when you turn on the Xbox for a quick five minute play, and have to sit through a 15 minute update before you can even do anything. It's a bad user experience.

This approach was a commercial failure on the native platform level (those Office-like app suites with network install of components each time you needed them). It was also a commercial failure on the "build my desktop from scratch when I boot up" environments.

It yet another tick in the "does not belong in a browser" list.

Perhaps Single Page Applications need to run inside a window where there's no browser navigation bar, no url bar. Stripped down so far it's not actually a functioning browser. That feels very much like a native GUI library at that point. Except for that ludicrous notion of the app needing to be installed each time the chrome/window is launched.

I can't see how "install the app each time you land on this website" is competitive against native's "install this app once, and run many times" approach.

I'm not convinced that introducing the limitations of native apps to a non-native platform is a benefit, or a feature that makes the non-native platform more competitive.

Out of the browser navigation facilities, the back button is the best understood feature. Users know how to use it, and what it should do.

Perhaps, where this goes is that Single Page Apps and web browsers aren't a good fit together?

Yoiks. 12 seconds until the first piece of content is displayed (compared to Wikipedia's 0.6s). That there (TTFC - Time to first content) is the perennial problem of client-side apps, the inability to get the first piece of content immediately to the user.

Since you say it's all JSON APIs, it should be trivial to build something on the server to server-render the initial page with content and serve that up while the rest of the application tries to download itself into the browser.

Probably positions stemming from the Botvinnik variation of the Semi-slav. Conventional chess wisdom doesn't really help, and figuring a way forward is pure calculation.

Then also, maybe lines of the "Irrational system" of the French Defence, Winawer variation (lines of Qg4, and Black sacrificing both g7 and h7 pawns).

Playing with nuances about what "complicated" means, perhaps also Nimzowitsch's "Immortal Zugzwang" game, where White is absolutely helpless on an almost full board of pieces.

The difference is that the positional sacrifice is less tangible. A space advantage, a tempo advantage, more mobile pieces, improved cohesion/coordination of pieces (Kasparov was legendary for taking this last kind of advantage and turning it into a lethal attack). It's a dynamic advantage rather than a static/permanent advantage, which also means there's a risk of that advantage dissipating as the game drags on.

These advantages aren't the kind where you can sit back and let the game play out confident of winning. It's a deliberate unbalancing of the equilibrium of the position, and one where this temporary dynamic advantage needs to be used to create a longer-lasting and static advantage.

Perhaps the positional sacrifice can be identified by similar means. The most superficial measurement of a position is the material left on the board. So when you compare the superficial measurement to a deeper positional measurement and they are divergent, then we have something positional.

I think one of Kasparov's games against Karpov in the New York portion of one of their World Championship matches involved Kasparov sacrificing a queen for positional compensation on the black side of a King's Indian. It would be interesting to see what this project thinks of that game.

All things being equal, yes women would have the upper hand.

But cultural norms warp things a little more. The cultural tendency is for a man to marry down, and a women marry up in social level terms.

Which means there's a layer of women near the top who can't find a husband. Particularly in professional careers. And the lowest social rung of men have no women to marry down.

This asymmetry means there's a band of powerful and successful women who don't normally find husbands. They become China's "leftover women", who have basically given up on the idea of marriage beyond the age of 27. One recent solution here is these women look abroad for suitable husbands. Despite being negged annually, the social stigma of not marrying up takes many options away from women.

During my time working for Yahoo Europe, I refused to patent the ideas I presented in Yahoo's internal hack days. It was retro-actively declared as the way to encourage us to participate in internal HackDays. So I also stopped participating. Today, I'm satisfied I made the right call.

The Bollea v Gawker case itself is already a counter-argument to your suggested fix.

What would have been different if it was known upfront Bollea had third party funding and was willing to use it? The facts of the dispute haven't changed, so the end result should not have changed.

The main effect is that Gawker may have changed their approach to defending/settling the case. Which is a good argument not to disclose how the applicants are funded.

"Anyone seriously installing a software package using a developer tool without knowing anything other than the package's name is a fool."

That includes the projects that had left-pad as a dependency.

It isn't a threat though, the company has no choice but to enforce their trademark when they see it infringed. Otherwise they lose the right to that trademark. That's the mess trademark law is in, fail to enforce it once, and that will risk any future trademark action.

Try it with just site:scripting.com

Is mirror.scripting.com really the most important page on scripting.com (and it's currently unavailable). That's what's turning up as the top result, more important than the scripting.com homepage.

I've been watching the Google SERPS view of his website tank since he switched to his JavaScript stack a few months ago.

It's a eye-watering example of what happens switching from a static website to a client-side generated one. There's basically nothing on the first page of a site:scripting.com search anymore.

Even the Google Sitelinks view lists the RSS feed as the most important page after the homepage.

It parallels that the majority of UK government initiatives into startups involve or are sponsored by Google, Facebook and Apple. Seems antithetical.

Since you've done PHP and MySQL previously, if you still remember how to use that, it's worth starting with a simple PHP micro framework (like Slim, or maybe Symfony 3). That will teach you about using URLs for routing. (If starting from scratch, pick a language, and pick a micro framework for it: Ruby => Sinatra, Python => Flask)

Get comfortable with that, and then create a route that sends back information in JSON instead of HTML. That will then give you something to try Ajax against.

Also, learn CSS. The Web switched to CSS for layout in 2001-2004. Have a read through 24ways.org -- their advent calendar for each year, it's nice bit size bits about modern web development. CSS for layout. Responsive design (basically adapting to various browser window sizes and screen resolutions). If you want to learn how to lay out a page in CSS this is essential, but if you want to get up to speed just building stuff, then taking something like Twitter's Bootstrap is a handy starting point.

Also, jQuery. Learn about using events properly, and keeping JavaScript in a separate file and hooking into the browser/document events you are interested in. jQuery is the starting point for getting your head around Unobtrusive JavaScript.

If you are interested in getting your head around static HTML/CSS sites first, it might be worth pulling up a Jekyll tutorial and following that. (Jekyll is a static site generator. Markdown documents rendered as static HTML using the Liquid tempting language)

Yahoo Europe's progress was from Perl generated static html, to Perl generated PHP.

What Rasmus' hire did was push Yahoo to allow server-side scripting languages on the web server. And that's where PHP was the blindingly obvious choice. (though, I would not be surprised if there was a bun-fight with mod_perl...)

It's a side-effect of cultural norms going back thousands of years. In marriage, status is a key factor, and the parents of both partners are the main decision maker whether to allow a marriage or not. Status wise: A man marries a women of lower status, a woman marries a man of higher status -- that's more likely to be approved by both sets of parents. (And parental approval is important in Chinese families)

Which means, there's talented, very smart women in China who are struggling to find suitable husbands, because they are equal to high status men. And those men are looking for women with less status.

The Male leftovers tend to then be at the bottom of the status chain, because there's no lower status of women to marry. So there are loads of rural areas and villages where women have moved to the city, and men remaining have no viable marriage prospects. (This is the segment negatively affected by one-child policy)

I bought a bunch of cassette tapes earlier this year from Tapeline (tapeline.info). Based in Stockport, Cheshire, UK. Bought both custom-length blank cassettes (for replacing broken ZX Spectrum game cassette tapes), and cassette boxes (single and jewel case).

Top-tier devs just give you skill and experience; that in itself doesn't give you passion.

What you consider an act of desperation, DuckDuckGo sees as an act of passion and strong interest. If a skilled developer values his time more than his passion, perhaps that isn't a good fit for DuckDuckGo.

Desperate people can apply, but they must be able to prove they have the technical capacity to deliver too. Which means they need to meet the calibre of developers who are in high demand, which means perhaps they aren't desperate?

This process doesn't look much different to participating in an open source project in your own time, and then after your contributions have been assessed a decision/invitation extended to be part of the Core Team. Except that invitation is also an employment contract with a salary.

By having the app running on the server it can take advantage of being primed before the first request arrives. Primed in that the app is already running, and/or the data retrieved is cached and regularly refreshed.

Depending on the nature of the application, if it's largely not client personalised (a content site like Bustle, as opposed to a Gmail client), one instance of the app on the server can respond to multiple client requests in it's lifespan. So basically it's an already spun up ready to go instance of the app, or already processed, just needs to squirt the HTML buffer at a response object.

So they are building a server-side app to deliver a usable first-load experience with HTML and CSS, while the JavaScript loads in and runs, and until the JavaScript runs, all the links work like normal anchors.

Sounds like Progressive enhancement [1].

[1] http://tomdale.net/2013/09/progressive-enhancement-is-dead/

As far as I can tell, working in the AWS teams is perhaps the best software engineering place to be at Amazon (e.g. note Tim Bray's joining the Vancouver office.). The positivity from there I've seen echoed by other diverse sources, so unlikely to be just kool aid.

Everywhere else, stay away, unless it is something you have a very very strong passion for. (Perhaps the Games teams might be another AWS like atmosphere in the making, hard to say yet). Don't get bait-and-switched with AWS buzzwords, make sure it is AWS doing the hiring.

From my experience working for Amazon, they seem to grind engineers down, so they are regularly churning through a constant supply of graduates to keep employee numbers up. So a large chunk of engineering is new to 2 years.

Stack Ranking (the cross-over of staff between Amazon and Microsoft in Seattle means the same people drawing up employee performance processes. They may insist it isn't stack ranking, but looking at how the review process works is inescapable that the nastiness of stack ranking is present)

Edit: there are a handful of genuinely good engineering teams at Amazon, but their ability to make a positive impact is tainted by the volume of garbage that surrounds them.

I learned a few languages in school: French, Afrikaans, Xhosa, South Sotho. Been learning Mandarin on my own over the past year (using Pimsleur).

The main difference is the tonal system, reading it it sounds easy, but training your ear to pick it up takes time. It's hard to follow an audio when you're not picking up the nuances of the tones in context.

The language structure is kinda logical, so far. I haven't reached tenses or multiple clauses yet.

I found some pronunciation similar to French, for me ren (Zh: people) is similar sounding to rien (Fr: nothing)

I'd be wary of touching any Yahoo API that isn't a core part of their business. Developer enthusiasm isn't enough considering how likely, when Yahoo run into difficulties, they'll just sunset APIs we're using.

I want to say the Search API is a good example of a core business proposition: there's a revenue stream there for the service, but the search results are probably from Bing, so although the Yahoo side looks like it has longevity, the reliance and licensing of search metadata from Microsoft is a dependency that ups the risk of using this API. I don't really trust Microsoft not to pull the carpet out from under us when they've collected a sufficient number of eyeballs to consider the second step of a bait and switch.

It doesn't need to be called "Markdown" to justify what they've invested their time in over the last few years. Changing to a non-Markdown name doesn't invalidate their 2-year effort of creating a spec, unit tests and implementation of a human-readable text format that can be rendered as HTML. A name change doesn't change the fundamental and substantial part of their work.

That's why they don't even need to call it Markdown. It can be a markdown derivative with a different name and it would still be as successful because they have the mindshare and the beginnings of a collaborative community.

""Github Flavored Markdown" is a thing, has been for a very long time. Not a peep from Gruber about it."

In the podcast John Gruber did with Marco Arment ( https://overcast.fm/podcasts/episode/344902019595#t=4527 ), John Gruber notes "Github Flavoured Markdown" is a good product name.

He also says that they should standardise using a different name.