On Wednesday, I had the opportunity to shadow at LivingSocial with Tony Pitale. Tony is awesome. He was a coach at the first RailsGirls workshop and really enjoys teaching (which is good for me because I enjoy asking a gazillion questions). LivingSocial is, by far, the largest company I have shadowed at so far. A lot of the initial part of our day just focused on looking at different tools that LivingSocial uses and how the company is structured.
There are over 100 developers that work for LivingSocial, which to me is interesting to think about in terms of culture. I’ve met with some smaller teams so far, teams that almost all work from one office, teams that work entirely remotely, and the in between but none with the sheer mass of developers that LivingSocial has. It was really informative for me, especially as I look at different company cultures as a job applicant, to learn about how tasks are determined, how teams communicate with one another, how standups work, and what sorts of professional development and peer learning opportunities exist at their size.
LivingSocial has a lot of different engineering teams. Each team is responsible for one to a few apps. That team is responsible for knowing all the logic of that application’s purpose and also helps different teams work on different code without stepping on toes, interfering with others, etc. There are a ton of different applications. In order for the applications to communicate with one another, a lot of synchronous API calls are utilized. This means, basically, that when an event happens, the event needs information from a different application in order to continue and make the process happen. There are also asynchronous API calls for other types of events and application communication.
Finally, LivingSocial uses a ton of different tools to measure and provide information about what’s happening. To just name a few we looked at were graphite, rearview, new relic, hive, and kibana. Each has it’s own purpose and tracks something different. The really cool thing about looking at all of these different tools was figuring out how they are used to see what’s happening. For example, when an alert, error, or bug report comes up, you can go into these tracking tools to get more information on what is happening and also to make improvements like site or transaction speed.
Other smaller things I learned:
*If you drag the icon of your sublime text file into the terminal, it’ll put the file path and you can run the file!
*Serializers. What interesting pieces of applications. Serializers say when you take a record out of a database, these are the attributes that we want back in JSON. They’re good to use when you’re building an API. You use something like serializers so that you don’t have to make a class with a method as_json which defines what would get returned as JSON. (Serializers relate to an interesting conversation I had with Jim Gay about presenters and what presenters are used for. As I learn more about rails, it’s also been really interesting to see how you can continue to break out these pieces of information to make cleaner, more organized code.
*when TDDing something, you can also use it to think as a design helper. If your test for a specific item is getting to large or crazy, it’s probably time to break it into different pieces and look at the code design a bit.
*A good way to organize TDD tests are by thinking through the logical order. So the test order should be setup, execution (thing you want to run), assertion (event did happen), teardown.
Overall, a really interesting day at a really interesting company with a really interesting setup and a really interesting teacher!!
No comments:
Post a Comment