test

Hi Caleb

Debugging

If bug is locally repeatable I always try to unittest it out. Unit tests help to isolate the problem and usually makes the fix trivial. In addition I use chrome devtools, nodejs debugger and technology-specific devtools where applicable(React devtools, Vue devtools and so on).

On my current project I had to find a bug in the vehicle-selection algorithm(vehicle for the order was occasionally chosen incorrectly, with no visible reason for it). To help myself I implemented a small web-based reporting tool in under 3 hours, which transformed raw-logdata into google-map markers and easily-understandable metadata. This tool was very effective in visualizing the circumstances, helped me with the bug-hunt, and at the moment non-tech managers use it for analytical purposes.

On my previous project every once in a while I received bug reports from our clients stating "page wont load. Please fix". I tried working on those tickets, but getting "so much needed info" from the clients was next to impossible. To permanently fix the problem I implemented a front-end logging mechanism based on 'Sentry' which collected front-end exceptions with every metadata possible. Since then most of those bugs where fixed during testing stage, and we haven't received a single front-end support-ticket for as long as I was working there(well over a year).

Testing

First time I wrote unit tests was over 7 years ago for a old monolith project. This project was under active development for 10 years, only manual testing, and every time we had to change anything anywhere something would break in another part of the system. Implementing any feature request required 10 times as much time to manually test every part of the system out as for the feature itself, and even then we had 6 months release cycles. To achieve a reasonable amount of code-coverage and 2 week release cycles we had to refactor "Active-record" architecture to ORM, split services into modules, getting rid of all static methods, implementing dependency container mechanism and lots lots more. Legally I cannot share any code from this project with you, mainly because the code is proprietary, and I signed the NDA :) Sorry.

Since then I haven't actually rewritten anything, I prefer keeping everything modular from day one. Please take a look at src and test file. Keep in mind this repository contains the 'proof-of-concept' version of the npm package, on this stage I only wrote tests that helped me with development(I am a fan of TestDrivenDevelopment). I can provide a more production-ready piece of code, but I have to ask my manager for permission first. If I get one, I will follow-up.

This package is a part of automatic order processing system, which I was hired to build from scratch by myself, microservices architecture allows easy testing of every service by unit tests, and ENV based system configuration allows mocking any endpoint for integration and stress-testing. Take a look at this Dockerfile which ansible uses for setting-up developers environment on lxc-hosted debian container. I can also share a stress-test which mocks every external dependencies and bombards the system with all kind of data, but again I need permission for that. Will follow up if I get one.

Best Practices

In my opinion the three most important 'best practices' in javascript are 'keep everything modular', 'keep everything immutable', 'automate testing of everything critical'. All three are 'a must' on any type of project, ever on a small one. At the end it all comes down to explaining the benefits to your management. Even if existing system is too big for testing everything right now, you can always start with testing a small part, and gradually increase coverage. Same applies to linting, modularity etc.

In case of typescript, or redux, or some similar technology it is not so obvious. Yea, it is good to have typings, or a single unified flow of data, or ability to modify state only by actions, but the technical overhead sometimes is too big to make it worthwhile. 

For example:

A microservice holds the current "state" of the vehicles(model, make, location, etc). Most of that data he pulls from the mainframe, but not everything. GPS coordinates, for example, are very sensitive to timings, and routing them thru the mainframe was not an option. I needed a way to collect location information from a socket endpoint by listening to a specific event, and updating my state accordingly, In addition company needed a way to add mutations easily on demand. 

I would say the best practice here would be to have a standard FLUX architecture, with a strict unidirectional data flow. It would allow implementation of any data-mutation algorithm easily and safely, but at the end I threw this idea away due to overcomplexity of implementation without any real benefits over a more lightweight 'middleware' approach: a) To add an action in FLUX I had to modify three different parts of the system, in case of middleware only one. b) Mutations were depended on one-another and had to be run consecutively, every next mutation depending on the results of the previous one. Both FLUX and middleware patterns are identically good in handling this usecase. 

And if more-then-one approaches produce identical results I always go with the simplest one. Please take a look at this gist, it describes the final architecture of the controller.

Last but not least...

There is no easy answer to this question given the information I currently possess. In the last 4 years I've worked for as low as 50, and for as high as 120 hourly. It is all project and position specific. I am fine with the average rate across San Franciso bay area, CA, or Westchester county, NY(both are kind-of my permanent residences) for the position.

As for the contract - I would prefer 40 hour a week. 

Thank you for your interest. Arthem