Don't Be a Dick - <AUTHOR> http://betterelevation.com/2011/06/13/dont-be-a-dick/

<comment><USER2> If you introduce yourself as a model (of any gender), and then tell someone that you don't recognize the Bottlerocket logo, you will identify with a different demographic. It's important to note that the guy was not dismissive, as in "You're a woman, therefore you wouldn't understand this." It was a recognition that practically nobody knows who John Gruber is.

</comment><comment><USER3> You know - there is another very good reason why you don't want to be a dick to people. Because interestingly enough - people who are into power games and ego just won't respect you, and after they've had their fun making you feel small, they'll likely avoid and ignore you.

If you're consistent enough in not being a dick, eventually those that remain around you will also not be dicks and your life overall will be much more pleasant.

The dicks deserve one another - and more often than not, that's exactly what they will receive.

</comment><comment><USER4> OK- but what about this childlike behavior from Jim Dalrymple to the author of the ZDNet article?

 _Phone in my hand, a gentleman named Jim Dalrymple turned to me and says loudly, "Hey, what phone is that?"

I respond, It's an Android, Samsung-

Before I finish he shouts at me, "Sucks for you!" Laughing, he turns, and then walks away as I'm saying to the men looking embarrassed in his stead_

Seriously? And people wonder why conferences are huge sausagefests.

<comment><USER5> From the article:

"Ed note: Dalrymple has a different account. He said that his laugh was in relation to another comment—about hockey—and he didn't walk out first. His comments regarding Android at WWDC had nothing to do with Blue being female."

Not saying one is right and the other is wrong, just pointing out that there were two different accounts of the exchange.

Also, if someone said that to me I wouldn't want to attend the event either, regardless of my gender. This is not excluding women from tech, this is excluding _nice people_. Either way it needs to change, but it seems unnecessary to bring gender into this (assuming, of course, that he would have made the same comment to someone of a different gender).

</comment></comment><comment><USER6> Wow. It's the sort of rubbish that I'd expect to see on The Register. ZDNet is the National Enquirer of the IT and computing blogosphere I suppose.</comment>


% Stack Overflow Questions Answered in 2016, by Type of Technology - <AUTHOR> https://docs.google.com/spreadsheets/d/1QlXayFZYGb2U_2OrFDv416ZaayuysS_fT31IDvt843o/edit?usp=sharing <comment><AUTHOR> Query was adapted from examples:

       #standardSQL
       SELECT tag, COUNT(*) num_questions, ROUND(SUM(IF(answer_count > 0, 1, 0)) / COUNT(*), 3) perc_answered
       FROM (
         SELECT SPLIT(tags, '|') tags, answer_count
         FROM `bigquery-public-data.stackoverflow.posts_questions` a
         WHERE EXTRACT(YEAR FROM creation_date) = 2016
       ), UNNEST(tags) tag
       GROUP BY tag
       ORDER BY num_questions DESC
       LIMIT 1000</comment>


Announcing Git Large File Storage - <AUTHOR> https://github.com/blog/1986-announcing-git-large-file-storage-lfs <comment><USER2> I'm sure GitHub did their due diligence before starting to work on this, but I can't lie: it bums me out a bit that they didn't find git-bigstore [1] (a project I wrote about 2 years ago) before they started, since it works in almost the exact same way. Three-line pointer files, smudge and clean filters, use of .gitattributes for which files to sync, and remote service integration.

Compare "Git Large File Storage"'s file spec:

        version https://git-lfs.github.com/spec/v1
        oid sha256:4d7a214614ab2935c943f9e0ff69d22eadbb8f32b1258daaa5e2ca24d17e2393
        size 12345

And bigstore's:

        bigstore
        sha256
        96e31e44688cee1b0a56922aff173f7fd900440f

Bigstore has the added benefit of keeping track of file upload / download history _entirely in Git_, using Git notes (an otherwise not-so-useful feature). Additionally, Bigstore is also _not_ tied to any specific service. There are built-in hooks to Amazon S3, Google Cloud Storage, and Rackspace.

Congrats to GitHub, but this leaves a sour taste in my mouth. FWIW, contributions are still welcome! And I hope there is still a future for bigstore.

