This post was imported from an old blog archive, and predates the creation of AdamCaudill.com.
On an average day, I take about 10 screenshots, and upload them to my FTP server. Now, this is easy enough, but it does take a minute, let’s break down the process:
- Press Alt+PrtScr.
- Go to the start menu, and use the “Run” command to open mspaint.
- Paste (and crop if needed).
- Save the image.
- Find the image.
- Open FTP program and upload the file.
Now, while that’s not hard, doing it a dozen times a day is annoying. So I decided to find a better way, or in this case, build a better way. Here’s what I set out to build:
- Simple hotkey to do everything.
- Automatically save the image.
- Automatically upload to my FTP server.
- Require no user intervention other than pressing the hotkey.
So, I built something to solve the problem.
At this point I’m sure you are wonder what this has to do with anything, well my friend, I’m about to explain. One of the core concepts of OOP is code reuse, designing code to be reused in many applications. This is a key to efficiency, but is often something overlooked when starting a project.
With this small project I faced two choices, I could glue, or I could start from scratch. Starting from scratch does give a better understanding of both the quality and the exact functionality of the code. Though this extra knowledge and experience does come at a price: development time. By doing it all yourself tends to draw out development time significantly.
Facing those choices, I opted to go the sticky route, and glue together existing components and code to build this little tool. Finding pre-made classes (that were very well developed) made the tasks of FTP’ing the file, and capturing and saving the screenshots simple. Two lines of code and the most important parts are done.
Careful reuse of existing code made this project trivial, taking only half an hour to finish (and most of that was in making the “toast” popup). Whenever you have the chance, look at how you can reuse code to save yourself some time. It’s often worth it.
This post was imported from an old blog archive, and predates the creation of AdamCaudill.com.
Wow, the summer’s over and I’m finally home!
After spending the last five months in New York (quite a difference from my native Florida), I’ve finally made it back home. Much has happened while I’ve been away, not the least of which is the death of Imspire and a few related projects. While giving up on these dreams has been difficult, I believe the result will be for the best.
I’m a developer, and I love what I do, it’s a great industry, and a very exciting field to be in. If you read my blog often, you’ll see I take every opportunity to mention how great this line of work can be, today I offer a somewhat different, less sugar-coated view.
The Pressure There is a constant pressure on developers to be better, to do more, to produce more, sometimes more than is possible.
It has been 20 years since I first used machine learning to solve a complex business problem. The underlying problem was simple: the company was selling a new service and wanted to know who was most likely to buy it. We had millions of records, and each record had hundreds of fields. A vast amount of data, but no idea how to extract insight from it. Countless hours from various data analysts had been invested into finding a pattern, but none was forthcoming.
Communication can be a real challenge; working across cultures, backgrounds, experiences, and perspectives can result in different interpretations — and this is under the best of circumstances. However, when it’s written communication, the challenge is multiplied due to the lack of feedback cues from facial expressions, body language, and the like. These challenges make it exceedingly easy to create a situation where what a person hears is entirely different from what the speaker (or writer) intended.
The last release of YAWAST was on January 1, 2020; while the release history was sometimes unpredictable, the goal was a new release each month with new features and bug fixes. I intentionally took January off from the project. In February, I left the company I was at; the team of penetration testers there had helped to inspire new features while looking for ways to make them more productive. But something else happened in February, an issue was opened – something that appeared to be simple, but in fact, made me realize that the entire project was in doubt.
