Parenting and Developing

A few months ago, I was learning how to balance being a new-ish software developer and a new mom. I reached out to a few mothers in the community and was amazed at what I heard. Every mom talked about facing similar challenges which got me thinking... do all parents feel this way? Are we all feeling isolated about the same issues?

As a result, I put together a survey and tweeted it out to parents (mothers and fathers) who are also developers. The results have been fascinating and very telling of issues and trends in this area.

The great people at Ruby on Ales allowed me to speak about the survey and it's findings this past weekend (video will be posted once it's available).

As I mentioned in the talk, this research will be ongoing. The more data I can collect, the better! If you are a developer and a parent, or know someone who is, Please fill out this survey if you have a chance. It's super short and we're all busy parents so don't worry about complete sentences or well-thought out responses... just a simple stream of consciousness is more than okay with me!

Thank you in advance!!! And ping me if you've got any questions.

Survey link: https://allisonmcmillan.typeform.com/to/BbVmbH

Searching through logs

Recently, I needed to check out which endpoints in a specific version of our api were being hit/ if they were being hit at all. This involves searching through the paper trail logs, which was an interesting process so I thought I’d write about it.

First, I want to say, there is a better path than the one I took. It wasn’t until after I did all this log downloading and searching that I discovered the paper trail CLI. I haven’t had a chance to take a deep dive into it yet, but I assume using it is better than downloading 30 days of log files and than combining them into 1 log file.

Which is what I did first. I had to look at 30 days worth of logs, so I went to the paper trail heroku add-on and downloaded all 30 days worth of logs. Then I used cat *.tsv >merged.tsv to put all of the 30 files into 1 file. After that, I checked which endpoints I needed to look at by just looking at the routes file. Luckily, there are a pretty finite number of endpoints for the specific version I was looking at. I think, if I was dealing with significantly more endpoints, i’d need to figure out a better systems for ensuring that I’ve checked all the endpoints.

Then, for the simple endpoints (ie- /livestreams or /livestreams.json for the index endpoint or /livestreams/ for the show endpoints) I just ran a simple grep -c command which greps for that path and then counts it. For example cat FILE_PATH | grep -c /v1/livestreams.json.

When I got to a slightly more complex endpoint, for example, one that had a path like /v1/livestreams/something_unique_here/watched I couldn’t just grep for the endpoint, I needed to use a grep compatible regex to find the number of results that had “watched” at the end. I did this by searching cat FiLE_PATH | grep -c ‘/watched\b’ which looks only for the last bit of the url.

And that’s it. Pretty simple but I hadn’t handled searching through large log files or any sort of complex grepping before.

Arlington Ruby's Ruby Retrosession 2016

Arlington Ruby RetroSession… Retro ruby for short was this past weekend. I’ve been to retro ruby the past few years, with the exception of last year when I was in labor. It was so fantastic to be back at a community event. I love the unconf idea and feel like I always get a lot out of the conversations so it was great to be able to participate.

The sessions were as follows:

• Rspec
• Advanced Newbie (including mentorship, cs without a cs degree, importer syndrome, and ways to step up as an advanced newbie)
• Freelancing
• Everything APIs
• Functional web stacks
• productivity tools hack
• infrastructure as code

and

• making a safe space.

Since this was a 2-track conference, I only went to half of these. There was also ice cream, a retro at the end, and lightning talks.

In addition there was a separate newbie track. Notes and resources gathered from that track are here: https://gist.github.com/kalimar/1a23222b59fd0208f88d

So first I went to the advanced newbie session. We started by talking about mentorship and setting up both formal and informal mentorship opportunities. We never really got into ways to step up, but one CS subject that was mentioned as important for non-cs folks to know was Cryptography and a specific place to do this is through CryptoPals. Another suggestion related to learning cs fundamentals was by watching university courses. A list of these are available through the Github repo awesome courses.

Next I went to everything APIs. The conversation kicked off by asking what do you want the JSON return to look like and how that is a major decision what crafting an API… looking at the response types. I took some notes about things related to APIs that I didn’t know like how api versioning relates to 2 things, the schema and endpoints, where, I think, only the endpoint is usually considered.

There was a great discussion about good practices for external APIs which includes different strategies of putting docs into the actual api. And another discussion about how people like to create APIs… both grape and active model serializers were mentioned.

Some random tools mentioned and things to look up were: Swagger yard was also mentioned as a way to auto-generate documentation. Pact which writes tests in web mock style and then generates a JSON fixture file which gets shared with the micro service where the JSON is generating the response. It then uses a rake task, I think, to execute the tests. This goes along with pact broker which is an intermediate layer. Graphql is really strict about endpoints but generates great docs and is just 1 endpoint… you tell it what object or data structure you want and then it just gives you back only that stuff. Statsd helps you figure out what is still being used which helps with what endpoints are still needed or can be deprecated. I/O docs generates query explorers.

Finally, for API design, someone mentioned tasty pie which is big in the python community and would be great if something similar existed for the ruby community and HATEOAS which is a response call that tells you everything else you can do with your API.

