Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror

Slashdot videos: Now with more Slashdot!

  • View

  • Discuss

  • Share

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).

×

Comment: Re:Why Force Your Children to Live in the Past? (Score 1) 734

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.

Comment: Re:This is not a mindshare battle...at all (Score 1) 319

by MillerHighLife21 (#49087583) Attached to: Java Vs. Node.js: Epic Battle For Dev Mindshare

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.

jQuery did more to change this than anything simply because their approach to client code allowed for graceful degradation. Javascript as an enhancement but not a dependency that could naturally fallback to working on HTML alone. This has always been a really solid approach.

Javascript's prototyping structure has it's merits, specifically for working within a browser and attempting to minimize object space for what's loaded in. I appreciate that, however, the language itself has a number of concerns when compared with other server side options.

Comment: Re:This is not a mindshare battle...at all (Score 2) 319

by MillerHighLife21 (#49083787) Attached to: Java Vs. Node.js: Epic Battle For Dev Mindshare

> 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.

Because javascript is unnecessary unless you're building a single page app meaning there's a decent chance you're not using it anyway. If you're predetermined to always use javascript, it's usually a good sign that you don't need to be making decisions about server side code.

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.

If using something other than javascript on the server side introduces a language chasm, I'd hate to see what chasm considerations database selection process looked like.

Comment: This is not a mindshare battle...at all (Score 5, Insightful) 319

by MillerHighLife21 (#49082539) Attached to: Java Vs. Node.js: Epic Battle For Dev Mindshare

Javascript, despite it's popularity, is a terrible language. It's popularity is due to one thing, it is embedded in the browser. If you could just pick your own language to embed in the browser, you'd never hear of it. The entire level of popularity from Node.js has come from 3 things:

1. Frontend (read, client side, not "PHP") developers who get the idea in their head that they already know javascript so wouldn't it be great to use it on the server too so they don't have to learn another language
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.
3. AJAX development, making JSON popular, leading to JSON based NoSQL databases like Mongo (which is great at what it does) and then uses Javascript for processing in the database too because of JSON

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 frontend, yes, Javascript everything...because you have no other option. That's like saying black was beating green for mind share with the Model T Ford.

On the backend, you have Java, Go, .NET, Ruby, Python, PHP, Clojure, Groovy, Erlang, Perl, Scala...all of these languages exist with different benefits and different trade offs.

If anything, a huge piece of Go's skyrocketing popularity is people wanting the non-blocking I/O perk of Node for certain use cases without all of the pain that comes from dealing with Javascript.

Comment: I'd consider Go and PostgreSQL (Score 4, Informative) 264

by MillerHighLife21 (#48804891) Attached to: Ask Slashdot: Linux Database GUI Application Development?

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 .NET stuff if needed.

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.

Comment: Re:nope (Score 2) 426

by MillerHighLife21 (#48795951) Attached to: Chevrolet Unveils 200-Mile Bolt EV At Detroit Auto Show

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.

Comment: What they should be doing... (Score 2) 602

by MillerHighLife21 (#48514781) Attached to: UK Announces 'Google Tax'

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.

Comment: Re:If it's losing steam it's because (Score 1) 291

by MillerHighLife21 (#48467753) Attached to: Is Ruby On Rails Losing Steam?

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.

Comment: Re:If it's losing steam it's because (Score 0) 291

by MillerHighLife21 (#48467627) Attached to: Is Ruby On Rails Losing Steam?

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.

Comment: If it's losing steam it's because (Score 1, Insightful) 291

by MillerHighLife21 (#48467437) Attached to: Is Ruby On Rails Losing Steam?

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.

The demand has been there for years and because the demand is so high, it means Ruby people are hard to find. For many companies that means that they'll end up using whatever they can find people to code with. You'll get people using all manner of PHP frameworks. The "hey, I know Javascript! Let's use Node!" crowd. The Java EVERYTHING crowd that for some inexplicable reason would use languages that isolate you to only running on the JVM like Groovy, Scala and Clojure instead of using jRuby for all of the same benefits with code that is portable OUTSIDE of the JVM. Then there's the .NET crowd who are in their own little world (but will embrace Node and Go because they work well in their world too).

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.

This process can check if this value is zero, and if it is, it does something child-like. -- Forbes Burkowski, CS 454, University of Washington

Working...