hello from the other side

No, it’s not Adele. It’s me, Raquel. I have not been on the blog grind for several months. Much has happened since graduating from ACLTC, both personally and professionally, some very positive things, some not so much. Life is like that.

Over the summer, I was lucky enough to do a three-month apprenticeship for an interactive design studio here in Chicago. It was great – I’ll have some posts about it soon – but now I’m on the hunt for full-time employment again. I have an interview coming up tomorrow!

I’ve spent the past couple of days preparing for this tech interview. I’ve been reviewing what I learned in ACLTC, rereading some notes, checking out my code on github, checking out the app I made, Hoop Helix, which was sort of a spinoff of what I made for ACLTC. Having spent some time away from terminal and github, it’s amazing how going back to it is related to muscle memory. Just the repetition of certain commands feels familiar.

The Code Newbie podcast has been great company while I’ve been prepping. If you’ve never heard it, check it out. Really useful and inspiring. I’m listening to the episode with Suzan Bond, who is giving great advice about interviewing and thinking about what you need as someone figuring out where they want to work.

Beyond the technical aspect of the interview tomorrow, I’m also thinking quite a bit about the value of the other skills I have and the full picture of what I bring to the table. The idea of valuing your skills and not selling yourself short is really important when it comes to the confidence that you bring into an interview. Especially as someone who is new to coding, it’s so easy to belittle my own accomplishments or feel inept. The trick is to recognize how much I know today and how that compares to what I knew yesterday, two weeks ago, two months ago. I’ve learned a lot and that’s indicative of my capacity to work in very significant ways.

OK, now I have to go figure out what to wear tomorrow.

Learning and practicing 20 minutes at a time

Having recently graduated from Anyone Can Learn To Code, I’m very excited about all these new things I know, but I’m also afraid of losing them now that bootcamp has ended.

I’m in the process of looking for employment, which makes me think I should be spending all my time focusing on that task. But, really, I need to dedicate some time to practicing what I’ve learned as well. I can’t expect to improve my code unless I’m writing more of it. And with better code and more projects, I’ll improve my chances of landing a job.

The logic is quite simple. But there are so many bits and pieces that go into what “improve my code” means that it’s a bit overwhelming to figure out where to start. There’s reading about Ruby, there’s practicing writing Ruby and Javascript, there’s becoming more familiar with Angular, there’s practicing Github workflow – then there are design related skills I don’t want to neglect either! And you can’t forget about the job search.

I won’t bore you with every bit, but let’s just say I have a mountain of post-it notes with each bit laid out. So what’s my plan? I’m going to break it all down into 20 minute increments. I won’t start them all on the same day, but I will start with a handful, enough for a couple of hours. Reading followed by Javascript practice, followed by Ruby practice…you get the idea.

Groundbreaking? Not really. But it’s new for me, at least in trying to apply it to so many goals. I’ll see how it goes over the next week and revisit to see if any adjustments would be helpful in keeping me on track.

Wish me luck!

Making content changes in WordPress for the non-coder

The premise here is simple. I’m going to outline a few steps for making changes to your WordPress pages in the Text view. Depending on what you’re working with, making edits in Visual view can sometimes be more frustrating so I tend to stick with Text view and show my clients accordingly.

This is aimed at WP users who are not coders, people who already feel a bit uneasy about using the Text view. In my experience with my clients, they prefer these steps to using the built-in WP revision comparison page. So here is how you can feel more confident about not breaking your page if you are going to make some changes.

1) You may not have noticed this before, but your history of page revisions is available in your dashboard. Look below the content edit module (that’s where you have your page content), you should see a list of revisions with the most recent at the top. It lists the author, date and time revisions were made. Before you make any changes to your content, make a note of the most recent properly functioning revision. If you’re page is functioning properly, the one at the top will be the one you want to remember – but don’t rely on your memory. Write it down, take a screenshot, record it somehow.

Revisions module

Revisions module

If you don’t see the revisions module, you probably have to select it in your screen options. Click on the screen options menu in the upper right-hand side of the page. A section revealing the many modules you can display will appear. Click on the Revisions box. That’s it. The revision history should now appear at the bottom.

If you still don’t see it, that is likely being caused by the theme you are using. Unfortunately, that is beyond the scope of this post. You may need to contact the theme creators, see if they offer support, search online if anyone else using the theme has solved the issue, or change themes.

