For a recent project, we built a live-search for over 60,000 records which used both simple pattern matching and full-text search. The records we needed to search were diagnoses that are used to assign patients to a therapy. I had never done full-text search or anything real-time with that many records, so I ended up doing a lot of experimentation. These posts will cover my experience, and I hope they’ll be of value to anyone implementing their own Postgres search.
The records we were searching were International Statistical Classification of Diseases (ICD) codes. Each record consists of a 3-7 character code, a short description averaging 11 words, and a few other data and association fields (for this post, I generated 100,000 records matching the real ICD format). We needed to be able to search by code and description, and users would be changing their search query quickly to find the right record, so it needed to be responsive. In part one, I’ll cover the code search where a user enters one or more codes (which may be partial).
Interested in the current state of tech in LA and meeting key leaders in development, startups, media, fashion and more? Join myself and several Carbon Fivers from our Santa Monica office at Techweek LA, Nov 20-21st to hear from top thought leaders in LA and attend a variety of events and networking opportunities.
Register for the event through our City Partnership and get a 15% discount.
Carbon Five will be participating in the judging of the Launch competition and hackathon where we see what next big thing will shape the future of LA and beyond. Interested in competing? Rally your team and apply today!
Techweek LA runs from Nov 20th – 21st in a custom built tent on the Santa Monica pier. Check out the full schedule and contact us if you want to meet up with one of our developers and designers at the event.
Steve McConnell wrote a book called “After the Gold Rush” that was published back in 1999. He wrote about how the software development industry would benefit by maturing and becoming a professional industry that had learned from the mistakes made during the tech bubble of the late 90s (Steve is actually better known as the author of “Code Complete,” a great book that influenced very many developers). We, as an industry, have learned a lot since then and there are far fewer colossal failures, but we still have plenty to learn about building successful software products. This is especially important when you’re considering your next gig.
The (tech) Gold Rush is still going strong, having dipped only a bit in the mid-naughts. If you’re an experienced designer, developer, or product person… you have more opportunity than most people out there. That’s a great position to be in and we should all be thankful.
All that opportunity makes deciding where to exercise your talents harder. There are many factors at play when you’re looking for a job, some of which may be obvious (e.g. size and location) and others which require looking inwards (e.g. culture, work style, and hierarchy). If you’re looking for a new gig, here are some tips that will help with the process.
Hopefully by now everyone has heard about the Bash remote execution vulnerability, and is sufficiently terrified. We here at Carbon Five all use Macs, and so we are all by default vulnerable. Here are the steps we took to secure our computers. Maybe they can help you too.
In this article, we’ll demonstrate usage of the Bacon.js library, implementing a Node.js chat application in functional reactive programming style. We’ll use the Socket.IO chat application example as our baseline, adding on some additional asynchronous workflows, interaction with MongoDB, error handling, and logging.
Here at Carbon Five, we have been making an increased effort to reach out to the growing junior developer community to provide guidance and mentorship. We piloted an event series dubbed Junior Jump, catered towards helping entry level developers prepare for their engineering careers. A few weeks ago, as a part of this event series, we brought in a group of junior developers and had an fishbowl-style open conversation about various topics concerning the current climate of junior developers including: the current difficulties of job searching, what kinds of expectations should be placed on a junior developer, and what the heck is a junior developer anyways. You can find the full video of this event below.
We’ve heard lots of feedback from those of you using Stickies.io. Today, we launched a few small updates. Here’s what’s new:
1) New landing screen – with an easier way to give us feedback
2) More color, less shadows – for a brighter day
3) New background – behold the dots!
4) Most importantly – we dropped the name Boardroom. You might be thinking – what’s Boardroom? Exactly.
For those of you who don’t know, Stickies.io is Carbon Five’s free online, collaborative brainstorming and retrospective tool. The project started as a Node Knockout submission years ago (originally called Boardroom…well, originally-originally called Retroflection which was a mash-up of…nevermind). Anyhow, we’ve been slowly work on it – responding to Tweets and pull requests on Github ever since.
Try it out and feel free to send us your thoughts at email@example.com. We have a couple of big new features in the pipeline, but we’re excited to hear your thoughts as well.
Tests help me write better apps. Writing tests informs my interface designs, expresses some of my intentions, and guards against regressions. As applications grow so do the number of tests I’m running as a regular part of my development workflow. If I’m not careful those growing test suites can slow down, become inconsistent, and eventually lose the trust of the development team. Fortunately, test driving software design is not a new idea and we can look to other languages and frameworks with good testing practices for inspiration on how to avoid pitfalls we encounter when writing tests.
I ran into a couple of cases on recent projects where I wrote unreliable iOS XCTests. Let’s take a look at what went wrong, what a better test might look like, and what tools we, as iOS developers, might be missing.
In the years since we’ve been providing integrated design and development on agile teams, we’ve noticed something that seems to emerge naturally on projects that are going particularly well. While we always set out to design our products in small releases, refactoring along the way (i.e. “the smallest whole“), often designers find themselves quickly under a ton of pressure from the developers, who are looking for well-defined stories to work on, sometimes after only a week of product definition.
Even once the overall product design is in place, each week brings a handful of new features that developers are eager to start. In addition, sometimes a teammate will throw a story into the backlog that is just an idea, not even ready for a designer to elaborate. At times it can feel like our team is a fiery coal-burning engine (our product manager and developers) starving for fuel (the design).
Without time for a complete set of wireframes (let alone visual designs) designers sometimes have to get a little creative. Not every story can get the same level of definition, and a one-size-fits-all workflow (e.g. design, build, deploy) doesn’t really make sense for every feature. We’ve found a set of activities useful when the team feels “blocked by design.” I like to call it Story Triage.