25 blog posts tagged "Programming"

Nerds. While programmers/coders/engineers are extremely clever, we've found they may not fully understand addresses. Sure, they're ready to talk about variables, loops, arrays, the scope of stuff, callbacks, hosting, events, overloading, pattern matching, packets, elements, and more. But if you point out that most house numbering starts at "1" and not "0," their heads may explode. We've worked with quite a few developers and helped them understand the facts around address data, beginning with our own engineers.

In an era dominated by technology, grasping the language of computers – coding – is increasingly essential. The Hour of Code, a global initiative, aligns with this need by making coding more approachable and broadening participation in computer science. This effort parallels Smarty's dedication to technological innovation, striving to simplify and demystify technology for widespread understanding and engagement. The movementThe Hour of Code started as a one-hour introduction to computer science, designed to simplify code and show that anybody can learn the basics.

Spend enough time as a software developer, and you learn about the existence and pain of technical debt. Understanding, managing, and communicating technical debt is crucial. It allows us to build more maintainable software, improve our productivity, and even boost team morale. We recently hosted a webinar with one of our software development team leads, Kiersten Nelthorpe, and senior software developer Cody Robertson, where they gave valuable insights and strategies to help you deal with technical debt in your work.

In our recent webinar, we brought together two of our software engineer experts, Adam Charlton and Ryan Cox, to demonstrate how to build a working application using ChatGPT to generate most of the code. We know what you're thinking: ChatGPT can't take our jobs; we've tried. This is wonderfully true. ChatGPT can pull together useful bits of information but still needs to be guided and curated by a human, preferably one with subject knowledge. The exact working scenario given by Adam and Ryan was:Write code in Python that takes an address and delivers the ten closest addresses to that address.

We have the luxury at Smarty of working with some incredibly intelligent, kind, friendly, and in many cases, funny individuals. Today we showcase one of those fantastic individuals, Kiersten Nelthorpe. Kiersten is one of our amazingly talented Software Engineers and is the team lead over our Backend Accounts Engineering team. Her accomplishments include building Microsoft API services for enterprise software, developing features for supply chain tools for Vivint, and building backend reporting APIs for Imagine Learning.

We have the luxury at Smarty of working with some fantastically intelligent, kind, friendly, and in many cases, funny individuals. Today we showcase one of those fantastic individuals, Ryan Cox. Ryan has a history of high-quality performance while problem-solving and team-building at large software companies along Silicon Slopes. You want experience? Ryan has experience. We're talking 61 years collectively in Java, Javascript, Typescript, SQL, Angular, AWS, and loads more. As a key developer at each company he's ever worked at, he's keeping the ball rolling by improving the quality of work we do here at Smarty every day.

Have you ever tried to add a minor feature to your application only to discover that you’ll have to re-write large blocks of code first? Or maybe you’ve spent hours deciphering hundreds, or perhaps thousands, of lines of existing code just to find out a task only required two lines of additional code. If you’re like most developers, you’ve wasted countless, frustrating hours wading through immensely complicated code trying to force it to do things it wasn’t built for. In his presentation, Mike Manwill, Frontend Team Lead here at Smarty, discussed 5 principles to help you create stupidly-simple applications that are maintainable, extendable, and bug-resistant.

Many businesses now collect data online. One could argue that it is nearly impossible to succeed in modern business without some sort of online portal in which there is an exchange of information between the provider and the customer. But how do you ensure that the information being input by the customer (or potential customer) is accurate?While there is no way to ensure that Bobby Duncan doesn’t put “Sammy Sosa” in the name line on a form, there IS a way to ensure that he’s putting in a valid mailing address for you to mail his package to.

It's been said that naming is one of the two hardest problems in computer science, along with cache invalidation and 'off-by-one' errors. (See what I did there?) Do you ever find yourself wondering what policies and practices you could adopt to make your life easier when reading code you wrote months ago? Or maybe you're up at night wishing you knew how to write code in such a way as to maximize adoption and convenience for your users? Well, look no further because we've anticipated the need, solved the problem, and now we're sharing our knowledge and wisdom at no charge, all out of the goodness of our hearts in this comprehensive, totally no-nonsense (nudge, nudge, wink, wink) style guide of Go naming conventions.

One topic that seems to come up repeatedly on Stack Overflow or other online forums is the topic of how to go get private dependencies. Specifically, if I have a private Git repository on Github or Bitbucket, how do I bring that code locally via the go get tool such that automated builds can produce a clean, consistent build without interaction from a user? This problem is largely solved for public Github dependencies but continues to be a challenge for private dependencies. To reiterate, if you're only cloning publicly available dependencies, you probably won't be reading this post.

Writing test functions in Go is easy:package stuff import "testing" func TestStuff(t *testing. T) { t. Log("Hello, World!") } Running test functions is also easy:$ go test -v === RUN TestStuff --- PASS: TestStuff (0. 00s) stuff_test. go:6: Hello, World! PASS ok github. com/smartystreets/stuff 0. 006s Preparing shared state for multiple test functions is problematic. The usual recommendation is to use table-drive tests. But this approach has its limits. For us, xUnit is the ideal solution.

For the purpose of this article, consider the following CSV data, slightly modified from the docs for encoding/csv:csvData := strings. NewReader(strings. Join([]string{ first_name,last_name,username, "Rob","Pike",rob, Ken,Thompson,ken, "Robert","Griesemer","gri", }, "\n")) Here's how you read the data, line by line, using the Reader provided in that package:reader := csv. NewReader(csvData) for { record, err := reader. Read() if err == io. EOF { break } if err != nil { // handle the error.

