skysight-inc/HackerNews huggingface dataset:
I know he's talking about averages but his story can confuse you when he talks about when people start work and when they arrive.

I'm immediately suspect of his numbers when he says the typical starting time in St. Louis is 7:50AM. I've lived in St. Louis all my life and only had one short-lived job that started before 8AM. Every other job I had started at 8AM to 8:30AM. I don't know anyone who has a normal, every day job that starts earlier than that and I wouldn't even think to call someone at their business earlier than that.
More recent:

"Aw man, I need to install Chrome to run this website?"
Hardly a library in the traditional sense. At best a libra-framework with tons of baggage added.

From their own project page: "AngularJS — Superheroic JavaScript MVW Framework" (empasis mine).

You have to code your logic inside its objects (controllers, directives, services, etc) -- that's not how a library works.
It's basically an Oppo (founder worked there) Find 7.
Please name a UI platform where you don't use frameworks.

Android activities/fragments = a framework.

WinForms = a framework.

ncurses = a framework.

Unity / Unreal3 = a framework.
As arguably the person who first sold Android-based robots, I understand the gripe very well.

People just aren't interested.

They'll praise Tesla once they know who he was, but they still buy Edison.
each inch is 25.4 millimeters.

Huh, I missed that development. https://en.wikipedia.org/wiki/Inch#Modern_standardisation
I fully agree with the sentiment. I've always been against TDD being pushed. Obviously as developers we love the stress-free appeal of unlimited time, test first, achieve 100% confidence in code. Wow so glamour.
In practice this will always never work, since we are time and budget constrained. Halfway we find that we are dumping tests in favor of writing even more hacky-tacky code just to meet a deadline.
This code will never be refactored, because the client is satisfied with the results, and does not appreciate all the edge-cases because you said you would take care of them.

No, I'd rather produce code that is well written, can be deployed, and taken over by other devs if needed, not several levels of testing paradigm's that need to be satisfied before code can be migrated.

Yes I agree that there is obviously a place for tests, and IMHO that's when certain business logic is considered implemented, and tests will need to catch all the edge-cases to make sure it will deliver in the future and not break with modification.
It's not so much about moving away from unit tests are more to do with picking the best points at which to test your apps. For web apps the natural points at are the model level and at the client level. For the Django apps I write these tend to be the most stable areas since they are likely to be heavily influenced by user requirements. The result is tests that have a long lifetime and provide better system documentation since they generally exercise the business logic of an app. That neatly avoids one of the major problems I have found with TDD that unless you know in advance exactly what you are doing and going to do you will end up writing a lot of tests that get junked.
We've learned a lot from using TM ourselves. I'd encourage to try cooking proper sous-vide somehow; the TM version doesn't do it much justice. The temperature control just isn't there.

You're right that a lot of the value in Mellow is going to come from the community, but it's already massively nice to have a device cook your ingredients to their peak before you step in and finish the process. You're going to have to cook, and we wouldn't have it any other way.
A quick Google for "FactoryFactory" led me to this wonderful page:

http://ws.apache.org/xmlrpc/apidocs/org/apache/xmlrpc/server...

I know it's a bit unfair to pick on that particular document - but I'm worried as a long recovered abstraction addict to what degree I actually thought things like that were ever a good idea.
I too was interested in what decisions spurred this design with application using Angular at one point, and there is a talk from ng-conf by one of the core developers of Angular that I think illuminates this: https://www.youtube.com/watch?v=_OGGsf1ZXMs

It boils down to managing complexity in complex web apps.
The problem is that even acknowledgment is discouraged by CYA types in case it leads to litigation later.
The Nexus 5 is only $350. This phone is nominally cheaper, but I wouldn't say 'killer'. I will think about getting it next time I purchase a phone though (I use a Nexus 5 now).
TDD on the unit level does seem to lead to high granularity, and complexity in the system as a whole in favor of simplicity in test construction. However, some of the problems described sound like they are coming from a premature optimization mindset rather than TDD itself.

Once I learned about Cucumber and the idea of stating a requirement/test that you can't even parse yet, much less have a test for, much less have the code for, I started liking the idea of TDD as a wish list pyramid.

This allows you to think in terms of the big picture requirements, and then drill down as required to fulfill those requirements. Because you've spec/documented your design on the way down to the unit tests you can always step up a few levels and reconsider, and rewrite architectural "tests".

For example my first test is "I have a software tool for editing photos". Now I implement this test by checking if there is an executable in a path. Fail. Now I make a hello world exe for that path. Pass. Now I write a new test: "It opens an OpenGL window.", and later "it uses a mvc pattern", "the edits are represented as a scene graph", etc. all the way down to specific logic.

