When we talk about localizing or internationalizing an application, we often focus on just the wording of labels and other text. However, there is more to it than just “what is the translation of this word”. Take for example this real world story.
I often encounter software projects that have absolutely no automated tests. This is rarely because the development team feels that authoring tests is a waste of their time. It’s most often the case that the team would love to have automated tests. If you feel like your project or team is stuck when it comes to automated testing, then I’d like to provide some guidance and specific techniques for how to get started.
As mentioned in my introductory post on the topic, while doing research for another article, I dug into nteract pretty deeply. It's how I like to learn about new things. nteract ships with the ability to run JavaScript code in notebooks, and I was wondering if it had the ability to do more than that. What I discovered revealed an entirely new level of awesome for using interactive notebooks.
npm is not only the package manager for JavaScript, it's also used to set up tooling around your codebase. Linters, transpilers, testing, and servers. Everything can be configured and run using the very same thing. Basic usage is really simple, too.
Have you ever had one of those “down-the-rabbit-hole” experiences, in which one idea sends you careening through a wormhole of thought? Such a journey often yields unexpected results, yet the “mind map” of your travels can actually be even more surprising. Well, it was one such “Eureka!” moment that convinced me of the parallels between the classic Hello, World! program and Test-Driven Development (TDD).
In my last blog post, I explained why metaphors are so important and how they can help raise our chops (and our hopes) when it comes to influencing the business side of things. The Seat Belt metaphor used in my previous example may have worked great for some, but not for others. Keeping a few different ones at the ready helps you adapt on-the-fly and better connect with whomever you’re speaking with. Another one of my favorite car metaphors to use is inspections.
A commenter on dev.to recently posed the question, “What should someone without a computer science degree focus on learning?” As someone who was lucky enough to know I wanted to study computer science as an 18-year-old, I thought I’d weigh in on the topic. I had some ideas floating in my head about what I considered most important, but also decided I’d poll my colleagues to get their opinions.
One of the most mundane and frightening tasks for many developers is writing integration tests. It's a time-consuming, fragile, and often difficult and frustrating task to accomplish. What makes it even worse is that it quickly gets out of hand and breaks often, which leads to frustration and dropping the idea completely.
Code refactoring, as defined by Wikipedia, is “the process of restructuring existing computer code — changing the factoring — without changing its external behavior.” As such, refactored code should introduce no behavior changes. Otherwise, you're not refactoring. You're refactoring and doing something else.
About a year ago, I had to code a Rails application to handle bounce notifications from AWS SES. Amazon Simple Email Service is ridiculously easy to configure and use in a Rails application. As the instructions at the GitHub gem page explain, all you need to do is add the aws-ses Rails gem and create a configuration file called config/initializers/amazon_ses.rb that contains your Amazon credentials (soft-coded of course). But, if you need your application to handle bounce, complaint, or delivery notifications, things get a little more complicated.
At a CTO Roundtable in NYC, I sat with several other technical leaders. During our session, we listened to each other’s current challenges and responded with empathy and advice. When I responded to one of the concerns with the advice “influence the CEO to adjust the schedule,” I was caught off guard by everyone’s response. Our former respectful and inquisitive dialog broke down into sneers, laughs and eye rolls.
In my role as Director of Operations at Corgibytes, one of my responsibilities is automating and optimizing our day-to-day tasks and workflow. As a result, one of the common patterns of my work is gathering, manipulating, and presenting data of various sorts. Thankfully, much of the data I’m gathering is accessible via API, which means I get to use one of my favorite technical tools: Postman.
First, a confession: I recently wrote a blog post about unit testing an Angular application. Well, as it turns out, what I was in fact doing was trying to convince everybody of the joys of Angular testing. Including myself.
I was looking for inspiration for my next blog topic and read through some of my old posts. I came across one called “Confidence From Your Code” that originally appeared on Femgineer in 2014. I thought: “Perfect! It's been a few years since I wrote that, I now work with Corgibytes and have even more legacy code experience, I'll update my thoughts.”
If you love old architecture and castles, you'll fall for Bratislava. Easily one of the most beautiful places you can visit in Europe, this Slovakian capital is small enough that you can drive/walk quickly to most places, but big enough to fill your schedule for a few days. It may surprise some to find out that, when it comes to software development, the area is very quickly becoming one of the European tech hubs. Last month, Bratislava hosted two big conferences in one week.
Over the years, I've heard a lot of different attitudes regarding code that’s going to be thrown away. Let me be clear here. I’m not talking about code that we think might get thrown away. I’m talking about code that we know will get thrown away.
I recently started writing tests for an Angular application, so I had to go through the entire process of researching the tools, installing and setting up the libraries, writing the tests and learning the tricks. Here's what I discovered.
In an era of omnipresent frameworks, libraries and tooling, it may be hard to decide what tool to use and when. I know from experience, that the first thing you do, once you decide to write a module or CLI tool, is set up an environment. Some people love it, some hate it. But no matter on which side you are, you’ll most likely end up spending way too much time doing it, polishing every aspect of the setup.
Do you ever refactor your test code? If not, I hope you consider making this part of your normal practice. Test code is still code and should adhere to the same high standards as the code that's running directly in production. As important as it is, refactoring your test code is actually a little risky. It's very likely that you could turn a perfectly valid test into one that always passes, regardless of whether or not the code that it covers is correct. Let's explore a technique for protecting against that possibility.
The process of renaming models in Rails can be very error prone. To just start renaming files and changing class names and search-replace variable names is fraught with peril -- so I figured having the ability to repeat the process, in essence fix my scripting mistakes and “do-over,” was important.
I’m going to list tools and strategies that a state-of-the-art application development project should be using. Essentially a portrait of the infrastructure of a successful IBMi application start. I’ll start with suggestions on dealing with the daunting task of selecting a language and framework. Then, I’ll recommend tools for source control, testing, editing, collaborative communication, knowledge base management, and project management. And I’ll finish with some considerations for RPG integration strategies and database enhancements.
Integration tests? Unit tests? Acceptance tests? How do all these tests work together and what should you focus on first? We like to think of testing as a pyramid. The goal is to build an entire pyramid and keep it growing at scale.