2) Next thing to do is copy all the code in your content edit module. Click your cursor anywhere in the text view, click “command” button and “A” button at the same time to select all the code. Click “command” button and “C” button at the same time to copy all the code.

Copy the code before editing

Copy the code before editing

3) Now paste that beautiful functioning code in a safe place. If you have a Mac, try Notepad. There are also plenty of free, online options if you prefer. For this example, I’m using Shrib I wouldn’t recommend Word or other word processing apps since unintentional reformatting can cause problems with the code. The idea here is simply to have an easily accessible copy of the functioning code in case the changes you make lead to accidentally breaking your page.

Paste the code in a safe place

Paste the code in a safe place

4) Ok, now you are ready for content changes. You have a copy of your functioning code and you’ve made a note of the revision that you can fall back to if something goes awry. Edit your content and test to see that it’s functioning and looks as expected. Publish and check again. If everything is working properly, great! You don’t need to do anything else.

(FYI, You’ll notice that the Revisions module has a new entry at the top. That’s because you just published the changes you made).

5) If the edits caused a problem, you can compare the copy of the functioning code (which you have safely waiting in another place) with what you just changed in the content edit module. I have my copy open in another browser window so I can easily compare one to the other. Perhaps you accidentally deleted or added something to the code that caused it to break? Comparing the two will help you find that error and make the correction. Syntax is key, so any extra or missing slashes, brackets or many other symbols can cause a problem.

Comparing code

Comparing code

6) Hopefully, you catch any problems before you publish and are able to review exactly what you are trying to accomplish or seek outside help. If you discover a problem after you publish then you definitely want to review your code and possibly seek outside help. While that is happening, however, you don’t want your page to sit there broken for all the world to see.

This is where you revert back to the previous functioning version of your site. Go to the Revisions module and click on the version you noted earlier. This will take you to a new page where you simply click on the blue Restore This Revision button on the top right of the page. All the edits you just made will be removed.

uncubed or not to uncubed

Time is flying by. In less than a week our ACLTC capstone projects will be unveiled at the Showcase at 1871. The bootcamp officially wraps up a few day after that.

This morning, I woke up early to review my resume for the Chicago Uncubed event that I am anxiously looking forward to attend today. It looks like it’ll be a lot of fun and I’ll meet some people doing cool things. That’s the good part of feeling anxious. But mostly, I’m anxious because I feel unprepared. Looking for a job? I’m still in bootcamp land, I don’t want that to end quite yet. I’ve never been particularly enamored with the job seeking process, putting together a resume and cover letter. When I’ve been in positions to do the hiring, I didn’t like it either.

Feeling unprepared, it’s tough to work on your resume with that feeling weighing you down. It doesn’t feel like there is enough time to “fix” all those gaping holes in experience and knowledge glaring back at you from the screen. So I didn’t. I closed my resume file.

Instead of going to Uncubed wondering if I have enough experience, if they will be able to tell that I have only the slightest idea of what they are talking about, if I’ll stick out because I still have so much to learn, I’m going to go precisely because of all those things.

I want to learn more about development and design and the processes that bring them together. I want to learn about different companies and their approaches to solving problems. I want to understand what they are talking about. I doubt I can do that if I stay at home.

Beyond that, I want to see what kind of work environment aligns with what I find valuable. Who supports and encourages employees to keep learning? Who contributes to open source? These are all great points raised by Coraline Ehmke when she talked with our class earlier this week, by the way.

So I’m going not to fix what’s wrong with me, but to continue to calibrate my strengths and weaknesses. I’ve learned a ton over the past few months! I knew nothing about rails or javascript or APIs or SOA when 2015 began. Absolutely nothing. Now, I’m building apps. I understand things I didn’t even know existed before.

Today is not a pressure-filled find-a-job-or-die day. It’s a day to go learn more.

My ACLTC capstone project, Hoop Helix

Screen Shot 2015-04-09 at 3.03.32 PM

Here is a first, albeit limited, look at my capstone, Hoop Helix. The basic idea behind Hoop Helix is quite simple: take individual National Basketball Association player stats and visualize them in a unique way that helps suggest a more team oriented understanding of their actions.