You later realize that a scene graph is not the right way to model your process, so you change that test to a different requirement, the altered requirements now redirect the TDD flow of an entire section of the application instead of just unit by unit.
I do mine without any fat; I findthe duck legs render enough by themselves.

With SV eggs, I usually saw off the top of the shell carefully with a knife, and squeeze them out into the plate. It's a fun process!
This is a stunning opinion considering the fact that there are many Rails shops that can't turn around a build in less than an hour because you can't test models independently of the database.
For everyone thinking "What's the catch?" the catch is, you can't buy it.

They are doing 100x 'invite-only' purchases during April, and I haven't seen anything explaining more availability than that.
Forwarding this to our web guy right now, thank you.
Avoiding Common Workplace Communication Mistakes
But on the flipside, what if Google decides to adjust their algorithm and demote sites that don't use the appropriate Schema to markup their content? Then Google is still going to cut you out by ranking you lower than your competitors. And actually, I wouldn't be surprised if Google already ranks sites without schema lower than sites with schema.

Personally, I'd rather spoonfeed the info to Google, rank #1 and run the risk of Google cutting me out with Knowledge Graph, or however else they want use the info, than not spoonfeed the info to Google and rank #10 while my competitors rank higher than me.

Obviously it's not that cut and dry, but it creates an interesting dilemma.
I like it because it's about technology and it's entertaining. I used to complain about the content but now I accepted what comes up and learned to ignore any title with "2048" in it.
It's a definite possibility, but we're 100% focused on delivering the feature-set we promised before.
Wow, even CNN Breaking News ‏@cnnbrk: NYPD, of all people, should know better than to leave a loaded hashtag out here
An abstraction is not useful, in fact it's downright harmful, if it does exactly the same thing as what it abstracts over, but more verbosely.

A lot of these patterns you're used to seeing in Java stem from Java's static nature.

Here's a car factory in javascript:

function makeCar(dealerName) { return new Car(dealerName); }

And here's a configured car factory:

var myCarProvider = makeCar.bind(null, "my dealer");

It makes precisely zero sense to create abstractions that reimplement core language features. That would be like writing a C function to add two uint8_ts, or a macro that expands to inline assembly to convert a float to an int32_t. You already have these things built-in, you don't need a gorillion enterprisey patterns.
Antonio Meucci.

Bell stole the telephone from Meucci and the hydrofoil from Ferrarin.

The joke at my old uni was "Italians invent stuff, Chinese make stuff, Americans get the money". (And yes, I know Bell was Canadian)
>You don't like, but other people like it, get over it. Just don't use them and stop complaining all the time.

Yes, it's like there's these things called "opinions" and people are posting theirs and trying to compete for mindshare.

Instead everybody should just do whatever thing he prefers, and nobody should attempt to convince others that this or that way is better. We are all unique snowflakes, after all, and it's not like an industry or profession needs best practices...

/s
That ..er.. doesn't appear to work?

(Chrome, Firefox, PC)
For all the negative comments about FactoryProviderBeanCreator whatever style of enterprise-programming: There is a point to it all.

The point is software exists mostly within its socio-economic context - software is mostly made for people by people and will be used by people.

The SingletonProxyFactoryBean enterprise-programming tries to solve people-problems, it tries to waddle through dependencies between libraries, frameworks, language specifications, implementations, organizational structure and various teams within an organization.

This angular.js enterprisy-feel tries to do the same - push responsibility onto the others, or separate responsibility down (separation of concerns) where nobody actually has to do anything but "configure". Or "run" it. Or just "buy" it.

Thats the ultimate goal of enterprise and this style of programming - which eventually leads to somebody being required to know a language on top of a language on top of a language to adapt it to the business needs.

Its the same reason why abominations such as SAP and Microsoft Dynamics (or basically any closed source very expensive suite of software) exist - those products are on the altar of Enterprise, they fit well to the organization and culture of capitalism. They fulfill the goal of "just buy it" or "just install it" and it will do _everything_ a manager or team thinks of. So the programmers make it so - sure the program doesnt actually do anything without the correct set of configurations and options, but now its not an application thats developed inhouse, its a product we buy and can get support for, kind of.
> otherwise what exactly are you testing?

it depends, what do you want to test ?

If you are testing a single function, why would you care whether the data comes from the database, the network or from a mock ? All you need is to verify that the given function produces the expected output given the right (and wrong) inputs. Being able to test this way also makes easy to keep the components in your software decoupled.

My philosophy is to use mocks for unit tests and the real thing for integration tests.
We're designing Mellow to be used every single day, and optimising for that means a constant presence on your countertop.

