wldlyinaccurate

Agreed! Glad you mentioned the image fade-in. I was actually speaking to our UX team about it the other day, and I think we might get rid of it \o/

Some of these old Eastern Bloc countries have had fascinating changes in language and written script in the last hundreds years or so. Uzbekistan is another interesting one, which currently uses Cyrillic, Latin, and Arabic (actually Nastaleeq) scripts despite Latin being the official script since the 90's. I had a really fun time building the BBC Uzbek website which had to support all of these:

- http://www.bbc.com/uzbek (Cyrillic)

- http://www.bbc.com/uzbek/lotin (Latin)

- http://www.bbc.com/uzbek/afghanistan (Arabic)

I don't mean to detract from the great back-end time that you've managed to achieve, but I think it's important to point out that web performance is about _so_ much more than the back-end.

Using WebPagetest, you can test your page with real devices to get an idea of how it will load for users who are not on overpowered desktop devices hooked up to the Internet over a fibre connection. If you look at the "Filmstrip view" for futureclaw[0], you don't even see any text until ~4.7 seconds in, and the page doesn't look finished until well after 13 seconds because that image takes so long to come in. Hacker News, on the other hand, has content visible at 2.3 seconds[1].

So yes, back-end times are important. But it's a small slice of the overall load time. Just keep in mind that the proportion of people on mobile connections is actually going _up_ in the developed world, and the average speed of mobile connections is not improving. It's really important that we (web developers) recognise this and build sites that can be used by everyone, no matter the speed of their device or connection.

[0] https://www.webpagetest.org/result/161224_TS_264/ [1] https://www.webpagetest.org/result/161224_H9_26Z/

Am I missing something here? What about bread, cheese, and tomatoes? Even the Strawberries/Chocolate/Brie example in the article would not sound horrible to some people — I've had chocolate with cheese on many occasions.

Cool, I'm glad to see there's a meta issue to track this stuff now. Couple of questions:

Is there a strategy to tackle the CSS and JS bloat?

Is performance something the front-end endboss folk consider important enough to delay feature releases?

Are you monitoring performance with a tool like SpeedCurve?

You only need to look at a DevTools timeline to see that it's the front-end which is slow: https://www.webpagetest.org/result/161021_08_XZF/

600KB of CSS, 800KB of JS... That's fine on your MBP over WiFi but on most pages it locks up the main thread on my phone for a good 5-10 seconds.

It's not as simple as that. Lodash is a great example of why the highlander rule doesn't work within the npm ecosystem: older versions are depended on by many widely-used packages which are now "complete" or abandoned. Refusing to use any packages which depend on the latest version of Lodash is just not practical.

I know that this type of functionality is useful, but please consider the performance implications before doing anything like this. Non-native implementations (i.e. not IntersectionObserver) _always_ use properties and methods that cause style and layout calculations which have a significant performance impact on low-powered devices.

A more comprehensive list is here[1], but the main culprits are HTMLElement.offset{Width,Height}, Element.client{Width,Height}, and Window.getComputedStyle(). Avoid these, _especially_ on events like scroll. You will ruin the experience for many of your users.

[1] https://gist.github.com/paulirish/5d52fb081b3570c81e3a

I personally find this "railway" approach (which is essentially a glorified Either) much less painful than dealing with exceptions.

Did you really find the example imperative error handling code more elegant than the railway-style function composition?

> It's really helped us distinguish developers who see work as a 9-5 job that they only do because they must and those developers who just love solving problems.

The two aren't mutually exclusive. Many (most, even) of the best developers I know will come to work at 9am, be super-productive for 8 hours, and then completely switch out of Developer Mode at 5pm. It's entirely feasible for somebody to be extremely passionate about programming and learning and problem solving and all the other things that we associate with "good" developers without them doing any sort of work in their own time.

Developers are people, too. They have families, friends, hobbies, and other things that are more important than your 2-3 hour coding test. You are alienating a large number of people by asserting that the ones who complete your coding test are "distinguished". You are also seriously reducing the size of your talent pool whenever you want to hire somebody.

"These requirements were crafted such that we don't expect you to finish" is exactly how we explain our coding tests to candidates, and it seems to work really well. We actually find that many candidates will spend their own time finishing the project _after_ the interview. Programmers do like a challenge, after all, and nothing says "challenge" like "we don't expect you to finish this".

If this kind of approach to learning Git interests you, I took a similar approach with A Hacker's Guide To Git (https://wildlyinaccurate.com/a-hackers-guide-to-git/). It is much longer and goes into a bit more detail than the OP but (hopefully) is arranged in a way that you can read it a few sections at a time.

Protip: ?w=1 on GitHub is synonymous with git-diff's -w flag.

