Tag: software development

  • Not My Google Reader Replacement

    Someone suggested Newsblur to me, and I went to their home page. Like many sites, it asks you to sign up, so I decided to give it a try.

    newsblur2

    The import from Google Reader caught my attention, so I clicked it. It asked for an authorization from Google, and then I got this page:

    newsblur

    I have to say. Not only do I now see anyway to understand the difference between $2 a month and $3 a month, but I also feel like this is a bait and switch, given the top banner. This could have been called out on the home page, though I suspect not as many people will click through.

    I’d gladly pay Google Reader $2 a month, but I know what I’m getting. Here I’m not sure, and I’m already annoyed.

    The search continues.

  • Better Coding, More Savings

    Learn to build better systems the first time with a little investment in your career.
    Learn to build better systems the first time with a little investment in your career.

    I’m sure most of us would like to think that we write fairly efficient code. However the reality for many of us might be that we don’t actually know. Many of us use the same patterns and practices that we’ve been using for a long time, rarely changing. When we learn a new technique or find a different way of coding that works better, we tend to then use that method over, and over, and over, and over again.

    I would guess that if many of us profiled our code, and examined the CPU and network bandwidth we consume, we might be surprised at what we find. CPU and network usage isn’t something we are often concerned about. We assume that we’ve bought a machine and we should be able to use as much of it as we can at any point in time. That’s not the best approach, but since we often have more hardware than we need for many processes, it works. It also explains why so many applications struggle as the load increases. They’re not coded efficiently.

    If you’re going to work in the cloud, you better learn to code more efficiently, mostly because it costs money. If you think about your design, you can reduce the amount of resources you use. In the cloud this translates to less cost. In the on-premises world, this means better performance and higher scale. It also means less complaints and phone calls.

    Scaling up an application can be hard, but much of the struggle comes from poorly coding your application in the beginning. Most of us have heard the saying that it takes less time to do it right the first time. That’s true in many situations, and it’s true for your application development. Learn to write more efficient code and use patterns that conserve resources. You’ll find your applications will run better, no matter what type of environment hosts them. If you’re not sure what patterns and practices work well, read an article or ask a question and find out what efficient techniques others use.

    Steve Jones


    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Practicing Deployments

    Practice makes perfect, especially for deployments.
    Practice makes perfect, especially for deployments.

    It’s said that amateurs practice until they can get something right. Professionals practice until they don’t get something wrong. That’s the idea, and while professionals make mistakes, they make far fewer than those that don’t approach their craft as a professional task.

    Many of us in the data industry develop software in some way. Whether we write queries in T-SQL or build projects in .NET, we produce code to accomplish some task. I’d like to think that many of us improve our skills over time, preferably by practicing new techniques and learning from our mistakes. I know some people stick with the tried and true methods without gaining skill over time, which not only hurts one’s career, but also doesn’t give an employer a reason to value their work.

    However the deployment of software, which encompasses more than the developer(s), doesn’t improve in many cases. Deployment includes operational people’s skills, scheduling dowtime with clients, possible even the briefing of support personel. However the whole process is often performed poorly. Deployments fail, or require more time than expected. People view them as a pain, and software deployment tends to happen less often than it could, resulting in a large software inventory.

    There’s a great quote from James Moore on how we can deploy software better: “…deployments are hard, but rather than long-winded planning, they need constant practice, testing and refining, and we could only do this by deploying early.” Red Gate Software has learned that deploying more often results in the company gaining skill in deploying software, resulting in more successful software changes in applications.

    The improvement you make in your software can bring tremendous value to your clients, but only if they can use those features in the software. Learning to push those changes out in a repeatable, professional manner is a great way to ensure your clients and customers trust you to deliver new features and enhancements that meet their needs.

    Steve Jones


    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Serverless Software

    Developers may never see groups of servers like this again in the future.
    Developers may never see groups of servers like this again in the future.

    I love the words “loosely coupled.” At times in my career, I’ve built software and have aimed to ensure that processes, workflows, and components worked well on their own. In the places where I had to work with data or services on different physical machines, I tried to ensure that each item would run separately, and communicate when needed, but wouldn’t fail if another machine was down.

    That’s kind of the idea proposed in the article that says the future of software is serverless? It’s an interesting read, talking about the advances in cloud services that can change the way developers build applications. Developers should think about liking services, and pieces of applications, ignoring the idea their systems are tied to specific servers.

    It’s a future that I think makes sense for most environments. Development shouldn’t be concerned about the size or care of physical machines. Instead they should think about building on a platform of services, and expecting the scale to grow or shrink as needed, without code changes.

    I do think this could be the future in which development proceeds inside companies, as well as for commercial software. However vendors need to sell “private clouds” which function in the same way as the public ones, for those companies that want to control, and invest in, their own hardware.

    Steve Jones


    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.