In the screenshot above, I have Los Angeles Clipper’s point guard Chris Paul’s top five passing targets and top five passers – that is, the teammates who pass to him the most – to this point in the season. Although not pictured here, there is an accompanying breakdown of assists as well. In the network representation, Paul is the central node and the top five teammates are the outer nodes. Node size reflects the total number of passes made by Paul (on the left) and received by Paul (on the right) according to teammate. These numbers are visible when a user hovers over each node. Right now, the edges (the lines that connect the nodes) aren’t representative of a value, but that will likely change in the future.

So who cares? Well, if I were an opposing team I would make note of the attention that Paul and Blake Griffin pay to each other. They pass to each other quite a bit. Perhaps disrupting that interaction could cause a significant disruption to the Clippers success? As a fan, I simply like seeing the interaction between teammates.

I’ll provide more writing about how I built this in future posts, but for now I’ll just say what I used to create the network graphs. In my ideal world, I would learn D3js or Processing (or both! why not?) to create the visualizations. In my practical world, that isn’t feasible right now so I went looking for an alternative. I found vis.js, a visualization library that includes a network. After more looking around, I found a Ruby Gem, vis-rails.

I’m not exactly sure what type of data I’ll look at besides assists and passes, but that’s all part of what I’m still figuring out. There is quite a lot of data available at NBA.com and combing through it is a research project all on it’s own.

Write/Speak/Code Chicago workshop, part 1

** Initially, I was going to write about my experience at the Write/Speak/Code workshop in one big post. However, I decided it was better to split it into two parts. Part 1 provides a brief intro to the workshop and goes into my experience as a volunteer. Part 2 (forthcoming) takes a deeper look at the intentions, exercises, and outcomes of the workshop.

A few weeks ago, before we started our in-person classes for ACLTC, I attended a Write/Speak/Code workshop here in Chicago aimed at empowering women engineers. More specifically, the full-day Own Your Expertise workshop focused on two key ideas:

1) how to find value in your own knowledge and experience
2) how to present yourself and your accomplishments with confidence

The main payoff being that valuing your experience and having self-confidence are critical to contributing to open source and speaking at conferences, two significant means of communicating in the tech field.

Being someone who is new to coding, which almost automatically means confidence is in short supply, I was immediately interested. In the fields of library science and graphic design, where I’ve had years of experience, I’ve seen how different avenues of communication can help you create a profile and reputation. I was interested in seeing how that related to the tech field as well.

The full-day workshop was free and, by the time I heard about it, already at capacity. Fortunately, I was able to attend as a volunteer. Unfortunately, I had to leave a few hours earlier than the scheduled end of the workshop. So while I couldn’t participate fully or stay for the entirety, it was still well worth the time I was able to spend there.

What follows is my experience as a volunteer, which is one of my favorite ways to attend conferences, workshops, etc. Besides the fact that it usually means being able to attend an event for free, I also look forward to meeting other volunteers. You never know who it will be and what you might learn.

The workshop was held at Dev Bootcamp and featured Rebecca Miller-Webster leading us through a series of exercises. When I arrived, I was asked to greet attendees, tell them about the food, restrooms, and childcare available, and generally help everyone get seated. Some people appeared to know each other, while many, like myself, didn’t know anybody. The room was full of friendly and lively energy as everyone ate breakfast and prepared for a full day. I would estimate that there were between 40-60 attendees in the room.

I was paired with another volunteer and in between greeting attendees and finding extra chairs, we struck up a conversation. Turns out this person (let’s call her Lucy) had been coding for over 20 years. I mentioned that I was in ACLTC and learning Ruby. Lucy starts to tell me about the history of the language and it’s forebears. Then I start asking questions about all kinds of things that are brand new to me, like using terminal. She even explained a few acronyms: things like Bash (Bourne again shell) and TIMTOWTDI (There Is More Than One Way To Do It).

Again, this was before our class had started meeting in person so all I had to go on was doing exercises on my own. Having a person with so much experience to ask questions to was great. There wasn’t anything about a specific coding exercise or problem that I was trying to solve. That wasn’t prompting my questions. I simply wanted a more general, almost informal, history of coding through the lens of someone who’s been through it.

When I’m learning a new skill, I tend to also want to learn a bit around that skill and it’s general field. I’m always interested in the social history of how things have developed and arrived to that point where I happen to be learning about them. I was lucky to have met Lucy, who entertained all my questions and encouraged me to ask more. That is not always a given when meeting someone who has been doing something, and, as I would later learn, doing it quite successfully, for a while.