I'm really disappointed to see this happening. Studying computer science in Christchurch, New Zealand made Jade Software a well-known name to me. They've never been a modern or progressive company, but I used to respect them for their successes. Now I just feel like they're letting themselves and a big OSS community down with this petty trademark dispute.

Bad form, Jade.

Jade Software are a New Zealand-based company. They've been around for decades.

Make sure you are connecting the 5V power supply to the PWR IN port, not the USB port.

You're right that your (very contrived) examples are different. But if anybody on my team writes code like this, it doesn't pass code review.

This reminded me of Wraith, a screenshot comparison tool which The BBC developed for integration testing: https://github.com/bbc-news/wraith

I've found that Sourceforge is still the only place you can get a lot of good-but-unmaintained software. I was there just the other week for the Saxon project[1], and it was painful to see how low SF have sunk.

I wonder if it would be possible (and legal) for somebody who isn't the project owner to copy some of these unmaintained projects into another system?

[1] http://sourceforge.net/projects/saxon/

If you have never touched Haskell before, I would recommend reading the first 4 chapters of Learn You a Haskell[0] first. LYAH has a much more gentle introduction to Haskell, and really helped me grasp the basics.

After those chapters I would highly recommend working through Write Youself a Scheme, using LYAH as a reference when you need a more in-depth explanation of something. This is how I taught myself Haskell, but I realise that this approach might not work for everybody -- YMMV.

[0] http://learnyouahaskell.com/chapters

I find it helps to browse popular user packages: https://packagecontrol.io/browse/popular

Most of the productivity gains I get from Sublime are from packages like Emmet, DocBlockr and my own custom macros.

I don't really understand what you're trying to convey. You cite many scenarios where you could die going about your everyday life, but then criticize free soloing as being significantly more risky and "reckless".

The major difference between getting into a car accident and taking a fall while free soloing is that while free soloing, you are in control of nearly all of the risk factors. Free soloing routes that are beyond your capabilities, or climbing in bad weather -- that is reckless. Free soloing routes which you have practiced many times with protection -- to me, that's less reckless than cycling to work during rush hour.

From the Epic Scale website (http://www.epicscale.com/):

How is money earned?

Solving math problems for weather prediction, physics simulations, cryptography (including cryptocurrency mining) and more has real world value. We solve these problems on behalf of our trusted partners, and donate proceeds to your favorite charities.

The key words there being including cryptocurrency mining.

This is really interesting, and a great approach to testing. I wonder if other JS engines like V8 are using this or something similar?

Yeah, I think the high resale value only applies to previous-generation machines. Basically, for a couple hundred dollars each year (plus the hassle of using eBay) you can upgrade to a brand-new machine.

I own a 2014 XPS 13 and I absolutely love it, but my next machine will be a Macbook. The reason is pretty simple: resale value. Upgrading to the latest and greatest Macbook is absurdly cheap since you can sell your old model for close to the original price. Whereas I'll be lucky to get half of what I paid for my XPS 13.

I have the 2014 XPS developer edition and can get 10 hours with modest screen brightness. I get even more if I use a minimal WM like i3.

I find the two things that can really eat up the battery are screen brightness and having a poor Wi-Fi connection.

Sorry, I've just realised how snarky my comment came off as.

I guess the point I was trying to make is that a huge portion of Git users don't actually need Git; they would probably get everything they need from a conceptually simpler VCS like Mercurial or SVN.

Regarding the DAG thing, this is just because that's essentially how Git actually represents the objects which it stores, which represent your repository and its history. A lot of the time I'm in the mindset of "committing some code to a branch" but sometimes it's useful for me to get into DAG-mode so that I can more easily think about how I want my repository to be structured.

An example is how I work with my master branch, which I consider to be the absolute source of truth for a repository's history. This means that it should be full of complete, atomic commits which are ordered in a way that enables me to do things like git-bisect (for finding bugs), generate meaningful release logs, and just generally understand the history at a glance. So rather than just blindly merge my branches into master, I spend a lot of time using git-rebase to squash, re-order, and edit my commits. I find it easier to do this when I'm thinking in terms of a DAG, rather than some abstract concept of a "commit" (whatever that is).

I understand the sentiment, but Git is hardly meant to be a simple tool that anybody can pick up and use without any prior experience. I don't use Git just to version and share my code -- I'd use Dropbox if that were the case. No, I use Git because I want to perform complex operations on a directed acyclic graph which represents the history and structure of my project. I use it because it can be interacted with in a programmatic way, and extended to meet my needs. Git is supposed to be complicated, and you do need "Git skills" to use it properly.

Really great screencast. If you have the good fortune to be a JS developer in 2015 (and beyond), there are some exciting times ahead!