As the buzzword “devops” has been out in the market for quite some time now, there are a “jungle of tools” built and tagged under the DevOps category. But these tools can be differentiated from the way they function and at what point in time they can be leveraged in a software execution cycle.
"I've got this idea for game-changing software idea, what technology should I use?" These questions have disturbing expectations. There's a Gordian Knot of dependencies that's sometimes baffling.
Today’s example is about what happens when a login page is loaded securely, albeit embedded within an insecure page. This is a common security anti-pattern and you’ll see it on many sites.
From my statistics I know that 80% of my subscribed readers are using Google Reader. It used to be 90% before Google announced that they would kill Reader.
After reading this post I decided to see what my top ten shell commands are...
With DevOps bringing source control to configuration files and publishing to production servers being automated – bringing both code and configuration over on the same time, the difference between code and config has become less than ever (if it even exists).
You know it's a bad day when you experience all of these.
If releases are traditionally major events which require heroic efforts and present real business risk, reasonable people will try to do them less often. But with many business processes this instinct is exactly the wrong thing.
As a DevOps team, we’re trying to maintain our systems in an ideal state, using a whole bunch of tools that affect the state of our systems, sometimes in unpredictable ways. Let’s take a look at a closed loop diagram...
Good intentions can go awry quickly in the world of software development. Imagine this common scenario: there are multiple teams building related projects at the same company. At some point, someone realizes that these teams tend to generate a lot of duplicate code; why not create a common library?
Two colleagues of mine ask a very similar question for interviews, something that as a developer or as ops guys you might find yourself needing to do. Given a log file of a particular format, how many times does something occur in that log file?
Autonomy, mastery, and purpose are some key aspects of motivation at the workplace. What else motivates software engineers?
Goroutines are the recommended method for concurrent programming in Go. They are lightweight and you can easily create thousands of them as they are multiplexed onto multiple OS threads. This blog describes how to make use of HawtDispatch to achieve a similar result in Java and Scala.
There are several variations on the theme of principles of OO programming. None of them include "a few large omnibus classes with nebulous responsibilities."
Investigating the bane of accidental interconnectedness.
It’s been a while since the last major release of TeamCity, and today we’re excited to announce that new TeamCity 8 is here and available for download.
From a user viewpoint, "paving the cowpaths" means that the legacy usability issues have now been modernized without being fixed. The issues remain. A dumb business process is now implemented in a modern programming language. It's still a dumb business process.
Here’s the thing about security – you can’t just “do it” then move on. What I mean by this is that it’s a continuous process and thinking that you only need to just implement some secure coding standards or scan the website once before go live leaves a great big hole in your process.
At DevCon TLV I gave this presentation about code coverage, and how we can use, and misuse it. Here are the slides. You can still catch it in webinar form in a week’s time on the Typemock channel.
If I were to suggest that you implement Microsoft Dynamics AX 2012 in your life, you might give me a strange look. But if you have experience implementing Dynamics AX, and especially AX 2012, for clients or your own company, maybe my suggestion won't seem so strange.
As pointed out by John E. Vincent in his blog Configuration Drift and Next-gen CM, configuration management systems aren’t assertive enough. They are designed to verify the state of a resource at the point they run.
Here's a moderately sized list of Books, Blogs, Articles, Podcasts, and Videos about DevOps, Continuous Delivery, and workplace culture. From the blog "Opus Magnus"...
This is PuppetLabs' State of DevOps survey, which polled over 4,000 IT practitioners. They found out some interesting things, which you can see in the infographic.
Continuous Deployment is an awesome-save, process-changing, team-loving, kudos-earning, stress-reducing capability that any team is wise to implement. OnCheckin is definitely aiming to bring this awesome’ness to as many ASP.Net developers as possible by making it fast and easy to setup.
This week we're talking to Zac Gery about what he calls the biggest misunderstood problem in the development world -- not to mention his love of curling.