[1]: [https://github.com/lionheart/git- bigstore](https://github.com/lionheart/git-bigstore)

<comment><USER3> Looks like you wrote git-bigstore a few months after I wrote git-fat (also Python and a similar design; partially inspired by git-media). It would be interesting to do some performance comparisons and merge our capabilities, perhaps with support for each other's stub formats if we can do it in a compatible way.

<comment><USER4> It's also somewhat notable to mention that git-media was written by one of the founders of GitHub. So...that may be why? :)

</comment></comment></comment><comment><USER5> It's interesting that this uses smudge/clean filters. When I considered using those for git-annex, I noticed that the smudge and clean filters both had to consume the entire content of the file from stdin. Which means that eg, git status will need to feed all the large files in your work tree into git-lfs's smudge filter.

I'm interested to see how this scales. My feeling when I looked at it was that it was not sufficiently scalable without improving the smudge/clean filter interface. I mentioned this to the git devs at the time and even tried to develop a patch, but AFAICS, nothing yet.

Details: <[https://git-annex.branchable.com/todo/smudge>](https://git- annex.branchable.com/todo/smudge>)

<comment><USER3> As the author of git-fat, I have to say the smudge/clean filter approach is a hack for large files and the performance is not good for a lot of use cases. The reality is that it's common to need fine-grained control over what files are really present in the repository, when they are cached locally, and when they are fetched over the network. Git-annex does better than the smudge/clean tools (git-fat, git-media, git-lfs) but at somewhat increased complexity. I think our tools have stepped over the line of "as simple as possible but no simpler" and cut ourselves off from a lot of use cases. Unfortunately, it's hard for people to evaluate whether these tools are a good fit now and in a couple years.

As for git-lfs relative to git-fat: (1) the Go implementation is probably sensible because Python startup time is very slow, (2) git-lfs needs server- side support so administration and security is more complicated, (3) git-lfs appears to be quite opinionated about when files are transferred and inflated in the working tree. The last point may severely limit ability to work offline/on slow networks and may cause interactive response time to be unacceptable. Some details of the implementation are different and I'd be curious to see performance comparisons among all of our tools.

<comment><USER5> Thanks for verifying my somewhat out of date guesses about smudge performance!

Re the python startup time, this is particularly important for smudge/clean filters because git execs the command once per file that's being checked out (for example). I suppose even go/haskell would be a little too slow starting when checking out something like the 100k file repos some git-annex users have. ;)

<comment><USER6> Ok, that means I don't have to check out git-lfs, git-fat or git-bigstore. My annex is 250k symlinks pointing to 250 GiB of data. It's slow enough as it is.

<comment><USER5> At 250k files in one branch, you are starting to run into other scalability limits in git too, like the innefficient method it uses to update .git/index (rewriting the whole thing).

<comment><USER7> There is the new "split-index" mode to avoid this (see "git update-index" man page). The base index will contains 250k files but .git/index only contains entries you update, should be a lot fewer than 250k files.

<comment><USER8> It seems that `--split-index` is only available at 'update-index'. Can it be used with `add` or via `git config`?

</comment></comment></comment></comment></comment></comment></comment><comment><USER9> This looks like it misses the mark a bit.

As anyone who's worked on project with large binary files(the docs assume PSDs) you need to be able to lock unmergeable binary assets. Otherwise you get two people touching the same file and someone has to destroy their changes. That never makes anyone happy.

It's also unseen how good the disk performance is. These two areas are the reason why Perforce is still my go-to solution for large binary files.

<comment><USER10> That's an interesting point I hadn't considered before. Git, as a _distributed_ vcs, takes the position that everyone can edit all files, and rare conflicts can be managed easily because changes are relatively small and diffable.

But these assumptions break down with binary assets. Changes are _not_ small, they typically change entire files at once. They're also not diffable. As a result, conflicts are not rare, they're _common_ , and impossible to resolve for both parties. That's why locking or "checking out" certain files is a needed feature, so changes are ordered strictly linearly -- a graph structure doesn't work.

<comment><USER11> > They're also not diffable.

I think that really is a problem with the diff tools, not the format itself. This is why both Mercurial and git allow you to pick special diff and merge tools per filename extension.

<comment><USER10> Most binary assets are compressed. Diff tools can't work with compressed assets; you'll have to decompress before diffing. Sometimes they also include checksum information which would invalidate any attempt to merge.

How far do you take the decompression? For raster images, you'll probably have to decompress all the way to bitmap because the same image could have multiple completely different binary representations in a format like png.

How do you diff changes? If we have a raster image and one person changes one thing by a small amount, say increases brightness 1%, this could alter every pixel of the image! How would you detect that change and interleave it with something like a contrast adjustment of 1% that could also change every pixel? Sure, the merger would still have to choose which adjustment goes first if the changes aren't independent, but how would they know that's what changed? I.e. how would the diff tool know that the changes are "brightness +1%" and "contrast +1%" and not some other arbitrary number of adjustments?

<comment><USER11> I don't think the problem is trivial, but I don't think it's hopeless either. If we can measure a person's pulse and mood with a camera pointed at their face, I'm sure we can come up with a tool that can approximate semantically meaningful diffs of artwork. For image formats like xcf that store parts of the image or the editing history independently, this problem becomes even more tractable.

<comment><USER12> It's very tractable if you don't insist on the diff reconstructing the target file byte-for-byte. But this would require pretty invasive changes in the version control system, no?

If you change the top-left pixel of a PNG, for example, between the intra prediction and the DEFLATE compression, the new file can be totally different, and to reconstruct it you either hope the destination is using the exact same libpng with the exact same settings, or you have to find a space-efficient way to write down all the arbitrary encoding decisions the format allows.

</comment></comment></comment></comment></comment></comment><comment><USER13> So basically it's git-annex, but tied to GitHub. [http://git- annex.branchable.com/](http://git-annex.branchable.com/)

<comment><USER14> > tied to GitHub.

The protocol is open ([https://github.com/github/git- lfs/blob/master/docs/api.md](https://github.com/github/git- lfs/blob/master/docs/api.md)) and the client additions are open source. There is a reference server implementation at [https://github.com/github/lfs-test- server](https://github.com/github/lfs-test-server).

edit: added protocol spec

<comment><USER15> > The protocol is open and the client additions are open source. There is a > reference server implementation at [https://github.com/github/lfs-test- > server](https://github.com/github/lfs-test-server).

This isn't about this particular instance (Github's LFS), but in general, a "reference implementation" isn't the same thing as having an open protocol.

Having a reference implementation without a proper specification means that any other implementations have to re-implement the existing reference implementation, _including_ any bugs. The purpose of a specification is to outline _undefined_ behavior as much as it is to outline defined behavior. That is, the specification says, "these are the portions of the program which you may _not_ rely on".

We've seen this happen in some languages in which a particular implementation is either the _de facto_ or _de jure_ standard. Other compilers or interpreters end up having to mimic their bugs when it comes to things like arithmetic overflow/precision errors, because developers have come to rely on the language behaving one way, in the absence of any clear rules telling them otherwise[0].

[0] Not that developers may not rely on things that a specification explicitly tells them not to - there are plenty of examples of this too - but at least then it's possible to say determine either that a particular program will run on any standards-compliant implementation, or that it is implementation- specific.

<comment><USER14> You're right, the protocol is also required. I didn't link to it in my comment, but it is also open and well-defined. I've updated my comment. Thanks!

</comment></comment></comment></comment><comment><USER16> This looks really interesting. You basically trade the ability to have diffs (nearly meaningless on binary files anyway) for representing large files as their SHA-256 equivalent values on a remote server.

What will be interesting is to see whether GitHub's implementation of LFS allows a "bring your own server" option. Right now the answer seems to be no -- the server knows about all the SHAs, and GitHub's server only supports their own storage endpoint. So you couldn't use, say, S3 to host your Git LFS files.

<comment><USER17> _You basically trade the ability to have diffs (nearly meaningless on binary files anyway) for representing large files as their SHA-256 equivalent values on a remote server._

That's exactly what git-annex does. Except it can host on your own servers, or S3, or Tahoe-LAFS, or rsync.net, etc. And it's free software. And it supports multiple servers for the same repo, so you have redundancy.

Adding an S3 remote is just setting the AWS keys and running a single command: [http://git-annex.branchable.com/tips/using_Amazon_S3/](http://git- annex.branchable.com/tips/using_Amazon_S3/)

<comment><USER18> And if you want the simplest solution (ie store blobs with the rest of your code), gitlab offers git-annex compatibility ([https://about.gitlab.com/2015/02/17/gitlab-annex-solves- the-...](https://about.gitlab.com/2015/02/17/gitlab-annex-solves-the-problem- of-versioning-large-binaries-with-git/))

<comment><USER19> Thanks for mentioning us rakoo. Using git-annex on GitLab.com is completely free. We're thinking about a 5Gb per repo cap but right now its unlimited.

</comment></comment></comment></comment><comment><USER20> > Every user and organization on GitHub.com with Git LFS enabled will begin > with 1 GB of free file storage and a monthly bandwidth quota of 1 GB.

Does this mean that with the free tier I can upload a 1GB file which can be downloaded at most _once a month_? Even a small 10MB file, which fits comfortably in a git repo, could be downloaded only 100 times a month. Maybe they meant 1TB bandwidth?

<comment><USER21> I would suspect the point is rather that you have a bunch of megabyte range files, and you rarely update them and don't have to sync. But for most workflows this feature seems targeted at, the free tier seems insufficient.

<comment><USER22> I'm having trouble seeing where a 1GB/month quota in any way meshes with "large file" support. The free tier is basically "test out the API, don't even think about using it for real".

<comment><USER23> Yes, that is the free tier. If you want to use it seriously, it will cost some money. OR you can use it and host your own file server, for free.

I don't think these facts are a problem. They create an open source tool, provide a location to try it out, and a service to pay to use it if you like it and don't want to host yourself. Seems like a fair offer.

</comment></comment></comment></comment><comment><USER24> The "filter-by-filetype" approach used here is going to work a lot better for mixed-content repositories than git-annex, which doesn't have that capability built-in (to my knowledge).

git-annex has been great for my photo collection (which is strictly binary files). It lets me keep a partial checkout of photos on my laptop and desktop, while replicating the backup to multiple hosts around the internet.

At work we have a bunch of video themes that are partially XML and INI files and partially JPG and MP4. LFS would work great for us, except we don't use github (we don't have a need for it.) It looks like this is going to be very simple for that kind of workflow.

Just yesterday HN user dangero was looking for this exact sort of thing, large file support in git that didn't add too much complexity to the workflow: [https://news.ycombinator.com/item?id=9330125](https://news.ycombinator.com/item?id=9330125)

<comment><USER17> The filter-by-filetype can be replace by small script that augments git: [http://git-annex.branchable.com/forum/help_running_git-annex...](http://git- annex.branchable.com/forum/help_running_git- annex_on_top_of_existing_repo/#comment-41049e5e5de08f6cc0b76f9298b8e4c0)

<comment><USER19> Would be nice to replace that with git hooks so you can just use regular git commands. Any idea's if that is feasible?

<comment><USER17> I'm not sure, but I doubt a hook would do. An alternative would be to have a frontend script to git that would shadow the git command (using shell aliases) and call git-annex when appropriate.

<comment><USER19> Yeah, I don't like shell aliases but it would work. I wonder how the LFS client works.

</comment></comment></comment></comment></comment><comment><USER25> This solves a real problem, but I can't help but feel it is a band-aid hack.

The main fundamental advantage (vs implementation quirks of git) I can see is that these files are only fetched on a git checkout. But (of course) this breaks offline support, and it requires additional user action.

Wouldn't it have been fairly easy to build exactly the same functionality into git itself? "Big" blobs aren't fetched until they are checked-out? This also has the advantage the definition of "big" could depend on your connectivity / disk space / whatever, rather than being set per-repo.

<comment><USER26> I have a feeling the decision for how to arrange, as a separate thing, is likely to feed the monetization component. Particularly if it's limited to using GitHub's storage.

<comment><USER27> Specs are open, there's an open server implementation. It might be easiest to set it up with github, but if it catches on, I expect implementations will be readily available from all github-like platforms and as stand-alone.

<comment><USER26> Awesome. I did notice they called it "Git LFS" instead of "GitHub LFS", which should be a clue there, though from other comments I figured it might be GitHub specific.

</comment></comment></comment></comment><comment><USER28> Has someone had a closer look and can say how this compares to Git-Annex?

<comment><USER29> This and git-annex (and git-fat and others) use the same basic architecture of storing links in Git and schlepping the binaries around separately.

Git-annex renames binaries with their SHA256 hashes, puts them in a .git/annex/ dir, and replaces files in the working dir with symlinks. Git-LFS seems to use small metadata pointer files (SHA256 hash, file size, git-lfs version) instead of symlinks. Not sure whether the files reside in something like the .git/annex/ dir; I'm guessing the do or there wouldn't be those pointer files.

You can clone a repo without having to download the files.

With git-annex you can sync between non-bare and bare repositories without having a central server. Git-LFS seems to have a separate server for binaries. It looks like it may act like a git-annex special remote rather than git- annex's usage of synced/master branch.

Git-annex repos share information about the locations of annex files, how many repos contain a given file, etc. You can trust and un-trust repos. It doesn't look like Git-LFS offers this.

Git-LFS has a REST API. I'm using an old version of git-annex so I can't say if it does (I think it does).

Git-LFS is written in Go, git-annex is Haskell.

Git-LFS is a GitHub project. GitHub will offer object hosting.

Update: clarity, speling, added a bullet point.

<comment><USER5> The lack of location tracking looks like the most significant difference to me. While the git-lfs documentation does mention that different git remotes can have different LFS endpoints configured, all git-lfs knows about a file is its SHA256. So how can it tell which remote to download the file from? The best it could do is try different remotes until it finds one that has the file.

I hesitate to say this means git-lfs is not distributed at all, but it seems significantly less distributed than git-annex, which can keep track of files that might be in Glacier, or on an offline drive, or a repo cloned on a nearby computer, and so can be used in a more peer-to-peer fashion when storing and retrieving the large files.

<comment><USER30> At a minimum, the metafile should include a URI, stating the last known location of the file, rather than just a bare SHA256.

<comment><USER5> That doesn't work very well. Consider what happens if two different clones of a repo update the metadata last-known url at the same time with different urls. Merge conflicts.

This is why git-annex uses a separate branch for location tracking information, which it can merge in a conflict-free manner.

<comment><USER30> Late reply: that's fine, as long as there is some information as to where the location is, and not GitHub-only.

</comment></comment></comment></comment></comment></comment><comment><USER31> After a quick scan, I'm a bit worried that this is too tied to a server in practice. For example, if I've downloaded everything locally, can I easily clone the whole download (including all lfs files) into a separate repo? If I can, can changes to each be swapped back and forth?

</comment><comment><USER32> Our solution is likely a lot more duct tape-y, but we developed a straight- forward tool in Go for managing large assets in git: [https://github.com/dailymuse/git-fit](https://github.com/dailymuse/git-fit)

There's a number of other solutions open source out there, some of which are documented in our readme.

</comment><comment><USER33> Can someone explain to me what problem this solves in layman's terms... How are version control systems are "impractical" for large files?

Or to put another way, what problems will I run into if I just commit large media files without using this?

<comment><USER34> With distributed version control systems such as Git or Mercurial, when you clone a repository you get the entire history of that repository (or of a selected branch). This means that if you place large media files directly in the repository, then every clone will contain each and every revision of that file. In time, this will cause an enormous amount of bloat in your repository and slow work on the repository down to a crawl. Cloning a repository several dozens of gigabytes in size is no fun, I can tell you.

Centralized version control systems such as Subversion don't have this problem (or at least, to a lesser extent), because as a user you only download a single revision of each file when you check out the repository.

Extensions like git-media, git-fat and now git-lfs solve this issue by only storing references to large media files inside the Git repository, while storing the actual files elsewhere. With this, you will only download the revision of the large file that you actually need, when you need it. It's sort of a hybrid solution in-between centralized and decentralized version control.

</comment></comment><comment><USER35> Is there any hint on pricing? Slighty annoying to have a section titled "Pricing" which .... doesn't tell you the price. I would much rather use my own external server for hosting large files, it is going to need to be price competitive with other options to be interesting I would think.

</comment><comment><USER36> What's stopping git from storing large files using Merkle trees + a rolling hash?

I'm probably missing something since there this, and git-annex, and git- bigstore, and others...

</comment><comment><USER37> Does this mean gamedevs might start droping Perforce for this? If its not too expensive maybe?

<comment><USER38> This is certainly the issue that is preventing game devs from adopting Git.

On the other hand game devs at this point are very used to Perforce, and it looks like Perforce is interested in solving this problem from the other side, by adding Git features to Perforce Helix and making it distributed.

<comment><USER39> Helix Versioning Engine is a native DVCS. This is in addition to a Git management solution that is part of the solution. Choice of workflow, combined with efficiency in large file, large repo handling -- definitely interested in solving the problem right, instead of using band-aid.

</comment></comment></comment><comment><USER19> I like the ease of use of 'git lfs track "*.psd"' and being able to use normal git commands after that.

Would it be possible to extend git-annex with a command that lets you set one or more extensions? By using git hooks you can probably ensure that the normal git commands work reliably.

</comment><comment><USER19> To celebrate the broader support for git with large files we just raised the storage limit of GitLab.com to 10GB [https://about.gitlab.com/2015/04/08/gitlab-dot-com- storage-l...](https://about.gitlab.com/2015/04/08/gitlab-dot-com-storage- limit-raised-to-10gb-per-repo/) also, we're glad GitHub open sourced it and didn't call it assman

<comment><USER19> Someone asked if this was temporarily or permanent, it is permanent, see [https://news.ycombinator.com/item?id=9344984](https://news.ycombinator.com/item?id=9344984)

</comment></comment><comment><USER40> Has anyone seen what happens for a user who doesn't have this installed when cloning? I've tried it out but it seems to not affect local clones.

</comment><comment><USER41> Does Github really do this using git's "smudge" and "clean" filters? That would mean reprocessing the whole file for each access. That's inefficient. It's useful only if someone else is paying for the disk bandwidth, and necessary only if you don't have control of the storage system. Why would GitHub do that to itself?

</comment><comment><USER42> BitKeeper has had a better version of this since around 2007. Better in that we support a cloud of servers so there is no "close to the server" thing, everyone is close to the server.

What we don't have is the locking. I agree with the people commenting here that locking is a requirement because you can't merge. We need to do that.

</comment><comment> Pirate-of-SV Can't wait too see what Linus got to say about this. I suppose he got an arguably better solution to the problem?

<comment><USER43> My guess is that Linus _doesn 't care_ about large binary files.

<comment><USER44> Yeah I've read interviews where he's said that he wrote git for his use case, which I imagine doesn't include large binary files. I don't think he'd really care.

</comment></comment></comment><comment><USER45> Wouldn't it be nicer if we had something like this on the level of the filesystem, instead of on the level of a version control system? Advantages would be that git and any other user-space application wouldn't need much extension, and files could be opened as if they were on the local file system.

</comment><comment><USER46> > Every user and organization on GitHub.com with Git LFS enabled will begin > with 1 GB of free file storage and a monthly bandwidth quota of 1 GB.

A GB doesn't get you very far if you are working with raw audio and video.

Does it make sense to think about storing virtual machines images (.vmdk) in git on GitHub with LFS?

</comment><comment><USER47> I still don't get why you wouldn't just check large binaries into a submodule and host that everywhere you would an annex/LFS.

</comment><comment><USER48> Yes! Bringing us all one step closer to the whiysi (we host it you store it) dev paradigm. Bravo!

</comment><comment><USER49> Cool! Can't want for future integration of content-addressable systems like ipfs :)

</comment><comment><USER50> This is very handy for designers, who want to use Photoshop or Illustrator with Git

</comment><comment><USER51> Hopefully bup will implement something like that for the backuping.

</comment><comment><USER52> Does this mean github could become useful for music production?

</comment><comment><USER53> So does this mean the large files are actually versioned?

<comment><USER54> From how I read it, it sounds like a little of yes and no... it's similar to git's way but I am not sure if they are really going to keep versions of all of the old large files... I guess if they are going to be fully reverse compatible like being able to go backwards in git you have to...

</comment></comment><comment><USER55> Can it link to torrent?

</comment><comment><USER56> Ah, cool! At last I will be able to store my database backups in GitHub.

<comment><USER51> Hopefully they will provide such functionality, but I don't think in the nearest future.

</comment></comment><comment><USER57> my name is Lars & i do projects for LiveIT! this is exciting</comment>


Robotics to Have Its "PC Moment" - <AUTHOR> https://popularelectronics.technicacuriosa.com/2018/08/01/robotics-pc-moment/ <comment><USER2> the PC metaphor is cute but it leaves out a few things imo. programming a robot to e.g. move things around in your workshop is intrinsically harder than eg. programming a home computer to do your taxes (for the robot you need computer vision, sensor fusion, motion planning etc). it will take the equivalent of BASIC before widespread use is feasible (= something that automates away the low level sensor-motor complexity). so is that coming soon?

<comment><USER3> "that moment when computers stopped being massive machines that only a handful of corporations could operate to something everybody found a use for—small businesses first, homes some time later"

<comment><USER2> yeah, I just read the article. true, for small-medium businesses it's more feasible. probably also an important point that machine learning can address some of the basic complexity</comment></comment></comment>


Help fight dementia by playing a mobile game - <AUTHOR> http://www.seaheroquest.com/en/ <comment><USER2> [The page load was painfully slow for me.]

The game appears to be sponsored by Deutsch Telekom (T-mobile).

The video explainer is here: [http://www.seaheroquest.com/en/what-is- dementia](http://www.seaheroquest.com/en/what-is-dementia)

The goal is to research how people navigate and to use that data to understand dementia.</comment>


More About Unicode in Python 2 and 3 - <AUTHOR> http://lucumr.pocoo.org/2014/1/5/unicode-in-2-and-3/

<comment><USER2> I wish the core developers would do two things:

1\. Add a new string type to Python 3 that mimics the old Python 2 str type (ASCI)

2\. Backport the usefull new features from Python 3 to Python 2.

If they don't do these things, then obviously some group will fork Python 2.7 and 20 years from now, there will still be far more people using Python 2.x than Python 3.x.</comment>


Wartime trickery - <AUTHOR> http://en.wikipedia.org/wiki/Jasper_Maskelyne

<comment><USER2> Highly recommended: _The Deceivers: Allied Military Deception in the Second World War_ [http://www.amazon.com/Deceivers-Allied-Military-Deception- Se...](http://www.amazon.com/Deceivers-Allied-Military-Deception- Second/dp/1616080795/)</comment>


Web Apps Are the Future - <AUTHOR> http://www.sitepoint.com/long-live-web-app/

<comment><USER2> This article does a terrible job of supporting its headline. The conclusion was that native is better than web but web might catch up. The arguments that show web > app:

\- mobile apps are bigger than web apps, incorrectly citing an article that claims an average of 23mb per app including games with retina assets

\- there's a cost for publishing apps but no mention of hosting, domains, SSL, payment gateways etc

\- apps need to be downloaded and may not run offline

\- users don't like apps as they're bigger to download and have updates</comment>


Greece Is Cutting Itself Off from the Internet in Attempt to Save Its Economy - <AUTHOR> http://m.mic.com/articles/121824/greece-is-slowly-cutting-itself-off-from-the-internet-in-attempt-to-save-its-economy

<comment><USER2> ...

So they actually want the country to crash and burn?</comment>


Tell HN: Don't work for companies that use hackerrank - <AUTHOR> This is not a way to evaluate programmers.   This is taking the stupidity of the white board programming challenges and injecting it with steroids.
This is just another step down the path towards the commoditization and lower status of programmers.
Software development is an art, as well as a science, and a good engineer is able to architect systems, even small ones, and is able to comprehend the interaction of several modules of code.
Not bang out some crap that produces the correct results in a very narrow challenge.
Never mind that hackerrank is poorly implemented- it has numerous bugs (because it was clearly written by the kind of people who think hacker rank is a good idea- those who think speed is paramount over quality[1]) Numerous times it would not take submissions that were pasted into the editor (I used an external editor, Atom, because the syntax highlighting was correct for my language).  It is limited in its languages and finicky in them.  The errors are often incorrect, resulting in the rejection of working code. etc. etc.
But even if hacker rank were well implemented it is measuring only two things- speed and whether the output meets the criteria set by the creator of the test.  This output criteria can often be wrong or more narrow than correct results.
And speed of banging out lines of code is not a measure of a programmer.
So, use this test and you'll get the people who don't understand software engineering, lack significant experience but can produce a lot of code quickly.
But not elegant systems... and you'll be slower to market and less nimble as a result.
[1] It isn't, not even in a startup.  Speed to market is about getting a working product to market. This is slowed down by poorly engineered messes that don't work. <comment><USER2> So, you don't do well on competitive programming problems and therefore decided to write a rant about it on HN. Do you even got an anectote where a candidate who did well on these kinds of problems were worse than another candidate who didn't do well on it?

</comment><comment><USER3> My employer uses it for phone screens and it's nice to have a way to look at the same text and write/discuss some pseudo code. If someone is using it to time people on stupid questions then it's classic PEBKAC.

Is hackerrank measuring time or was that the interviewer?

<comment><AUTHOR> DR Chrono has an add on the front page where people do their "challenge" in order to compete for an interview.

Worst example yet.

Apparently the company side generates scores based on whatever arbitrary factors HR chooses, including time, and some companies were simply comparing scores to decide who to hire.

Using it as a way of collaborating during a phone interview seems pretty reasonable.

<comment><USER4> Hi, one of the founders of drchrono here. I think the hackerrank challenge works well for us as a company and is better for most candidates than phone screening or resume reviews. It isn't perfect and it has strong and weak points like any interview process.

There are really great programmers we hired who first came through this hackerrank challenge that we would have missed if we had used more traditional interview methods like screening their resume and a phone interview. As an engineer myself I hate technical phone screenings and resume reviews, I HATE doing them when I'm hiring and I HATE being subjected to them if I was looking for a job.

Based on this post and some other feedback I've seen, there must be a set of good programmers (who companies like drchrono and others would love to hire) who do terribly on these types of tests or just don't want to commit to taking the 60 minutes or so to do these tests.

If you don't want to commit the time to do the tests and you want to blanket apply for tons of jobs at once, then larger companies/recruiters are a better fit and I'm ok as a tech startup if we miss out on you. We want to recruit people who are passionate about changing healthcare and our company's mission, and having someone commit an hour of time feels fair. We as a company spend 10+ hours for every candidate we screen so asking for one of your hours for 10+ of ours seems reasonable (I'm sorry if other people don't feel that way.)

We use Python/Django on our backend and we found the tests are reasonable to complete in Python. For iOS developers the C-type challenges seem an order of magnitude harder. So language experience and the technical limits of hackerrank do make this process have blind spots and we know we are going to miss out on some good candidates. I still think hackerrank is the best solution I've seen so far to objectively judge technical talent and works better than phone screens and resume reviews (which are horrible and I personally hate).

We've used hackerrank (formerly interviewstreet) almost since we started hiring software engineers, so every engineer we currently have working at drchrono passed through the hackerrank challenge as the first line interview. One other benefit is that if someone gets a good score on the test we feel 90% sure that the person is technically strong enough to be able to do their job and we focus the rest of our interactions with the candidate on other variables.

I think the best way to apply and get a job at a company that uses challenges like this if you are bad at them, is to have built awesome stuff: Have an app in an app store that people use, have a popular website, have contributed significantly to an amazing project/product) and to reach out through your network on Linkedin / Angellist to people at the company. This works better for candidates who have done a lot of stuff. I've seen programmers coming out of high school who have really cool apps in the App Store and have cool websites / web applications, so this is achievable for developers of any background.

</comment></comment></comment><comment><USER5> The hackerrank site is terribly coded. Going between the problem and submission pages takes several seconds and hangs any browser I use about 25% of the time.

+1 to the incorrect solutions

</comment><comment><USER6> It's obvious that it is not perfect and it should not be used to rank programmers during an interview but is a good test for basic algorithms skills, something that every programmer with a serious education should be mastering.

</comment><comment><USER7> You basically code on the browser, which is not meant to be an IDE of your favorite programing language, you have to blame HTML, Web, Javascript, Web Browsers, Internet, your ISP, country, policies, cables, satelite all together, a lot of open source tools used by hackerrank for syntax highlighting, auto-completion etc.

Just because you didn't go through, you recommend whoever cleared not to join the prospective employer?

I see hackerrank and other similar sites are improving overtime, along with technologies & eco-system. You should understand that you might be programming 10000 miles away from the compiler.

</comment><comment><USER8> I tinkered with HackerRank just for the coding exercises, and was initially impressed by the sheer volume of languages the site supports, but quickly grew frustrated with it. The use of stdio instead of a test suite like Codewars uses made writing in any languages for which they lacked I/O boilerplate tedious, and the layout was atrociously oversized, not even fitting completely in a 1000px-wide browser window.

</comment><comment><USER9> Software development is an engineering discipline.</comment>


Q/A: What Thread-safe Rails Means - <AUTHOR> http://blog.headius.com/2008/08/qa-what-thread-safe-rails-means.html <comment><USER2> The big thing for me is the resource usage: Rails is wonderful, but I have a lot of different apps running on my server, and they all consume a fair amount of memory, which adds up. Anything that will slim Rails' footprint down some will mean a lot of savings for a lot of people.

<comment><USER3> You can try Passenger and Enterprise Rails combination before multi-threaded Rails.

It's interesting that in his announcement dhh actually downplayed the importance of this contribution, saying it is just another item in the enterprise-readiness checklist.

I'm pretty sure I read somewhere that a lot of Ruby-related native code, including db drivers, is written in a way that actually blocks the green threads when the native code is waiting on I/O. Can anyone confirm or deny this?

</comment></comment><comment><USER4> Oh good, I was wondering what this meant to me as a novice at Rails.</comment>


Slowcop beta arrives - <AUTHOR> http://slowcop.com/users/sign_up?invite_code=BETA

<comment><USER2> Signed up. Will look at integration the deployment API every time I roll out new things for my site. Interested to see how things track over time.</comment>