Rich Seviora

I've developed a number of Rails applications, including my own fitness tracker (https://www.sweatrecord.com) that's deployed with AWS OpsWorks. I have strong experience with all aspects of testing (unit, integration, and browser), enabling me to deliver well-tested applications. I've also contributed to Rails documentation, Selenium Webdriver, Coffee-Rails, and the Shoryuke ActiveJob adapter for AWS SQS.

I've built a variety of JavaScript applications from scratch, and worked on countless existing JS applications/libraries. Nowadays when starting any project, I reach to TypeScript and Jest. These tools allow me to quickly produce code that is well tested and well architected. When I'm creating code destined for the front-end I immediately add Webpack. Webpack's ability to create minified JS code directly from TypeScript files removes the tedious compilation step, and the Webpack Dev Server improves the speed of development. It also enables me to compile modular SASS/LESS, which hugely improves the maintainaiblity of my stylesheets.

Whenever I build a front-end application I instinctively reach for React. Like Angular, React allows me to quickly build rich interfaces from reusable components. But unlike Angular, React's support for the JSX enables a better development experience, especially when combined with TypeScript. React also has a very strong community behind it, and a wide variety of OS components that I can integrate into my projects, allowing me to implement new features far faster than I would've otherwise. I particularly enjoy the Velocity React library for component animations, and the Victory library for creating interactive data visualizations.

I developed a companion client for my fitness tracker app in Xamarin Forms to the late alpha-level. Xamarin Forms and its data-binding support allowed me to develop and modify the UI far faster than I would've if I had to develop in both Android and iOS. The benefits of codesharing between mobile platforms are huge!

I tend to prefer strongly typed languages, and C# is no exception to that. I've used it to develop a mobile client in Xamarin, and I'm looking forward to working more with it.

I'm a huge proponent of automated testing. It gives me confidence that the code will work as expected. When developing applications I vary my test intensity and specificity depending on the client requirements, the complexity of the code involved, and the typing support that the language provides. For Ruby projects, I practice an approach that I call "near TDD". I don't necessarily test every line of code I write, but when I'm working on any complex code I work through the red-green-refactor approach. This is really driven by Ruby's lack of type-checking (a mostly inevitable outcome of the strong metaprogramming capabilities it offers). When I'm working on TypeScript or C# projects I tend to refrain from unit testing every feature; instead I unit test only complex logic, and/or code that interacts with an external library. Regardless of the language, I write integration tests and browser tests when the code complexity calls for it. The great benefit of browser testing is that I can test against multiple browsers, and it allows me to test the solution end-to-end.

Prior to becoming a freelance developer I worked at a large telecom. As an account analyst and then manager, I coordinated and managed a number of projects with IT dependencies. At some point I picked up a PMP certification. I focused primarily on requirements gathering and solution design. I witnessed a number of projects that went off the rails due to poorly defined requirements (missing, unclear, or outright wrong), and consequently I go through requirements with a fine toothed comb so I can tease out where potential issues might arise.