He mentions Lombok in the tools section.

And Guava's collection creation methods are part of an intense desire to not use the new key word anywhere in application code.

Also, if you look at the Javadocs for some of the creation methods, they explicitly state that they are for Java 6 and earlier, and that modern code should just use the constructor with the diamond syntax.

http://docs.guava-libraries.googlecode.com/git/javadoc/com/g...

The other replies kind of hit on this, but I'll expand on it by saying:

The collection creation methods existed because Java could perform type inference on methods but could not on constructors:

  // Java 1.5
  Map<String,Integer> map = new HashMap<String,Integer>();
  // Guava
  Map<String,Integer> map = Maps.newHashMap();
  // Java 1.8 diamond notation
  Map<String,Integer> map = new HashMap<>();

I realize he mentions Lombok, but he specifically bemoans the extra boilerplate with writing builders and data classes, but does not mention the @Data or @Builder annotations...

I think it's usually better to do this with a reproducible script instead of manual editing in a text editor. There are too many times where the requirements change after the fact for "simple one-off" transformations.

I was going to say the same thing. I think of everything as black boxes, so choice of language is not as important as approach. I would use PHP because it's informal - it's a hybrid between shell and C so expressiveness and speed come basically for free and there isn't much friction. Being able to quickly iterate often makes relationships become apparent at a meta level. For example a quick lookup of a parsing error might reveal that the data was generated by a standard tool, so I could drop what I'm doing and grab that instead. It's not so much about individual choices, but a way of attacking problems that compounded over time leads to a great deal of leverage.

I've used this to great effect to help handle partially obfuscated phone numbers and validate whether they could be valid or not. There are far too many edge cases to try to handle on your own if it's not core to the problem you're trying to solve.

Soylent is the first one that comes to mind.

It's like asking "Why doesn't everyone know calculus in this day and age? It was discovered hundreds of years ago." Sometimes people are ignorant, lazy, under a time crunch, etc. When information became widely available(That SQL injection is bad and easy to fix) has little to do with how 5 random dudes working on a team write their code.

I already do default to SSL when possible with the KB SSL Enforcer extension[1]. It breaks some sites some times, but it's generally pretty good.

[1]https://chrome.google.com/webstore/detail/kb-ssl-enforcer/fl...

I agree that they fill different needs and there's definitely room for both. I think a good addition to http://startbootstrap.com would be a few preconfigured palettes that will work with the templates.

http://bootswatch.com already has some of these. I might start integrating some of my own sometime though. Might not be a bad idea.

Every time I see a thing about the internet of things, I get a little excited, but then they don't really show exciting examples of what you should do with it. Outside of Lockitron and Nest, I am unimpressed with what's come out so far. But it's tough. The field seems so expansive that most people get overwhelmed with possibilities, but few bare any fruit. For my part, I've only had one decent idea in the space. I'd love to see a robot that cooks food for me while I'm commuting home. Possibly like a Zojirushi rice cooker that I can program to make stuff at a certain time, but with more flexibility and a web API.

Mechanical engineering is really hard. Getting injection molds made is really expensive. 3d printed stuff is janky (right now).

Sure, but that's hardly the only problem. The simple fact is most people don't have systems in their home that they want/need to interface with through an app or something. Here's a close to comprehensive list of the electronic things in my home: Several computers, Microwave, George Foreman Grill, Rice Cooker, Fridge, Thermostat, Toothbrush, Lights, Dish washer, Washer/Dryer

Mechanical engineering doesn't seem to be blocking point for any of those except maybe the washer/dryer and food related stuff. I could definitely see the opportunity to have a device that could portion out N grams of rice per person and then have it ready to eat when I get home, but for the rest, I don't see it as the stumbling block.

Machine vision is also a problem. One of the biggest I think. You could have a tiny tractor that grows you delicious veggies, but machine vision can't deal with plants.

Yeah, but if we had that we wouldn't be talking about "internet of things" we would be talking about "actual AI everywhere" which a whole next level of difficulty up.

Injection molding is the cheapest process on the planet, if you have a production run of >10k for a mass produced product. It is hard to find anything on Earth cheaper than an injection molded object.

That's a big damn if though.

I mean, for small runs.

There's a startup on a an automated home cooking machine[1], read the section about "palate home".

http://gigaom.com/2013/09/26/designer-don-norman-on-his-stea...

Agreed. Starting with a framework first unless you truly and deeply understand the space is going to either make something that kind of solves a problem but has its own problems, period, or kind of solves a problems but has its own problems for a really long time while you slowly refine it. And the odds of dedicating yourself to solving a problem that you don't have a need to solve are low.

I tried to test your example with your API, but it requires a credit card even for the freemium plan. Is there any way you can make a rate limited API that never charges to avoid that? I'm not familiar with mashape so it may not be possible.

I can't easily. The free quota is pretty high on their. (5000 calls), For development I'd work off a few test cases that you save the response on, then if you get something working decide if 5000 calls a month will fill your needs.

Saw you are trying it out. Awesome! Sorry the documentation is a bit weak right now, we had people wanting it so we got it out, rather than getting all the docs complete.

I did try it out. It does a good job of pulling out different bits and categorizing them. I went ahead and ran the example you had and put it up to continue the conversation(https://gist.github.com/adpreese/6722561). If you want me to take it down, I will certainly respect that but I thought it'd be convenient for anyone else paying attention.

The noun phrases part of the response gave a concise list of things, including the word thing(hijacked, NLP thread, stuff, My NLP, thing, Drakaal, cooler, heuristics, Just). That's maybe good at picking out the nouns, but it's not really actionable yet. It might be great as the bag of words to use for trying to classify something, but by itself the best it's giving me is NLP/heuristics if I had the concepts grouped together, somehow. I think that's a reasonable takeaway from your example, but I'd be curious what your thoughts are on it.

PS. I tried the TLDR API on a copy and paste of the original article with commas, periods, and single and double quotes removed but it returned a 500 error. I'm probably doing something wrong, but I'd love to see what it spits out if you can help me out.

We have the groupings and we can use sentiment to get the importance. The API is somewhat limited compared to our full bag of tricks, mostly because we don't want to give away all of our secrets, but also because we change things pretty often and would have to let others know when we made changes if they were consuming an API.

Play with the http://TLDRStuff.com tools there is zero learning curve over there.

One of the API's takes a URL, one takes plaintext or HTML, not sure which one you hit, but the TLDRStuff.com will make it really easy for you to play.