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.
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.
Ideally we should want a society where no one has to work unless they feel like it.
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.