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.

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.

Thanks! From what I understand it's pretty rare for a company as small as that one to get phished as heavily as it was. Having full responsibility to deal with something like that among other development priorities was a unique experience.

Through their servers. You can't do it for your domain though (or at least you couldn't last year). Might have changed since they started offering their Mandrill product and virtually MUST have that capability.

Also means you should avoid those services. My company had to rule out MailChimp for email specifically because they wouldn't support those protocols. It's unfathomable to me that a company who's entire business revolves around sending email does not actually have a way to let you use these.

I implemented the strictest controls possible for a site that was being heavily phished and it worked very well. Here's the things you have to understand about DMARC, DKIM, and SPF (since SPF matters to DMARC too).

As a basic overview, here's what these do.

SPF = Only allow emails from specific domains / ip addresses
DKIM = When an email arrives, verify the signature with the domain it claims to be from to ensure it actually came from there
DMARC = How strict should we be with SPF and DKIM?

DMARC in itself isn't an actual verification system. What DMARC does is allows you to tell mail servers exactly how to handle emails that do not pass SPF and/or DKIM checks. Without DMARC, mail servers have to guess and basically follow their own rules. If you've taken the time to document where email from a particular domain comes from (including 3rd party services), ensured that your SPF includes everything, and have verified that all emails are signed with DKIM then eventually you can be strict enough with your DMARC settings to say that anything not passing both SPF and DKIM can simply be trashed. That's what the strictest setting looks like. You can also tell mail servers to send it to the spam folder, just in case you missed something. You can tell it to treat SPF strictly and ignore DKIM or vice versa. You can tell it to apply your DMARC rules to a percentage of your emails (to make it easier to transition into to using it with a small group of messages). You can also have providers send you an XML based email of the days activity to see how messages were handled from different services and where those messages originated. The reports can be a pain to make sense of but once you have everything setup properly you tend to stop looking at them.

It's important to remember, because SPF if easier to implement since it's just a DNS rule. For DKIM you have to actually sign the email before it's sent which may or may not be possible from all of your various points of email origin. DKIM is better, but that makes it more complicated. And that's why you have to have something like DMARC so that you can tell mail servers just how thoroughly those rules have been implemented.

The site that I implemented it for was a very old site where people managed high dollar transactions over email. Phishing was RAMPANT but even more so because there was a good chance a phisher could pass off an email as actually coming from our domain. The combination of 3 protocols in strict mode stopped that completely. It didn't stop PHISHING, but it did secure our domain against it. After that phishers had to use other domains, leaving off a middle letter, trying spelling variations, etc. This gave us the ability to work with registrars to either buy the domains or report the domains for abuse.

As an early poster said, you can't completely stop phishing but there are preventative measures you can take to protect compromised accounts.

After that we took additional steps to secure users accounts. We started recording ip addresses with all logins or return visits along with geographic data from MaxMind. Once we had enough sample data to create a general point of origin, we started locking accounts if they were accessed more than 200 miles from their normal center point and always if they logged in from a different country. As soon as the account was locked for a geographic reason, we sent users an email notifying them that their account had been accessed from another country or outside of their area and that if this lock was in error, they could click a link to disable that function for 2 weeks while they were traveling. Otherwise they should change their password. Users really appreciated it. We expected some usability frustration, but overall these users were very happy to know we were watching out for them.

People also tried to create fake accounts on the system to initiate transactions. For that, we took a page out of Fark's playbook. On Fark, when you get blocked / banned you don't KNOW you've been banned. You can keep posting away but nobody else can see it. We did the same thing when we recognized fake accounts through an assortment of internal mechanisms, including CAPTCHA to make sure these guys had to work by hand. We'd let them continue doing whatever they wanted for a period of 7-10 days after we spotted them but nothing their accounts did actually reached any other users. If we just blocked the account, they'd just create a new account so it was key to make sure they didn't KNOW they'd been identified. After 7-10 days we'd actually lock the account so they knew we "caught them".

We used to keep a metric report for our own entertainment to show how much time these guys were spending trying to scam people AFTER we flagged their accounts. It was incredibly amusing to watch them waste 6-8 hours a day for months on end after all the hassle they caused us.

I have no idea where to even begin with this. You can't possibly believe that.

It's good advice in terms of the math, but it's not in terms of the reality of hacks.

What's most important is that you aren't using the same password in multiple places. Otherwise, no matter how you chose it, if a hack of a service exposes that data then your email and password are going to be tested against a plethora of other sites just to see where else you used it. If you're using a password manager and creating random passwords that even you don't know, then if one service is compromised you only have to worry about updating your password for that one service.

At some point, we need to start giving huge tax discounts to corporations based on how much they spend on labor. Right now we seem hell bent on making hiring people as expensive as possible.

Also, give huge corporate tax discounts based on how much you spend on labor. Right now this country seems focussed on creating policies that incentive employers to reduce their workforce by making employees more expensive. Stop that and start rewarding employers who ACTUALLY create jobs.

This has REPUBLICAN backers. It's called the Fair Tax.

The Fair Tax involves eliminating income tax, replacing it with a federal sales tax, then giving ALL legal US citizens a check every month to offset the tax against basic needs. At the time it was originally proposed I think the suggestion was a $400 / month check.

To make it a basic income and take it a step further, bump it up to $700 / month (effectively doubles the minimum wage) and reduce social security and welfare payouts by the same amounts. Eliminate unemployment since everybody gets this now and institute a flat 10% income tax to go with the 10% federal sales tax.

The combination of the two creates a tax system that ensures if you're in this country, you pay taxes. If you're a citizen, you get the payout.

The most important part of the equation is eliminating unemployment. In some parts of the country where the cost of living is low there's a lot of unemployment abuse. Unemployment gives somebody the choice of whether or not to continue having all of their time while getting a check or giving up that check and going to work. That's important, because under this structure if you go to work you make more without giving anything up. Period. Part time work becomes much more viable.

Although, on further examination it looks like it is structured almost EXACTLY the same.

No idea. Hadn't seen XL before.

I saw that EnterpriseDB offered to support XC though. http://www.enterprisedb.com/se...