Stop Treating Digital Weapons Like Biological Weapons
Our Chief Code Whisperer, M. Scott Ford, shares his thoughts about the WannaCry/WannaCrypt malware and reinforces a call for a Digital Geneva Convention.
Our Chief Code Whisperer, M. Scott Ford, shares his thoughts about the WannaCry/WannaCrypt malware and reinforces a call for a Digital Geneva Convention.
Recently, I was pairing with a developer on a client's team. He was stuck and couldn't figure out how to fix the problem. I had a look and guided him through a series of bash and other shell commands until we found the solution. After thanking me -- he had been at it for hours -- he asked me 'How do you know all of this?'
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 this two-part post, I explain what are interactive notebooks, why we'd want to use them, and how to get started with the nteract desktop program.
A few years ago, in a screenwriting class, our instructor asked us the following question: “How do you prepare yourself to write? What things do you do to create an environment that’s conducive to writing?” This was the third quarter with my fellow students – first class with this instructor – and I was comfortable speaking my mind. My answer went something like this: “I don’t have time for that. I only have one hour at lunch to write. So I turn on my laptop and I write.”
Software engineers usually don’t deal with binary data directly. Most data is stored in well-known, open-format files and manipulated through libraries that know how to handle them. So bits and bytes are almost never in a developer’s mind. Apparently, they even scare people: all that random, unreadable mess not meant for human consumption...
While doing his undergraduate at Virginia Tech, my son Tyler worked at 100-Cents (or some such store of similar name). He went on to graduate with honors and become a CPA at one of the Big-5 accounting firms. Then, he got an MBA at Darden (one of the top MBA colleges in the country). And now, he is an investment banker that manages the sales and acquisition of companies valued over a billion dollars. So he’s doing OK. But, instead of telling him I’m proud of his accomplishments, I chide him saying: “I had hopes of you becoming a manager at 100-Cents.” Which is not necessarily a career that you spend $250,000 on education to achieve.
“You should strike,” he said. We were laying in bed, catching up on the day's news when I saw an article for a general strike being organized to bring awareness to the contributions of women, both at work and at home. I mentioned it to my husband, Scott, who is also my business partner. Or as he likes to point out, I'm technically his boss as I'm the majority shareholder.
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.
I'm getting very comfortable with Hyper-V on my Windows 10 Pro machine, and I'm really happy I have this as a development environment. After updating Corgibytes' Chief Code Whisperer, Scott, about where I was at for a current client, we talked about remote machines and Azure. This lead to attempting to upload a VHD to Azure.
Stop me if you’ve heard this one... After spending years understanding the inefficiencies of a marketspace, a brilliant subject-matter expert strikes out on their own as an entrepreneur. Using their grit, knowledge and connections, they build their business. Soon after, investors and paying clients follow to benefit from the new product.
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.
Does this sound familiar? A nervous, yet wildly confident singer prepares to wow competition judges. Meanwhile, a clip of them telling the camera some heart-wrenching story wraps up. The frame ends on some mention of this being their last chance at happiness, and this is their Hail Mary plan to finally follow their destiny. The music starts. The singer wails.
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.
A while back, I wrote a blog post about IDEs vs text editors. Ultimately, I was really writing about whether using an IDE made me less of a software developer. My conclusion was that while it definitely didn't make me less of a software developer, there were things experienced software developers did that I wasn't doing that were worth learning. So I've been trying to do what it takes to earn the right to call myself a “software developer.” I've learned a lot in the process: about shortcuts, vim and bash, but, mostly, about myself.
Recently, I was on the STEMxm podcast, where the host asked me a simple question: “You’re a woman in tech, you’re also a business owner and you have small children. Do you have any thoughts on the balance question and managing all of this?” Let’s first address the maternal bias that comes with just asking the question. Scott never gets asked how he “does it all” as a father, but I do all the time as a mother.
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.
Even though Conway's Law originated in the software world, it's easy to extrapolate the idea to pretty much anything an organization produces, including content. I would even say that it’s not only the communication structures that permeate the content, but also the organization’s values and culture.
Do you use a GPS navigator on road trips? Or a GPS watch to track your run or bike ride? Then, you’ve been exposed to GIS. GIS stands for Geographic Information System. Even if you haven’t used the two items I mentioned, I’m confident you’ve experienced it, as most everyone has used GIS in one form or another. The most common usage is the maps application on a smartphone.
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.
A few months ago, I wrote about how a small group of engineers with a noble idea created open source software and changed the world. The idea proved the collective intelligence model for software development and allowed for an explosion of software products. In this post, we will explore how those early gains accelerated quickly through cloud computing and the birth of Software as a Service (SaaS)
If you've never tried functional programming development, I assure you that this is one of the best time investments you can make. You will not only learn a new programming language, but also a completely new way of thinking. A completely different paradigm.
If you sent me an email today, you’d get an autoresponder that starts with a quote from Jan Tschichold. What better quote to feature during my own “White Space” time in December and January, during which I’ve purposely limited my meeting schedule and am only checking email once a day.
We're interviewing people to join the Corgibytes team. When I mention this to others, I hear a wide range of opinions on what exactly those technical interviews should look like. Over the years, I've experienced the gamut myself. Some were intensive. Some thought-provoking. Some... bizarre.
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.
Do you remember the scene in Silver Linings Playbook when our main character portrayed by Bradley Cooper, Pat Solitano Jr, finishes reading his Hemingway novel (if you haven’t, caution, strong language)? I’ve done that. In my mind only, sure. But I have uttered swear words after finishing books, movies, TV series, and even blog posts.
After years of scoffing at talk of prejudice in the information technology field -- as a white male with good hair --, I'm starting to call prejudice against my being old(er). It’s true: age discrimination is a real thing.
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.”
Working on a remote team, we need to be extra creative to find ways to socialize, get to know each other better and even share a few laughs. Those natural moments like a quick hello-how-are-you in the hallway just don't happen. That's why we've enlisted the help of our very own custom bot member, Ein.
Our beloved Chief Code Whisperer, M. Scott Ford, was invited – again – to be a guest lecturer at the Harvard Extension School. Watch this FREE class on continuous integration, continuous delivery, and DevOps from our own “Bob Vila of the Internet” (and special thanks to Trainer and Coach Richard Kasperowski, Teaching Assistant Wendy Wong, the Harvard Extension School, and the amazing students in the Agile Software Development class).
Over the past year, we’ve written a lot about empathy on this blog. We’ve discussed empathy-driven development, the empathy spectrum, and the fact that empathy is a skill. And like any skill, it can be learned and takes practice to build. But perhaps one of the most important posts was actually an update to an existing one.
As a person who has worked in enterprise software and technology for almost 20 years, I always marvel at how different this industry looks from twenty, ten, or even just five years ago. Over the last two years, the landscape has shifted for classic enterprise vendors like IBM, Oracle and Microsoft in dramatic ways, but the massive tectonic shifts we now see have only been due to the incremental changes deep below the surface for decades.
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.
Last Friday, I caught a friend’s band at a local pub. I know how it sounds. “A friend’s band. That’s cute.” Except it’s not like that. This friend is an exceptional guitarist. When he plays, it’s like watching Joe Satriani, Jimmy Hendrix, Slash. His instrument becomes an expression of his soul.
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.
When building a feature or fixing a bug, you will be reading the code that exists. One thing I do often is ask, “Why was this done this way?” Programming is not a binary profession. Fuzzy logic would be a better way to explain how problems get solved. Just as programmers' experiences vary, you can find many solutions to get from 0 to 1. So, when I want to answer my initial question, I leverage git blame.
Is your code difficult to work with? Chances are, it’s time to get rid of code you don’t need. That can be a scary prospect, but the rewards can be well worth the effort. Recently, I was inspired by KonMari, a technique for decluttering physical spaces, to help me visualize how to refactor codebases to make them easier to work with.
Amazon OpsWorks is an excellent, low-cost option for Platform-as-a-Service hosting. OpsWorks provides relatively easy-to-use UI mechanisms to manage, deploy and host applications on AWS EC2. Corgibytes uses OpsWorks to host both Rails-based and Angular-based servers for one of our clients. Configuring the Rails-based OpsWorks hosts was easy – mostly because there are tons of blog posts on how to do it. But setting up the Angular server was a bit more problematic for me, as my good friend, Google, provided little help.
As our blogging efforts increased this past quarter, our Lead Content Whisperer, Jo, requested a mechanism to publish blog posts in advance. I was happy to volunteer to build a simple solution using the tools we already had in place.
Markdown, GitHub, Atom, Jekyll, rubber duck, refactoring… Those are just a few of the terms I had never heard before starting here at Corgibytes. Yes, I had heard of a rubber duck, but not being a rubber duck. In case anyone’s thinking “Oh, she’s one of those drips,” let me stop you right there. I’m a knowledge-thirsty geek.
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.
One of the comments I get frequently is how the culture of Corgibytes feels distinctive. Clients enjoy working with us, employees are happy and not stressed out, and the company just kind of purrs. This didn’t happen by accident. It’s the result of lots of intention and implementing specific strategies.
One of the many cool things that we do here at Corgibytes is yoga classes three times a week. The word “yoga” conjures up images of fit ladies on their mats in a classroom, and the teacher in the front doing crazy poses. You probably don’t imagine a group of people, each one sitting at his own desk, on different continents, connected online with the teacher and doing the crazy poses in their chairs. Well, that’s how our yoga classes are, and as unusual as this might sound, it is amazing. I love yoga classes!
My first job out of college took me 1,500 miles from where I grew up. After a year of working there, I spent most days working from home along with my other co-workers. The team commuted to a single point about once a week since we enjoyed hanging out with each other and it helped us catch up on what we were working on. Shortly after this, I had a desire to move back home to spend time with family, but wanted to keep working with a great team. That wasn’t a problem and this soon unlocked the awesomeness that was being remote.
Eight years ago, I went to my high school reunion. I had worked successfully in the field of sales and marketing since graduation. I had started my own consultancy when I was twenty-four which helped clients with sales and developing their “brand voice.” I was the human voice behind businesses large and small. At the time I loved my job and had no plans on leaving my industry. At the reunion, I looked around, and after the mandatory mingling that comes with being a social butterfly, I locked eyes with someone I recognized. He was leaning against the bar, drinking a soda, and looking utterly uncomfortable. Yep. That was none other than M. Scott Ford.
“How would you rate yourself as a programmer?” They always have to ask THAT question in job interviews. And I hate it. So much. Why do I hate it? Because I know they won’t like my answer. But what am I supposed to do, lie? Nope. I have to be honest. Which is why I take my time before responding. I take a deep breath, look deeply into the eyes of the interviewer, and, finally, I say: “Average.”
One of the great benefits of working for a small company like Corgibytes is the ability to adopt change quickly, especially in day-to-day operations. Some of the biggest improvements in operational efficiency have come through our virtual office manager and assistant, a little canine chat bot we call Ein.
“You’re so lucky! You get to work in your pajamas!” That’s the most common reaction I get when I tell people I work from home. I don’t work in my pajamas. I’m pretty sure none of my colleagues do either. And if they do, they’re not sharing it. Obviously, it’s a personal decision, but, for me, when I’m in my pajamas, I want to chill, not work. And although my “office” is at times my recliner, I am working, not lounging.
My dad is a self-described contrarian and eccentric. I love that about him. He doesn’t ever do something because that’s the way you’re “supposed to.” He’s also incredibly driven and energetic. He’s a fixer. If he sees a problem, watch out. If it aligns with one of his passions, he’ll put all of his energy towards finding a solution.
There are 10 types of programmers: those who use an IDE, and those who think that the ones who use an IDE are not real programmers. I'll start by making it clear that I belong to the first group and do care _a little bit_ about the other group’s opinion. So I decided to dig a little deeper and collect opinions about this topic. The choice was either to become a real programmer and switch to a text editor, or to reinforce that I am a real programmer who uses an IDE!
Stereotype threat is especially pervasive in technology. For women, this manifests as the “girls are bad at math” stereotype. For men, it's more often “you have no social skills.”
One of the most important expectations we have for all team members is that he or she keep a daily journal. While I was skeptical when we first started this practice, now I can’t imagine our team functioning without it.
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.
Docker's new Distributed Application Bundles are an exciting development. They have the potential to be revolutionary for describing the structure of a distributed application and making that description something that can be deployed as a single file.
An experience report of using Mob Programming at Corgibytes. Trust, which was already high, became even stronger. Clients became more engaged and several commented on how much value they were getting from working with the Corgibytes team. When clients felt like they were getting more value, sales, grew, too.
I had the pleasure of keynoting at Ruby Nation where I expanded on one of the core values at Corgibytes: Communication Is Just As Important As Code. This post is pretty much a transcript of my talk. I got great feedback and am looking forward to presenting on this topic more.
If we want our developers to have more empathy for our customers, we as employers need to have more empathy for developers. We need to cast off the stereotype of good developers being only those people who are emotionless, data-driven, Spock-like caricatures, and embrace the fact that as humans, we all experience emotion.
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.
At Corgibytes, we have five core values: Think of Others, Calm the Chaos, Communication is Just as Important as Code, Adopt a Growth Mindset, and Craftsmanship in Context. These values are the nucleus of our company: the center of all decisions, big and small, for the Corgibytes executive team and staff. Here's a look at each one in detail.
How do you interrupt your engineers appropriately? At Corgibytes, we use Inception Layers do describe how interruptible we are.
When we put empathy at the center of our technology, human connection becomes stronger. Infusing empathy throughout your organization and development strategy can have profound positive impacts on customer loyalty, employee retention, and vendor service.
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.
Estimates are useful. They help business owners predict and control their budget, scope, and timelines. Right? Well, not always. Over the years, we’ve learned that there are some projects where estimates work great and others where it’s a disaster.
One of my current projects' Rails application is hosted on AWS OpsWorks. OpsWorks is a lower-cost alternative to Heroku and EngineYard that still provides a full-suite of features, from deployment to scalability and fail-over. As with most Rails applications, this application requires background tasks.
When I was interviewed by Corgibytes for a lead developer position, I was asked who were my role models. I responded David Heinemeier-Hansson (DHH) and Kent Beck. I expounded: DHH because he is a business developer rather than a computer scientist and he has great ideas about achieving excellence while maintaining a work/life balance. And furthermore Kent Beck because, as brilliant as he is, he still sees himself as a coder. Whatever.... The thing is, I lied.
While it's true that there are many software developers who do enjoy starting with a clean slate, there is also a group who loves working on making existing applications better. Rather than starting from scratch and building an 80% solution, these developers are ideal for taking over a project once it's become stable, and nurturing it for a long time. Neither developer is better. Both are needed in the software world. You just need to understand when to use each one.
There's been an interesting case winding it's way through the court system in the United States over the past few years. The outcome of the case is hinging on one small question: Can you copyright an API?