For the price, they are excellent keyboards. Well made, slim form factor, durable, no breakable parts. I use them with my non-Apple machines too. For $49 it's really hard to beat.
Slashdot videos: Now with more Slashdot!
We've improved Slashdot's video section; now you can view our video interviews, product close-ups and site visits with all the usual Slashdot options to comment, share, etc. No more walled garden! It's a work in progress -- we hope you'll check it out (Learn more about the recent updates).
Our conservatives are batshit insane from old-time-religion and living in a far-right-wing propaganda bubble, and want no part of modern civilization, but the US is hardly a failed state.
That old time religion teaches love, joy, peace, forbearance, kindness, goodness, faithfulness, gentleness and self-control. At the point that we consider that insane, we should take a strong look in the mirror and consider what type of propaganda you're consuming to derive such a view.
I've learned it. I'm not going to pretend that I'm unbiased about this stuff because I was building single page applications before jQuery or Prototype even existed, before JSON was a thing, and when you still had to code things to work in IE6, Firefox, and Safari (because Chrome wasn't a thing yet). Because of that I've got an internal bias of treating anything in the browser as insecure and unreliable.
> I don't understand 'so much logic'. You need to validate user input in the browser (with 'logic') to avoid server round trips for common errors; but you also must validate data on the server side, because you can't trust the incoming POST/PUTdata (it may come from a malicious agent). Why would you program the validation twice? The same goes for aggregations, filtering, sorting, utilities etc. - not to mention prerendering the page on the server side for faster initial load or some other purpose (SEO optimization).
Validation has to be done on the server side no matter what. In the browser, you can also validate and if the server round trip is unbearable you can AJAX validate. At best you're only able to do some validations in the browser without hitting the server since you can't easily check for uniqueness in the database or rules other than "meets these general form requirements".
Aggregations come from data, in the database. Unless you're hitting API's on the server side to pre-render then you've got one set of logic accessing a database and one set accessing the API's. Otherwise you're just hitting a bunch of APIs from the browser meaning the data access logic is on the back and the API access/AJAX logic is on the front.
Filtering allows you to filter based on what's on the page, so again, unless your entire database is in the browser or you're hitting an API on the backend instead of a database so that you can use the same API on the front-end, it's separate logic. Sorting...what's already in the client vs data in the database.
Which leaves pre-rendering for single page apps on the server side for SEO purposes so you can use the same rendering logic on the client side. That just about the only legit use case and that can be worked around simply enough by just allowing whatever server side language is rendering the template to inject placeholders for the client to be able to reuse.
> So instead of a zillion competing options with various tradeoffs, just pick the language you already use anyway (JS), which also has various tradeoffs, with the big plus that you don't introduce a language chasm along arbitrary technical boundaries such as some length of wire between a data center and the user.
The one use case where Node stood out as a great solution was for an API front-end because of the non-blocking I/O aspects and in practice projects get to be unmaintainable callback soup. Which is why the second you try to do anything serious with Node, you find out about Go and never look back.
The reason you don't just pick the language you use anyway is because the only reason it's "the language you use anyway" is that it is forced upon you. If anybody had a choice in the matter they wouldn't select it because it's a terrible choice. That's like asking people why they don't just use Windows servers since they already use Windows desktops anyway...because virtually all of those other options are much better choices for the task and there's no reason to start a project with a handicap.
2. Non-blocking I/O, which is admittedly very worthwhile on the server side...however, Java still blows it out of the water for concurrency and Go is currently doing everything that Node does here, but better.
There's a 4th reason that gets tossed around that I've never seen actually validated with the idea of "reusing code on the backend and the front-end" but I've never seen a case where that was actually a good idea since it involves exposing so much logic.
On the backend, you have Java, Go,
Actually, that will only help you with web based stuff. Go doesn't do any UI stuff (that I know of, but I haven't looked hard) so it might not be what you're looking for.
Go is still young so if you're looking from a "language saturation" standpoint, it's not where you want it to be yet but it's gaining traction fast. It will be familiar from a typing standpoint and as a language it provides excellent concurrency, which in certain types of applications becomes a really big help. By learning Go you'd be providing yourself with a language that helps solve a complicated use case rather than just another language that does exactly the same things as other server side languages. It's compile time is almost instantaneous which is similar to a scripting language. Runs well on both Windows and non-Windows environments too, which will make it easier to use it along side your existing
PostgreSQL as a database is pretty much amazing. Everything you like from SQL Server is there without a lot of the stuff that you don't. Here's a writeup that I did a few months back breaking down what's great about PostgreSQL in as concise of a post as I could. http://www.brightball.com/post...
Since this is a specific "what should I learn based on my current background" type question, that's my recommendation for YOU based on the post.
This is correct. For most people if you never run out your charge the only time the engine will turn on is as a precaution against stale fuel.
The Volt is an Extended Range Electric Vehicle. The presence of fuel so it can be used on long trips is great. I took mine on several trips greater than 350 or so miles and being able to refuel on those rare occasions was really helpful.
Most hybrids like the Prius are just very powered down to get as much as possible out of a gas engine. The Volt is like driving a car with a V6 in it. I got 3 speeding tickets in mine because without the engine vibration I just didn't realize how fast I was going. Great, great car. The lease just ran out and I miss it. Working from home full time now makes it really difficult to justify getting another though.
You're right. Here's a solid overview of the type of technologies that Docker impacts which appeared on Hacker News a couple of months back http://www.brightball.com/devo...
Is offset that tax shift by an amount of money equal to how much is spent employing people in that country. Same idea, but provide an incentive to hire more people locally.
I've been wish the US would do something similar to use taxes to incentive employment. Right now there's so many additional rules, fees, and legislative attachments to hiring people that the government is virtually incentivizing companies to favor automation.
jRuby totally changes the dynamic for Ruby, no question. It solves virtually every non-imaginary production problem that Ruby's historically had WHILE adding the entire Java ecosystem to the mix.
Python is very heavily tied to C. Ruby seems to live in both worlds much more successfully.
Yes. Clearly. Visual Basic was a sysadmin language, a standard bearer that's copied in every other language, used to write DNS tools, ported to run on the JVM and use Java libraries, and the DSL language chosen as the basis for most of the infrastructure management tools used today for the cloud....
Exactly the same.
Umm...no. This is the stuff that makes no sense to me. Everything there is 100% accurate and even without Rails, Ruby itself is just about the ultimate utility language. There's legitimately no reason to avoid learning short of "I hate Ruby for no apparent reason".
Case in point, comments like this one.
It's because it's hard to find people. For whatever reason, despite the demand, people get violently offended that Ruby is the 99% solution instead of the 80% solution and stubbornly refuse to just learn it. Short of fringe, extreme performance tuning use case that somehow jruby didn't manage to solve...Ruby is just about the ultimate general purpose language. From sysadmin to web to DSL to backend to volume and utility of open source libraries to a community focussed on developer efficiency and happiness...ruby is "the language". There is no other language out that that addresses all of these so effectively.
Ruby is an excellent language that makes a lot of very complicated things in programming simpler to achieve thanks to run time manipulation of the core language. Specifically things like dependency injection and modifying existing libraries to suit your purpose without having to touch the code of the core library and break your upgrade path or extending the class and then replacing every single usage of it with your subclass. This accelerates problem solving, eases the use of smaller pieces of code and the ENTIRE language and gem ecosystem is what it is because it takes advantage of it.
In so many cases, what companies use is based on who they can find to hire because demand for programmers is so high right now that becomes a determining factor everywhere.
The only language out there that is legitimately picking up steam in the "I am different in a meaningful way" sense is Go. In the mean time, believe me, all this Ruby code isn't going anywhere. Regardless of whether you're talking Rails, Puppet, Chef, Capistrano, Foreman, RubyDNS, the Gem ecosystem and every other standard bearer for how to do things that are emulated across other languages these days...Ruby's everywhere.
When I learned that on the fly I could inject or replace a method in a core object at load time and in 3 lines of code solve a system wide problem no matter what design pattern, coding style, or good/bad architectural decision was made by a previous developer it pretty much changed my life as a programmer. There is virtually no programming problem in a ruby application that makes me grumble because I "have to deal with it" or it will "take years to fix" because it's so easy to fix. This applies with open source libraries or legacy applications. That's why Ruby is awesome and the biggest reason that I'll never understand the people that want to hate it so much.