I was recently asked two interesting questions:Why did you move from GoConvey to gunit?Are you recommending folks do the same?These are great questions, and since I'm a co-creator of GoConvey and the principal author of Gunit, I feel responsible for giving a thorough answer. For the impatient, here's the TL;DR:Question 1: Why did you move to gunit?After using GoConvey and feeling consistent friction with that approach, we came up with an alternate approach that was more aligned with what we value in a testing library and which eliminated said friction.

For this installment of the Testing in Go series we'll be talking about a grouping of packages that facilitate general-purpose comparisons in various contexts. Since the most common context is testing it seemed like this series was the right place for the discussion. We generally refer to these comparison functions as assertions (cue ominous background music and spooky sound effects). You may have already read the opinions found on the Golang FAQ related to assertions. "Why does Go not have assertions?"Go doesn't provide assertions.

IntroductionTL;DR: Choose an approach to software testing that helps your organization create the best possible end results. That might mean using and/or creating a few tools and/or libraries along the way. Or, maybe not. What follows is a description of what we do at SmartyStreets, couched as a response to Dan Mullineux's equally valid way of doing things. The costA favourite test helper library, with some simple test assertion functions clearly has some value. . . They [testing libraries] are not so bad, but they come at a cost, defer to avoid them.

Not every server is made equally. On dedicated servers, the hardware varies widely. On virtual and cloud servers, the resource allocations also vary widely. Some servers are CPU-optimized for maximum computing power. Others focus on having a lot of memory. Some servers are built to have a good balance of all system resources. Hardware aside, we require many differing tasks of our servers. Some applications are processor hungry, some need large amounts of disk space, while others take up a lot of memory.

For this installment of the Testing in Go series I'll share a really nifty way to deal with time in your unit tests. When the behavior you are testing depends on the current time it can be tricky to assert on the results because the current time is a moving target. So, usually we end up resorting to approximations in our assertions that, while functional, always bother me a bit. In some cases, depending directly on the system's current time prevents acceptable test coverage. Consider this trivial example, which defines a calendar service with a method that identifies the current quarter of the current calendar year:File: calendar.

I think it's time for a slight detour. In part 1 we covered the basics of testing in go. In part 2 we covered a few slick ways to execute tests. In part 3 we covered some of our recent endeavors at Smarty to build on the basics. Toward the end of that post, we went into some detail regarding our approach to assertions. The assertions referenced in the GoConvey project are actually their own separate project that are imported into GoConvey. The nice thing about separating the assertions into their own separate project is that they can be used, well, separately.

Here at Smarty, we're mostly programmers and developers. There are a few needles in the haystack here that don't know "Unix" from "eunuchs", which is unfortunate, but we're working on that. And because we're all tech geeks over here, we like to talk about code, and tech, and why all that stuff is important. In that spirit, we decided to talk about code in a way that maybe all of us should have considered a long time ago. Your hidden meaningsLet's start with a scenario. Imagine you go on a museum tour.

ReviewWelcome to part 3 of our "Testing in Go" series. If you're new here, feel free to catch up before reading on. In part 1 of this series I eluded to our perceptions of the standard testing tools provided by the Go tool and the standard library and what was missing for us. We all have different expectations of a testing tool and so it's no wonder that so many have been created. Part 2 of the series focused on how we have made the act of running tests effortless and automatic. IntroductionIn this post and the next few posts I'll focus on our approach to writing actual tests.

Here's part 1 of our "Testing in Go" series. IntroductionThinking about trying Go? You won't regret it! It's great that testing is baked into the "testing" package from the standard library and the corresponding go test command (which has all sorts of useful and interesting flags). We'd like to show you how easy it is to get started using the built-in testing tools and introduce you to some tools we've created. This is the first installment of a series designed to do just that. All you have to do is create a file named like *_test.

Here's part 2 of our "Testing in Go" series. If you're new, feel free to catch up before reading on. BasicsYou've already learned how to execute tests in Go for a single package. $ go test There's a bit more to it, though. You can run any package from anywhere if you provide the import path. For example, this command runs the actual tests for the "testing" package from the standard library:$ go test -v testing If you've already run go get github. com/bradfitz/http2 you can execute those tests from anywhere with this:$ go test -v github.

You asked for it and now you've got it. For packages that pass all tests, coverage reports are generated and made available by clicking the package name, which in that case becomes a link (provided you've cleared your browser's cache!). Right now the coverage command that is run is something like this:$ go test -covermode=set -coverprofile=<package_name>. txt That command generates a plain text profile used in the following command:$ go tool cover -html=<package_name>. txt -o <packge_name>.

One of the great benefits of TDD/BDD is that you usually don't have to spend much, if any time at all in a debugger. To enter a debugger is to admit a loss of control over the system under test. Even so, there are times when you do need to debug something, even if you're maintaining the discipline. Lately, most of my coding is in GoLang. Coming from using an IDE almost exclusively to write Python (using PyCharm) and C# (using VS and ReSharper), and knowing how great the visual debugging tools are it's hard to fathom using a console-based debugger for GoLang code.

It's now been a few months since I decided that the kind of testing tools I wanted for Go programming hadn't yet been created (or I just hadn't found them yet. . . ). So, about 4 months ago I started work on GoConvey and a month later came the first release. The coolest thing about GoConvey (other than the clean DSL, comprehensive set of built-in assertions, and the fact that it integrates fully with go test) is the built-in auto-reloading web UI that reports your test results to your web browser whenever a relevant file is saved (HTML5 notifications included).