A handy intro article for developers to start contributing more effectively with GIT open source projects
Being the only woman in a room full of guys makes me feel “other,” not having a special club. It’s nice to having a club that’s all women so that there’s somewhere to do go when I don’t want to feel other. If being a redhead made me feel other, maybe I’d like to spend time with other redheads in CS, but it doesn’t, so I don’t.
All too often, people associate improvements in software quality with a very brute force “add features and make it prettier” strategy. This was endemic with the software world for decades, and still is a common go-to “answer” for this quandary. But, most of the time, it’s not the right answer, or at least not the entirety of it.
A recent event has triggered a lot of interest in the debate about the good and the bad parts of Open Source. Oracle’s attack on Open Source. For large corporations who aren’t Red Hat, taking a stand on the topic is far from easy.
Recently we experienced increasing interest in node.js deployments on our service. Especially after our Testing Tuesday series about node.js a lot of people started creating Continuous Integration and Deployment projects on the Codeship.
There’s more to being a good developer than typing - and there's more to typing than just being able to press some keys. It means being good at the fundamentals: knowing the language well enough, knowing your tools and how to use them, knowing how to navigate through code, knowing how to write code – as well as being fast at the keyboard.
When I was in college, I was a pretty mediocre student. I knew that my grades weren’t going to get me a great job after graduation, but I had read that doing research with a professor was looked on favorably. So, it turned out that doing a research project with a professor was pretty good way to bootstrap success, although perhaps not in the way it usually works.
In day to day life as a systems engineer there aren’t too many opportunities to build solutions based purely on theoretical studies or research papers. Entering the world of programming and software development though, a lot of new problems come up that you can find your own solution to.
You inevitably see a lot of unattended, unlocked computers around the place. Naturally the responsible thing to do when seeing such risky behavior is to help the victi.. uh, I mean “individual” understand the risky nature of such behavior.
Every week here and in our newsletter, we feature a new developer/blogger from the DZone community to catch up and find out what he or she is working on now and what's coming next. This week we're talking to Antonin Januska: web developer, designer, and writer.
Developers often tend to think that one coding convention is better than another in terms of readability. The fact of the matter is, there isn’t any proof that one convention gives better readability than another.
A fundamental requirement of Continuous Delivery is that the codebase must always be in a releasable state, with each successful pipeline commit resulting in an application binary ready for production use. How can an architecture evolve without impacting the flow of customer value or increasing the risk of production failure?
We need to change the way we talk about change management. New technologies, practices, and commercial pressures have made traditional change management approaches difficult to apply effectively. There is no tradeoff between rapid delivery and reliable operations.
The Java language cannot differentiate between public API and private stuff. A good example of this terrible temptation is the sun.reflect.Reflection.getCaller(int) method. The Dark Side can be seductive indeed!
We needed to solve two problems. First we needed a way to remember and enforce all the ways the search needed to behave. Second, we needed to fix the collaboration problem. As an engineer, the solution to the first problem was clear: automated testing. As a human being, the solution to the second problem was also clear: better collaboration processes and tools.
The default application generated by Play has examples of unit and integration tests, however it does not demonstrate how to integrate in any Behaviour Driven Development (BDD) frameworks.
I have met several prima donna developers, who were not even that good (see, now I am doing it myself ;-) ). This phenomenon is not limited to Java developers. It's everywhere. Frankly, it is making me sick.
Cloud DevOps and PaaS are paving a path towards teams adopting governance best practices. Teams often follow human nature and take the path of least resistance. DevOps automates activities, and with adequate up-front planning, DevOps can make ‘the right thing to do the easy thing to do’.
When discussing functional programming we often talk about the machinery, and not the core principles. Functional programming is not about monads, monoids, or zippers. Using functions instead of simple values may seem counterintuitive at first, but it is actually a very powerful technique for generalizing code.
Recently Flo talked with Chris Coyier about Continuous Deployment and Automation on the ShopTalkShow Podcast. Many of you might know Chris also from the infamous css-tricks.com site.
The next logical step in my journey across the Entity Framework v6 RC1 after having established a fairly robust data access approach was to imbue my solution with some more “smarts” when it came to entity validation.
It’s hard to have a conversation or hear a presentation these days about DevOps without hearing Netflix’s name being uttered: they’re a poster-child not only for employing DevOps principles. But how did they achieve this? Join us for a chat with members of Netflix’s Engineering Tools and Playback Reliability teams.
We use the IRC hook to receive notifications to the IRC channel (#joind.in on freenode) when interesting things happen on the GitHub repositories. We noticed recently that we were being notified about more types of things happening on some repositories compared to others, so I decided to investigate.
FluentAssertions is an alternative assertion library for unit tests, to use instead of the methods in Assert class that Microsoft provides. It has much better support for exceptions and some other stuff that improves readability and makes it easier to produce tests.