Late last year we were working on implementing user-notification flash messages in our EmberJS application, and ran across an excellent blog post describing a service-based approach for flash messages. This was a great start and I really liked the overall approach of using a service paired with flash objects and components, however, when integrating this functionality into our application I ran into some limitations and came up with some workarounds and improvements I wanted to share.
I recently returned to Chicago after spending three weeks in Brazil. While I did get to spend some time relaxing on the beach, it certainly wasn’t all vacation.
Here at Table XI, we’ve been developing an International Exchange Program where developers can travel abroad to work with and learn from software experts all over the globe. For our people, this is a really unique opportunity to learn about other cultures, pair with amazing people, and connect to the broader software community outside of Chicago. While visiting, we always try to engage in the local community, actively participating in regional conferences and other community outreach programs.
If you are the type of programmer who writes perfect, error-free code in every commit without fail, this tip is not for you. If you're like me, small mistakes sometimes occur – a debugger breakpoint left buried in an obscure area of the app, or maybe I missed resolving a conflict during a hairy merge. With discipline these things shouldn't happen frequently, but when there's an inevitable lapse it's nice to know that git's got your back.
Your Ruby on Rails application is sick. Deadlines are looming, but every time you make the slightest change to the code, something else breaks. Nobody remembers what that tricky piece of code was supposed to do, and nobody can tell what it actually does. Plus, it has bugs. You need test-driven development, a process for improving the design, maintainability, and long-term viability of software. Table XI's Senior Developer & Agile Coach, Noel Rappin, can help.
Since the discovery of the Heartbleed bug about a month ago, companies have been scrambling to fix security issues while the general public has been warned to monitor online account activity and change passwords (though not everyone has felt the urgency, apparently).
Last week we hosted one of our best Table Talks series yet, focusing on the topic of "Technology for Social Good." Given our long history working with nonprofits, we were excited to hear other designers, developers, and technologists talk about how they've used their powers for good.
Overall, a running theme seemed to be that technology for technology's sake cannot make the world a better place—but in the hands of smart, thoughtful, mindful people, it can be the agent for meaningful invention. Think: a quickly deployed web app that allowed Boston marathon runners to call their families after last year's bombing, when cell towers were overloaded; or a text helpline designed to aid and track down kidnapping victims.
The rise of web standards made authoring CSS easier than ever. However, the browser vendors wanted to move quicker. Their solution was to implement features before the standard was finalized using a vendor prefix for the property.
You may have read this week about security issues with Apple software. First off, if you have an Apple device and you haven’t yet updated to the latest iOS 7.0.6 for iPhones, iPads, and iPod touches, or OS X 10.9.2 for Macs, do so immediately.
Here, we take a closer look at the problem and try to analyze what happened.
There is importance in failure—not only does it give you nuts-and-bolts experience that you can draw from later, but it also teaches you how to deal with making mistakes and, best yet, how to rebound from them. It’s empowering—especially for those just starting their careers—to hear experienced professionals openly and honestly discuss their mistakes. It reminds us that nobody’s perfect, that even the best minds need to ask for help sometimes, and that failing isn’t shameful.