Throughout the day, I continued to pepper Lucy with questions about what languages she works with, how much she likes working with them, what kind of things she’s made…pretty much anything that came to mind. She was always game. She also offered to partner with me so that I could still participate as much in the exercises as possible, while fulfilling my volunteering duties. I’ll go into those exercises in greater detail in part 2, but I’ll leave you with this. That day, through a combination of the workshop and Lucy, was the first day that I ever called myself a developer.

Test-driven-development is blowing my mind

Over the past couple of days, we’ve been learning about test-driven-development (TDD). Tests, as I’ve come to learn, are written to test whether your code (specifically, the methods) works properly. In some cases, the same person writing the code writes the test. In other cases, you may pair up with another dev and ping-pong the writing: first dev writes the test, second dev writes the code, and then switch.

Testing code is completely new to me. So far in class, we’ve been writing apps in Ruby without tests. So learning about tests has blown my mind on two levels. First, the concept of testing and it’s potential for helping to state objectives and clarity of function is really exciting. Jay also mentioned how tests can aid communication between developers and save time when it comes to adding new features to an app. All that sounds very good and useful and is on the positive side of my mind being blown.

The second way in which my mind was blown is realizing that it’s more work! Just a whole lot more code to write and in a form that is different from the syntax we’ve been using. That’s on the negative side of my mind. I had a feeling of slight discouragement in realizing that it existed, which is kind of funny. I’ve been bombarded with new concepts and vocabulary and all kinds of things for the duration of this class, but this one thing in particular incited a negative feeling. It’s not so much a matter of trying to avoid work. That’s not it at all. It’s more a matter of feeling a bit overwhelmed; of being in the throes of trying to wrap my thinking around one thing and then having this other thing pop up. Even though they are supposed to work together, getting the logic down to make them work together is the challenge.

To be fair, I’ve only known about testing for two days, but with everything else we’ve learned, I’ve had an understanding of the logic and basic execution pretty quickly. With testing, it felt like it was an inversion of what I was learning, as if I had to recalibrate my thinking to accommodate the way testing works. It’s taken me a while to figure out how to execute the tests in the few examples we’ve covered. When Jay goes through the example with Rspec, it makes perfect sense, but when I try it…not quite.

In the strict sense, TDD is supposed to start with a test before any code is written. The test is meant to fail, then from there you start developing your code to get the test to pass. In that vein, I suppose I can view my initial failure to grasp and execute testing as a meaningful first step. Now I have to figure out that second part of getting the test to pass.

Serendipity and Coding

One of the things that I’m most excited about with ACLTC is that among the many things I am learning, much of it is completely new to me, but there are also some areas that I am familiar with, to varying degrees.

Our week covering HTML and CSS, for example, was mostly a week of review for me since I’ve been teaching myself for a few years. That’s not to say I didn’t learn anything new, I did. SASS! SASS is one of those acronyms that I’ve seen around the web but never looked into. Now I know it’s a CSS extension language and even have some inkling about how to use it.

A few years ago, while working part-time for a charter school, I was tasked with running periodic reports on applicants. Where did they live? What schools did they attend? And a few more reports that were more complicated in nature. All the applicant data was stored in Filemaker. I knew how to input the data but the report part wasn’t really part of my job description. So I asked our IT guy how I was supposed to get this kind of info. He ran through some MySQL basics with me and showed my how to export the data to Excel. Then I could generate all the reports my supervisor wanted. Everyone was happy.

Now that we have started to explore MySQL in class, I have a vague memory of the limited MySQL syntax that I learned before. I also have the memory of successfully using MySQL. It’s not much, but it’s a positive reference point.

Much more recently, I used Twitter Bootstrap in building the largest website I’ve ever made. I had noticed a few other sites that use it, so I looked it up and saw it was fairly straightforward to work with. I already had an idea in mind of what I wanted to build – something about basketball and data – making the connection with Bootstrap was the last step. During this past summer and fall, the Black Mamba Myth site was born.

When we covered Bootstrap in class, I was already familiar with much of what was being discussed. It’s encouraging when there are those pockets of familiarity that get sprinkled in with the brand new. There’s a sense of relief almost, because I’m not starting completely from scratch and have some points of reference – even if they’re vague, like with MySQL. But even in those instances where my points of reference are very specific, recent and numerous, like with Bootstrap, there is still so much to learn!