After I bounced between productivity hacks and functional web stacks but spent most of my time in productivity hacks. There’s always great stuff out there. A full-ish list of what was discussed can be found in the hackpad.

The last session I attended was about infrastructure as code. This was really interesting to me because, I feel like one of the next steps for me is to learn more about devops and how deployments, etc. actually work, without the magic of Heroku. The session started out talking about what we think about when we think about infrastructure as code… things like Docker, Ansible, version control, Puppet, and Chef. It is humans changing code and code changing computers. The reason we do this is so that the infrastructure code is repeatable and can be replicated in the future. There are lots of challenges to infrastructure as code but the main thing mentioned was that if you don’t stay up to date on it, then there can be lots of security holes. Additionally, if you want to start learning about thing like Docker, etc. the barrier is pretty high. The tutorials are fairly difficult and since it’s all changing so quickly, lots of information, tutorials, and documentation is out of date.

Some tools mentioned: flynn.io which is a platform as a service. There’s an interface for Docker, push heroku-like commands, and buildpacks. Open shift by Red Hat. Teraform which is a command line utility that can go across services and configure them (i’m not sure this is the best explanation but this is at least a piece of what it does). Otto by Hashicorp which is an opinionated system which seems like it might be a good option for an off-the-shelf solution.

Some good resources to get started include AWS in plain english and twelve factor app which talks a lot about the decisions that need to be made and the things you should be thinking about when you’re looking at infrastructure stuff. Finally, it was suggested that to get started learning about this, to just create a VM on your machine and play around using something like vagrant. And remember, devops is stressful so find a mentor, find a support group, and practice #hugops often.

I didn’t take as many notes on the lightning talks. Someone gave a great talk about note-taking (which I obviously love doing) and suggested to take notes in markdown and to create a notes folder in every repo (or just in your projects folder) and add it to your .gitignore. I actually love this suggestion because recently, I find i’ve got over 10 notebooks filled with notes and without having the time to add color coded tabs to these notebooks, it’s getting more difficult to find things I KNOW I learned so I’ve been debating starting to take these notes in a more searchable fashion (but don’t really want to just have a gazillion notes in evernote) so this sounds like a great suggestion. Also, taking the notes in markdown would force me to become better at it which I think would be super beneficial in general. The other thing I wrote down was a github repo called Dug which provides a more transparent view into open source software and allows you to organize github notifications better than you can with just gmail filters. Also, there were a few talks that related to sleep but I didn’t take notes on any of those because I have an 11 month old. One day I’ll sleep again.

That’s all! Retro Ruby was awesome. It was so much fun to see people again, learn stuff, and have great conversations. Here's the Hackpad with notes from the whole conference.
Plus the t-shirts glow in the dark!!!!

Rails Runner to the Rescue

Yes! I finally have something good and technical that I can blog about!!

This week, I was working on one of our smaller applications. At GA, we send out surveys to students in order to get feedback on courses and programs and I was looking to add a new survey template. After becoming familiar with the codebase, I discovered that new surveys have previously been added by creating a bin file and then running that script since new surveys require tons of validations and therefore it is too complex to just add a survey via the console. And so that’s what I set off to do. Now, the actual creation of the survey wasn’t so difficult. The app is very modular and pretty clean and easy to understand. I finished up that task (as well as updated the readme to find this sort of information a bit easier) and then I said, ok great, well, now I have to deploy it to our staging environment. And so I sat for a moment and thought, well, how do I run a bin script only in staging. Enter rails runner. Rails Runner is an easy way to execute 1 file in an environment of your choosing. You can find a tiny bit more about rails runner in the rails docs here.

So based on this post I ran what I thought was the correct command…

heroku run bundle exec rails runner ./bin/file_name -r staging

and I got an error

/app/vendor/bundle/ruby/2.2.0/gems/railties-4.2.2/lib/rails/commands/runner.rb:62:in `eval': /app/vendor/bundle/ruby/2.2.0/gems/railties-4.2.2/lib/rails/commands/runner.rb:62: syntax error, unexpected '.' (SyntaxError)
./bin/file-name

WHAT?!

okay well, maybe I don’t need that ‘.’ in front of /bin and that is the issue. and so I ran

heroku run bundle exec rails runner bin/file_name -r staging

and got another error

/app/vendor/bundle/ruby/2.2.0/gems/railties-4.2.2/lib/rails/commands/runner.rb:62:in `': undefined local variable or method `bin' for main:Object (NameError)

well, now I was confused. I obviously needed the ‘.’ there and the first error was pointing to a syntax error… was there a typo in my code? I looked (and had a colleague look as well) and couldn’t find anything. I searched and searched (there really isn’t much about rails runner, which is why I decided to write this blog post!). okay, a little while passed and so I said to myself “it’s time to pair!”