Our idea is that instead of making sous-vide as cheap and simple as possible, we want to make it as useful and effortless as possible. I hope there's room for both types of product.
Google Testing Favoriting Service Google Stars For Chrome
Interactive Census profile of New York City
Off-topic, but I like seeing more and more programming related articles hitting the frontpage lately.
More amusing is that I/O is a conference of how to use Google services and platforms[0]. Really, look at it. It's almost entirely talks on how to build products for their p
platforms and pay-to-use APIs.

Presumably the developers still get their money's worth. If /when they don't soon or later these conferences will be full of empty chairs. So the question each person asks: "what do I gain by it," not what Google gains by it.
One word: Ember.js

I can't for the life of me understand the popularity of Angular.js.
I'm not familiar with your other examples but I object to ncurses being called a framework. In my understanding of the word a framework defines to some extent how your code needs to be organized and architectured, I don't think ncurses fits this description. It's more like a terminal-based drawing library.
Well, yes, but then that's all patterns are: terms used to represent a way of doing something. It's sort of marketing for methods - and whoever did the marketing for "curried function" just didn't do a good enough job, maybe.
Am I the only one that cringes each time i see the promise
"over a day's worth of battery life."

We used to have 2 weeks of battery life on any normal mobile phone.
> Over the years, the test-first rhetoric got louder and angrier, though. More mean-spirited.

Where are those mean TDD zealots? Can you point me at blog posts or mailing list messages displaying such behavior? I've never seen it personally. On the other hand, now and again a blog post like this comes up that's full of disdain towards the practice of testing first. I do TDD because it helps me get my work done. I'm happy to help others write tests if they wish, but I'd never look down on another developer because he or she doesn't use this tool. Some people like drawing diagrams, some people like to use an IDE... Do what works for you.
Prepare to Have Your Mind Blown by a Balloon and a Minivan
Well speed of testing is not the only consideration. Mocks are also (primarily?) intended to isolate your testing so you're not looking through an entire stack to find a bug. Often, especially in early phases of software they're over kill, and distract from implementation time however.
Yes, yes, and yes. It's worth it for what it does to fish and seafood alone.

You're right though, meats have traditionally been the main focus in sous-vide, but it's by no means limited to them. Pears are amazing, eggs too. Risotto, potatoes, and carrots are insane.
The price is actually higher than some of the cheap smartphones from Asia. What interested me is that CyanogenMod is now an OS of a 'killer' smartphone.
Seems to be a good device, but if there is no wireless charging I am out. It is one of those things that once you have you cannot go back. But the price point, the implicit promise of updates forever from CM team, and the fact that Google is moving to closed-source with key apps that used to be OS, does make this a very attractive phone. I hope there will be OnePlus Two.
And that mobile phone didn't do half what this and other smart phones do.
First person to create a HTML5 version, please reply to this comment with a link.
(Great idea though, other than the unity bit)
No we didn't, not at the time.