The points of reference also serve as great reminders when I feel stuck or frustrated. I didn’t know anything about MySQL, HTML, or CSS before I learned the first thing about any of them. That may sound obvious, but it’s a neat measurement to keep in mind. I learned one thing about HTML and then another and then another, step by step. Just like I didn’t know anything about Ruby before this class, I’m learning step by step. I didn’t learn HTML all in one day. I’ll get the hang of Ruby and APIs and all the new stuff, just like I got the hang of HTML.

This class is, for me, just the right proportion of the familiar with the brand new. I couldn’t have planned it any better if I tried. It just so happens that the topics and timing of the class align with my experiences and with what I want to learn.

Practicing with routes and controller files in Ruby on Rails

We are a couple of days into the sixth week of the program and have already built a number of small apps using Ruby on Rails. As we’ve been working through the creation of many little apps in class, I’m reminded that practice is crucial to learning something new and familiarizing myself with the process of working with Ruby and Rails.

The process of creating and naming the app in BASH, generating a model and controller, running the rails server, and revising and creating files in the text editor are all steps that seem pretty straightforward. However, there are nuances at almost every step that makes practicing the process so helpful in building a feeling of understanding and confidence that what you are doing makes sense.

A very important part of the process is the relationship between the routes, controller, and views in Rails. Initially, when Jay first ran through the demo in class, I was very confused about what was happening. There was a URL request, some kind of controller, HTML, and all these things floating around that made the app appear in the browser. It was a big jumbled mess that I couldn’t quite parse out.

So I did something that often helps me break down jumbled problems: I drew it.

I drew out the three files (routes, controller, and HTML) that I knew were involved and filled in the info as Jay reviewed it for the class. Normally, I try to mimic what Jay is showing us on my computer, but sometimes it’s best to listen and take notes – especially when I know I’m confused. What I ended up with has helped me so much in untangling the mess I started out with.

Ready?

Here it is!

Drawing from my notebook

Drawing from my notebook

The drawing itself is not revolutionary, but it helped me see what I couldn’t before. Namely, how the routes I specify will dictate what I define in the controller file and what I name my HTML files. I made myself draw it and write out some context so I could go back and use it as a guide. I’ve referenced it many, many times during class as we’ve built the lottery app and the employee app and the e-commerce app.

Having that reference drawing on hand while I’ve been practicing has really helped my understanding of the process and where it could go wrong and how you could troubleshoot. It’s to the point where I feel confident enough to explain what is happening with the routes and controller to someone else. Last night, I drew out a more elaborate representation on the whiteboard while I was trying to help a classmate understand the relationship between the files.

routes1

Whiteboard sketch in class, #1

routes2

Whiteboard sketch in class, #2

Again, the sketches are pretty plain, but they still perform the function of communicating.

In the routes file you specify that a GET (or other) request to a URL will route to a given view, which is named after the hashtag (#). What precedes the hashtag is determined when you create the app in terminal to begin with. Whatever name you give your controller (which should be plural) will be the same name that you enter before the #. The URL and the view do not have to be the same.

In the controller file you define each view that you already named in your routes file. Jay has mentioned that this is not required for the app to work, but that it is best practice to do this. I can completely see why. It’s a step toward keeping everything organized and expressing relationships, which are always handy if something is not working as expected. In some cases the views being defined don’t require the creation of any variables, but in most of our practice examples they do. This means that within the appropriate view, you specify an instance variable (and how it might relate to the model, for example) which will then make it possible to call that instance variable in the view.

Which brings us the view files. These are the HTML (html.erb to be exact) files that you create so that the URL requests that were specified in the routes have something to show. The HTML file names should be aligned with the names previously specified in the routes and controller files. Whatever comes after the # in the routes will be the name of an HTML file. If you specify three distinct routes, then you should have three distinct HTML files. If you specified an instance variable in the controller, you can call it in the appropriate HTML file so that it can be displayed.

And that’s it. As far as I can explain it. I’m still unsure about the language I’m using at times (am I setting up a routes file? or should I be calling that something else?). And I still get a bit lost switching between rails console and terminal and figuring out if the rails server is running in the proper folder, but all that will improve with practice.

Vocabulary: Rails, routes, views, controller, model, instance variable (in Rails, different from Ruby instance variable), rake db:migrate, CRUD, SQL, REST, rails console, rails server, GEM, bundle install