I grabbed a colleague who suggested to see if we could even just get into the shell and then run the command from there, so I entered heroku run bash. Success! I’m in. Then we just did an ‘ls’ to make sure we were in the right place. Yup, right place. So then we did ls bin and the file wasn’t in the bin folder! Here’s where I had my moment… I thought that I needed to run the bin scripts BEFORE deploying the PR to staging so that the files would exist and the surveys would appear in our staging environment. HOWEVER, rails runner was looking into the staging code base in order to find the files but of course, they weren’t there because I hadn’t merged the branch in.

Merged the branch in, and then ran

heroku run bundle exec rails runner ./bin/file_name -r staging

and the problem was solved. Just a simple order of operations issue.

On what the heck to blog about

A few months ago, I made a commitment to start blogging again at least once per month. I keep this reminder on my to-do list and try to keep a running list of topics that I can write on. This WAS great when I had a lot of hours to put into extra learning, extra reading, and all those other great things you do when you’ve got more time. I blogged about side projects, issues I faced, interesting blog posts I’d read that week and a whole bunch of other things that I thought were pretty interesting.

Now that I have a small kiddo who periodically requires some attention (and by periodically I mean I looked away for like 5 seconds the other day to finish something and he totally face-planted), even more of my learning is done on the job. What I do at work is really interesting. The app is fairly complicated and so I new and different things every week. From feature builds to bug fixes to investigations, every day is varied. However, with all this learning i’m doing at work, and all the notes I take in my notebook so I can study and remember everything in the future, it’s hard to blog about these things. Why? Because there’s so much contextual knowledge around the problem and the solution. Aside from the fact that a lot of things are proprietary, you need to know a lot about the application, data structure, and history of development in order to understand why we need to solve some of the problems that we do. Furthermore, oftentimes what I am doing is a small piece of a larger puzzle since my tasks are often more digestible than whole large-scale tasks and to blog about this small piece would require a significant understanding of the larger component I’m working on. Finally, I still find it difficult to figure out which solutions are only applicable to that specific problem I’m solving and which are applicable to many different situations.

So, what do you blog about when you’re not working on a side project? How do you come up with ideas? I wish I could blog more often but I’m currently feeling like it just takes so long to figure out what to talk about!

Chrome Extensions and a Return to Meetups!

Well, I missed my "blog post a month" by a week or so, but I finally got an idea for a blog post! A few weeks ago, I finally made it back to Arlington Ruby (as a part of me trying VERY hard to start going back to meetups and getting re-acquainted with the community I love so much) and learned about making chrome extension from Casey Watts. Nope, it has nothing to do with Ruby but it was really interesting to learn about. There were two components of this presentation that I enjoyed. The first was the actual technical content of learning how to do a chrome extension and the second was the presenter's teaching methodology.

Let's start with the technical content. Did you know that making chrome extensions is super easy?! In about 30 minutes, we already created like 3 chrome extensions. There are 2 things we learned... bookmarklets and actual chrome extensions. According to the presentation, a bookmarklet is "a bookmark that runs javascript on the current page instead of taking you to a new page" (like a regular bookmark would).The basic premise of both bookmarks and chrome extensions is altering the "location" field on the "add page" form in order to execute the javascript.

An extension is only slightly more complicated than a bookmarklet... at least the examples we did during the meetup, but i'm sure that this is where it can get really complex with more sophisticated ideas. An extension has a manifest.json file which outlines the name, version, description, javascript files (or html or css) you want to pull in, and where you want the extension to work.

Finally, we spent a little bit of time talking about examples of chrome extensions people might want to build, how to distribute and deploy a chrome extension, and some security things to keep in mind when either downloading or deploying an extension.

As I mentioned earlier, I still assume that making a more complex extension is more difficult. It seems like it could potentially involve a significant amount of code and because of how the code is pulled into a chrome extension, could be complicated to mentally keep it all straight and organized. All in all though, I had no idea that building an extension was so straightforward and I can't wait to think more critically about extensions I use or actions that might make sense to make an extension for.

The second part of this presentation that I liked was how it was taught! It is really difficult to teach something technical without really knowing the group of people you are teaching. It is even more difficult to do this when you know that there will be a pretty diverse level of skills in attendance as well. Casey did a great job! He started by framing what we were doing and what the end goal of the "lesson" was. He then had us pair up, which enabled everyone to work with someone on the parts of lesson that were self-guided. It was great to bounce ideas off of someone else and, we all know that often at technical meetups it can be difficult to meet other people. The guide that he walked us through was really clear and easy to understand. You could move through it faster if you were more experienced or slower if you were less so. It was a lesson but felt very laid back, informal, and fun. Finally, we worked independently in small chunks of time but then came together in between those times. When we came together as a group, Casey made sure we were all paying attention and as a result I think there was much more group participation than if he had just hoped that everyone was engaged instead of really enforcing that they do so. I feel like everyone left having met/spoken to someone AND actually having learned a bit more about chrome extensions.

RubyConf Australia

I am actually working on a more technical post. It's so difficult to come up with them when I can't show code from work since that's what i'm doing and learning al day!

In the meantime I wanted to announce that I'm SO excited to be speaking at RubyConf Australia in February about working remotely with the phenomenal Kevin Hopkins.