Go back ten years and we had a few days worth of battery life. Fast forward to now, and you'll get two weeks out of any non-smart phone.
I'd start by trying it out: https://www.youtube.com/watch?v=MYGYyZcm6kE
I think a problem is that we tend to overgeneralise our own experience. When we try out ideas, such as TDD, we (hopefully) get a good feel for how they work (or don't work) for us. Reading articles or getting advice might help us to understand and use those ideas better, but the impression is still based on your personal experience. That's fine when you're talking about how you like to work, but I think it comes unstuck when you start trying to apply it to other people. Even if you read other people's perspectives, it's often tempting to consider those that disagree to be idiots (although you might not be so blunt), and those that agree with you to be sensible.

I think it's more productive to try out a technique, try out some variations based on others' advice, and then share the experience: I found this technique useful in these situations, but not in these. Here are some tips that I found effective, and here's what didn't work for me. Then, people can try out techniques for themselves, and learn from your experience.

If we want to generalise what's effective and what's not for software development overall, then I think we need a much rigorous approach then getting a vibe from the community. I've only ever seen a handful of studies that try to be unbiased and somewhat scientific in assessing techniques like TDD.
Resource for Learning CoffeeScript
I've been feeling this way about testing for a while now and I'm glad that DHH wrote about it so I don't have to feel "wrong" or "embarrassed" by it anymore.

I personally have gone a bit further and only write tests after a successful incarnation of a project (that means customers) that I want to keep developing, or if writing and running the test itself costs me less time then F5'ing a page or mucking around in the rails console.

I have noticed that it's much easier to throw away code that I haven't invested a lot of time in and usually the second time I write it (with tests), I have a much clearer idea of how to implement and test something.
i don't think you actually understand these patterns or how they're used. it's useful when you have multiple implementations of `Car` that you want to use under different circumstances. Or when `Car` is dependent on static configuration that might depend on the host it's running on, or might be different in development/testing/production.
The thing is, while this kind of thing is available for pretty much every language, it is standard for Go. As in, if you don't gofmt your code, everyone who looks at it will bug you to format it. That's a huge difference. There's basically zero code in the wild that you'd ever want to use that /isn't/ gofmted.
Which came first, paper airplanes or real ones? [1992]
Sigh. I can't say anything about Angular because I've never used it. But this constant ridicule of "the Enterprise" is getting on my nerves. Obviously, software design patterns change a lot over the years. Old practices are abandoned -- sometimes more slowly than we'd wish -- and others replace them. But much of this criticism comes from the fact that the critics 1) use technologies that are not mature enough to have growing pains, and 2) don't really know how software is made in the real world.

RE 1, the factory/provider/whatever pattern, comes in real handy when 2 years from now, a crucial ODE library that your air-defense system uses, absolutely has to be replaced by something else. And it's not like a kid could write a quick re-implementation in Go over the weekend.

As for 2, many of these patterns have been designed for software that does not resemble web applications at all. Just to give a sense of how out-of-touch SV developers can be with regards to the software world at large, IBM, Oracle and SAP combined employ more people than Google, Facebook, Twitter and LinkedIn combined, ten times over; there are more Java developers in the world than the entire population of the entire Bay Area.

I'm not saying that the maligned "enterprise" patterns have a place in a client web framework, or that some of them aren't dated. All I'm saying is, stop treating some software patterns that you think are unnecessary just because all you build are CRUD web-apps as inherently stupid. They are not. One of the reasons people working on CRUD web-apps can "move fast and break things", and just "rewrite the whole thing in a couple of weeks", and say stuff like "what's wrong with a simple 'new'?" is precisely because the software they develop is, frankly, not that complicated.

I would also like to remind the author that his beloved Erlang was developed in the very same environment he thinks so little of.
https://www.greenqloud.com/

Based in Iceland, has FreeBSD 10. Not sure about SSD though.
Thanks, would also appreciate recommendations for better/faster Tesseract results. Particularly with scanned document PDFs.
Is any tablet that can makes calls a phone? Technically yes I guess, but it's still weird to call it that.
You had 2 weeks of "standby time" battery life, but in practice it was more like 3-4 days. I agree all OEMs should be pushing for 48+ hours of battery life, though, at the cost of performance or even higher resolutions and whatnot. Because when they'll promise 2 days of battery life, heavy users will still get only like 1, because with the phones promising 24h of battery life now, heavy users get like half of that. It would be great if everyone could get at least 24h of battery life, which means the "average" battery life should be 48h or more.
I think there is a different point to it all: Java doesn't have first-class functions.

In OCaml (and without doubt other programming languages as well), you can use a function to make "objects"/"values" that you want made ("constructors"). If you want to parametrize the function ("factory"), you just partially apply it to some arguments. If you need to make other objects before you can make the desired object ("dependency injection"), you pass other functions as arguments. If you want to do something else instead of creating a new object (e.g. "singleton pattern"), you write a different function.

It's just functions, all the way down.
Is actually anyone considering JavaScript not to be "ruined" by default in the first place?
No, I mean internally inconsistent. I had to point out that I meant it in the case of the button that said "1$" but not the rest of the website, where it said "$299" or whatever. Site down.
Curious about this too. Also, what's the stack providing Tesseract-as-a-Service? According to my cursory search, Google app engine won't run Tesseract as its a native library, not an API. I'd like to try this on non-Latin/CJK hardcoded subtitles, but ocrat does latin only.
Why Apple has stopped growing
I feel like these articles come up every few weeks. people don't understand angular (particularly why DI is useful) and criticize it for being verbose or confusing, usually using the provided sample code -- would it hurt to spend some time actually trying to understand the framework than to dismiss it on face because it looks kind of like something people don't like in Java?
nice! :-)

What about providing a carousel of latest/random albums to make it easy to find great photos?
same here, not seeing cursor or typed text
Bottom line: this is an easier way for Google to steal your information. Once they steal it, you will get almost no traffic as Google will show the answers themseleves
The response is as religious as the subject; and I don't think the AA allegory is very respectful.
Thats what people typically market it as, but when you use it, it has mor in common with various GUI toolkits. Lots of windowing, and the like, but not much drawing.

Not sure if that makes it a framework, though.
Snowden revelations have been 'good and bad' for business, says Huawei CEO
Techorama Belgium
i completely agree. I'm 100% against bureaucratie , but accusing angular of being bloated is a bit unfair. It does has its weird part (like the service/factory pointed in OP) but in general code is much much lighter using the framework.

As opposed to , let's say, spring, which transforms a simple project into a gigantic mess of configuration files and abstract annotated code.
You might find this amusing. http://www.airtractor.com/
So it's a ComplexComplexApplicationComplexityManager.
I hope you're right. Good luck!
A Quick Look at Haskell