AJAX. Down the rabbit hole …

Hello!

First things first: Ajax. Ahh, ajax *sigh*. I will warn you that this is yet another selfish post, where I try to justify what I’ve learned to myself. I hope it remains interesting to you regardless.

After a few days of working with javascript and JQuery ($$$), we had our first introduction to AJAX. This morning’s lecture started off ok, but ended with a sore forehead (from furrowing my eyebrows so much. I didn’t know this was even possible). That said, after reviewing it this afternoon I think it makes a bit more sense, but the more I thought about it the deeper the rabbit hole went.

Taking a step back from the rabbit hole

We keep hearing the word, ‘asynchronous’, and initially seemed a bit ‘jargon-ey’. That said, it turned out to just means that a task is requested, and while that task is being processed and returned, other things are being done. This raises the question, ‘what is doing the task? Is the browser asynchronously? Is it the server dealing with requests asynchronously?’. As far as I understand, javascript is handled asynchronously, and it is therefore the browser that is handling asynchronous requests. If javascript is special for its asynchronous execution, then we can infer that typical scripts are not asynchronous, and therefore synchronous, or sequential.

In addition, I found it helpful to revisit the DOM tree and its contents, in order to understand what AJAX did, in comparison. The DOM tree is comprised of the window object and the browser object. With each full HTTP request (regardless of which of the RESTful actions we are taking), the DOM tree is regenerated.

Peeking at the rabbit hole 

JQuery is a tool we can use to work around this necessity to regenerate the whole DOM tree (which would take a lot of time for intensive site and be pretty data-heavy). JQuery is a javascript library which facilitates writing of javascript code for user interaction on web sites. At this point (6 weeks into a boot camp …) I finally realized that a library is not just some static reference document, but it is a document that ties shorter code that we write, to a fuller form that is actually executed when the code is processed. The crucial bit here is that the browser is able to map the code that we write to the fuller form and executes it accordingly.

Knowing this, JQuery is a library of ways to manipulate the DOM. It also contains methods of tying these DOM manipulations to events initiated by a user interacting with a web site. In JQuery, we select DOM elements by their html/css identifier, and then apply a manipulation to it. We can also tie ‘event listeners’ to these html/css elements, and react to these events. In typical JQuery, everything is handled solely by the browser and as such, additional information is included in the front-end code. For example, if we want to insert a new html element using jQuery, we specify what this element is being appended to, as well as the html element itself (is it a div? is it a list item? what text does it contain?).

Stepping into the rabbit hole 

Now, going back to AJAX, what is its state (if we’re thinking of it as an object) and what does it do?  The wikipedia page provides some helpful resources, including the following:
‘Client-side technologies / techniques that allow two-way communication between the client and the server’.  I think most definitions I’ve seen tend to indicate that AJAX is not the technology itself, but it refers to the technique, or method, that is done using several technologies (including asynchronous JS, XML, Json, etc). It is also a function in jQuery.

The way that we are using AJAX, it is almost a tool used in a subset of jQuery cases. Ajax is used to bridge the browser-server divide, request information and retrieve information from the server for rendering in the browser page. The result is a manipulated DOM element (with the remaining DOM tree staying the same), with changes reflecting information from the server. For example, if we wanted to show a few list items each time a (‘show more’) button was clicked, we could use ajax to retrieve a partial ‘view’ page containing a few additional items, then insert it into a jquery request to append this information to an existing DOM element.

 

Why does it even matter? 

At first, when I heard about AJAX and jQuery, I struggled a bit with understanding why this even mattered. Being able-bodied in a metropolitan area with decent internet service, it’s easy to forget why this matters. However, in addition to the accessibility issues that we discussed in class, I started thinking of specific cases where the load time affected what sites I visited. In each case, a careful consideration of initial load vs subsequent loading would be helpful:

• Internet can still be painfully slow in remote areas. For example, when i was working from a motel room in Terrace Bay, I could only access the ‘light’ version of Outlook, gmail, because things took so long to load. Sub-par internet is still very real for a lot of people. AJAX would have made the request/response cycle easier, but the initial load wouldn’t complete in time.
• More recently, when I’ve been trying to use the free wi-fi on the subway, the load time for a full request/response cycle plays a big part on what web sites I visit. For example, today I attempted to visit coursera, but couldn’t even get past the initial sign in , before leaving a stop and the internet cutting out. In contrast, I am able to read individual emails from my inbox in gmail even while the internet is shut off because it is part of the initial loading.
• Being on a 350 mb data plan, I’m relatively aware of what I use the data on my cell phone plan for. If ajax can help reduce the amount of full request-responses and reduce redundancies, this is good news.

As we learn more about these technologies, I think it’ll be interesting to see how we can actively make choices to integrate progressive enhancement and graceful degradation into our web application designs.

Big whoops.

Hello reader! This week has flown by! There has been a lot learning and a lot of things going on.

1. Mistakes

First things first, Seat Yourself. Seat yourself is the name of our group project that we started working on last week with a purpose of connecting diners with restaurants. While we were working on this project the day before it was due, we noticed some strange things. Errors we thought we’d fixed were back. Then, when we checked out one of our controllers, whole methods were missing.

As it turns out, once we broke off into pair programming, we would commit and push to the origin. However, I had managed to pull changes, carelessly accepted crummy merging and pushed to the origin master. BIG whoops. I don’t remember the exact details of what happened, but looking through our commits, I’m assuming that in my rush to wrap up the work for the day, I’d rushed a commit and caused a massive error. Thankfully, my team members were incredibly forgiving and nice and helped us get back on track ASAP. I think there’s 4 major morals of the story:

Slow down to speed up

I hate this idiom, but I absolutely see the value in its message. When I was a kid, I was constantly told to slow down and focus, in order to stop making careless mistakes. Even as an adult, this still holds true. It’s exhausting, and requires immense strength of will but it’s absolutely true. When we mess up because we’re rushing, especially something as big as the mistake I made, there isn’t a good excuse.

Commit commit commit, and write descriptive messages. Check commits!

When we did realize there were big commit errors, we called for help and ended up going through gitx to find out exactly where we lost all of our data. As it turns out, we hadn’t caught this until 5 commits and a few other merges had happened. We were strongly encouraged to check gitx every time we do a merge and just make sure things were ok.

One thing to note is that gitx only seemed to colour the first line of entire sections that were deleted or added. The positive and negative signs were used to keep track of what happened, and we ended up copying and pasting our code back into the controller.

Have a great team. Appreciate team members. 

This mistake could have completely soured our team. It wasted a few hours in a program where time is so limited. Instead, my team members were incredibly forward thinking and focused on finding the ‘where is the problem’, without focusing on the fact that I had done this. No one yelled at me. Instead, they focused their attention on solving the problem and fixing our program. I am honestly so thankful they reacted the way that they did.

Afterwards, we were required to submit a single group submission, so we submitted my github page, and all decided to fork as a bit of a failsafe (and I made a clone for a version 2.0). In case you are interested, the work in progress is at: https://github.com/mokutsu/seatyourself2.

2. Javascript

Second thing about this week: Javascript. We’ve taken a dive into the world of javascript and jQuery. It’s been pretty interesting comparing the similarities and differences between Javascript and Ruby. Javascript seems to have less built in features which can be frustrating and some concepts such as ‘this’ are still proving to be tricky. However, being a bit of a ‘verbose’ programmer, at this point, I really like the explicit looping conditions that Javascript.

Debugging in javascript has also proven to be challenging, and using the right tools becomes key.  After struggling with debugging with node in the console, it became clear that I should be debugging in the browser. The dev tools provided in Chrome are friendlier, and allow for more ‘poking and prodding’ to see what variables are being set and which ones aren’t working.  This has highlighted the need to code in chunks and test more frequently to see what’s working and what is not as well. It looks as though slowing down to go faster will hold especially true as we get deeper into JS.

In rails, we were able to see the error thrown back by the framework, correct it, receive the next error message, and continue to build the website in an ‘error-driven development’ methodology. At this point, it doesn’t look like this will be an effective way to write code with javascript, which will be challenging. However, hearing about some of the ways that javascript is being applied across the board, I am very excited to learn more and play some more with this language.

 

Update on Team Working

Since the last post, we’ve had another day of working on our team project. I remain convinced that this has been an amazing learning experience in seeing how others perceive a problem and how others would fix things differently from how I see things. It’s also been a joy having 4 people read through the rails documentation instead of just having to sift through it myself. The questions we come up with as a group are also quite interesting and the depth we reach is a bit deeper than I would have thought about things on my own.

For example, yesterday, we were discussing global variables and helper methods and were wondering if it was bad practice to rely too heavily on these. However, as we discussed this with an instructor, we dove into why we thought global variables were bad. As it turned out, global read/write/access was the reason that global variables could be potentially dangerous. However, the way that we were using helper methods and instance variables across our application was really limited to global reading access, with no real writing access. This thought process though was something i may or may not have had alone, but was good to get a discussion going about.

Goal Setting and Planning

In a world of instant gratification, it’s easy to doubt our happiness and quickly doubt our unhappiness. “Am I really unhappy, or am I just unhappy with things right now? Am I just mistaking this for true unhappiness? If I make a change, am I giving up long-term reward for short-sighted thinking? Am I just being ungrateful and a typical millennial?”

Yesterday, we had a guest speaker who introduced us to Wait but Why’s series, the Cook and the Chef. Although the blog is about Elon Musk, it is ultimately about the process of self-improvement, and how to define, achieve and refine our goals. The talk was really well presented and during the whole presentation, I kept thinking to myself: “if only I’d thought this way when I was making my changes, instead of jumbling the process!”.  The methodology suggested generally was as follows (check out the blog for better descriptions):

• identify goals (all of them! Don’t be shy!)
• define reality…but don’t get bogged down in conventional wisdom
• Figure out the goal pool: i.e., where your goals overlap with reality
• Figure out an action plan, and a feedback loop to refine the goals
• Continuously reassess, and compare every step against data

This message resonated with me. I had experienced a good year (or more) of cycling through aspirations followed immediately by self-doubt and self-defeating thoughts, punctuated with long sessions of anguishing over the details of why my aspirations were crazy, and why my dissatisfaction wasn’t real.  Perhaps you can relate to my thought process: “I’m unhappy, I hate this…but am I really unhappy or is this just me being unhappy right now now? Well, maybe let’s look at jobs and apply…but who’s going to hire me? I don’t have the right degree, I don’t have the right experience, I’m not good at this or that. Shouldn’t I be grateful for what I have? How can I be so ungrateful for my position? I should be appreciating the opportunities I’ve had more. I’m too old to be switching careers anyways, people only hire others for Y field straight out of university”. I’d mull over this whole cycle of thought for hours as I shuttled between cities or late at night, as I’d try to fall asleep. (protip: Existential crises are not good sleep aids. Try picking another time of day to ponder life choices). 

In retrospect, had I followed the suggested methodology in the talk, I think I could have defined my goals and started my action plan much sooner (and had more confidence in myself in the process). In a brainstorming session, I would never dream of trashing another team member’s ideas while we were still generating ideas. Why on earth did I think it was ok to do this to myself?

Once I was a bit more certain that I wanted a change, I started reconsidering, and my own method in figuring out a career path was far from illogical or non-methodical (in fact, I followed the methodology recommended in perennial classics like ‘what colour is your parachute’, ‘the pathfinder: how to choose or change your career …’, ‘I don’t know what I want, but I know it’s not this …’, etc.). Based on this, I took the following approach :

• look into why i was unhappy, and to what extent. Make a deadline for myself for when I definitely wanted to be out by.
• read books and internet posts, try to see what I was good at, what I liked, what I definitely didn’t like
• narrow down to 2-3 career paths and map out a few ways to get there
• do a cost benefit analyses for each map and pick one

Although they all suggested some form of reality check, either they suggest doing a reality check of my reality check, or I simply didn’t hear the advice or think it relevant. The problem with the method that I used was that I didn’t separate out my goals from reality, and I didn’t do a good reality check in the earlier stages. In fact, my perception of self was so distorted at this point, I had a real struggle figuring out anything I could potentially be good at. I had a hard time committing to a career path with this lack of confidence as well, since I’d constantly be wondering “but what if I suck at this? I would have wasted X years to find this out, and be out $YY, and maybe I’m just better off where I am now”.

With these limitations in mind, I realized I was quickly approaching the timeline I’d set for myself and had a deep thought about what core things I liked and disliked about my job. With a steady fear of ‘analysis paralysis’, I ended up giving myself a deadline to figure out what I liked, didn’t like, and what my next steps would be, and some form of end goal.

I ended up picking web development because it seemed interesting, it felt like I was joining the rest of my friends in the 21st century (not to say that mining is low-tech by any means, but it is different!), it was still analytical with some creative flair (like my last career), the job seemed quite flexible, there were jobs in cities, and the self-help books and websites I’d read had suggested I might be ok at it (so maybe this was something even I could do). It fit my picture of myself and my shaky reality. As I continue on this journey, I’ve become more confident in my own abilities and choice, and I’m quite glad (at least at this point) that I’ve made this change. I feel like I could be at least okay at this (if not good at it, some day after much more work), the people I’ve met are incredibly supportive and interesting, the community here in Toronto is alive and kicking, and it’s amazing to see what we’re building from scratch (and the conscious decision that goes into every single web page).

That said, after hearing this talk, I am starting to toy with the idea of learning data science and machine learning again, even as a hobby, now that I’ve shifted my perception of reality. Maybe I am capable of learning this. Maybe it’s not so crazy. Right now, things are busy, but I’m realizing that there is never time for things we don’t make time for. Let’s see how things go.

Anyways, long story short, quality talk, left inspired, lots to chew on. Back to rails!

Teamwork and Quartet Programming

Hello there!

When we talk about the core functionality of an app, it can be difficult to come to a consensus for some things as basic as “what does this app need to function?”.

Today, we got our feet wet in our first free(er) form team assignment to develop an application for customers to be able to make dining reservations at restaurants and it was helpful to let the notion of ‘this is common sense, isn’t it?’ take a back seat to ‘ok, let’s hear it’.

I am luckily a member in a group of 4, very competent and friendly people, and sometimes that means that we’re all very vocal when we disagree. It was really interesting to hear 4 relatively quiet(er) people have such a lively discussion. I think overall that it was an extremely helpful exercise in figuring out what exactly an application must do in order to function, and actually convincing ourselves of the priorities that we’d set for ourselves.

For example, we discussed that the restaurant model (in the MVC) must have some sort of logic to reject reservations if the restaurant would exceed its capacity. It seemed quite clear to me that there was no point in having an application to make reservations if you could make as many reservations as you wanted without input from the restaurant of any sorts. However, we then started discussing other factors like restaurant hours, days of operation, that would also factor into how useful this application would be in the real world. We then realized we had 4 school days to achieve this and it’s been less than  a week since our introduction.

Understanding our limitations, we decided to make assumptions in order to progress forward, and left such logic as restaurant capacity and hours of operation to our second sprint (yes, we are making quite small sprints, but I think this helps us in producing a functional app when we approach our deadline!).

After we worked out our plan on the white board for a couple hours, we progressed to quartet-programming (programming with the power of 4 eyes on 1 screen!) for the initial creation of the repository, the rails project, the models, controllers, routes and some views. It initially seemed a little clumsy at first, but it quickly proved its worth. I can see how this would be extremely helpful for:

• agreeing on and visualizing the models, model relations
• agreeing on and visualizing  controllers (and their actions), necessary views, model relations and how the routes are related to each other
• agreeing on naming conventions and how to break things up so that it’s easier to format down the line (e.g. everyone using divs at each level of their forms)
• picking up typos
• having someone look for logical errors, other people looking for syntax errors, and multiple eyes to comb through the code
• keeping the team informed of changes or difficulties as they’re encountered
• getting exposure to other people’s strengths / your own weaknesses and vice versa (e.g. I’m ok with visualizing routes and how they relate to actions/models and model relations, but I’m terrible at remembering syntax)

Moving forward, we’ll be breaking into pairs, but this was a very helpful exercise. It’ll be interesting to see, at some point down the line, how this process works with a test driven development approach, or if a larger, more diverse group of people are involved in the planning phase.

Anyways, onward to rails guides! Woot woot! (…sigh…)

 

 

 

The long winding road …

Adding onto this last post, in case it wasn’t clear, the boot camp has turned up a notch this past week, and it’s definitely the start of a long and winding road. Up to this point, I feel like much of the course content was manageable by doing extra prep work and being extra prepared but rails has been a wholly new experience (and quite the kick in the butt!).  Coming from a relatively technical background, it’s been very humbling to realize that I can’t just break-to-basics-code-my-way through this like we were doing with the fun ruby and sql exercises. I do  need to sit down, read the docs, learn the syntax, ask for help and actually listen (the listening part being the hardest part for me personally). 

For example, this past week, my objects/edit route decided to quit. I spent two whole freaking hours trying to debug this problem and spinning my wheels. I peeked over at my classmates’ screens, made small talk about this stupid error I was having, scratched our heads a bit, and within the many half-hearted suggestions I got, was the answer, though I didn’t realize it at the time. I gave up, went home, and sure enough the next morning, found out that because I’d defined my edit path below my object/:id path, the “edit” portion of the url was being recognized as a form of :id.

Two hours of my life that I will never get back. In a previous life, this would have been two hours that I wouldn’t know how to charge on a time sheet, and would have had to eat. Two extra hours I would have had to work to have the minimum 40 chargeable hours. TWO HOURS BECAUSE THE ORDER OF MY ROUTES WAS SET UP WRONG. Not only this, but two hours that I could have saved had I skipped ahead and just used resources instead. The next day, I told my class mate that his suggestion was right, but I was kicking myself for not listening more actively.

Moving forward, I think I’ll actually be using a timer so that I force myself to walk away from a problem if I can’t see it within a reasonable amount of time, and actually opening up to people sooner and taking the feedback more seriously!

Likewise, today, I spent three hours just reading through and inserting comments on my models, views and controllers we’d generated with a class mate, which has honestly been one of the most helpful experiences thus far. I think repetition makes for muscle memory and ability to reproduce, but actually following through each step of the code can be equally helpful (albeit time consuming and tedious at times). As we went through and started identifying things we didn’t know, the more we started seeing things we didn’t understand. Again, incredibly helpful, but a solid butt kicking none the less.

Reiterating the point above, DevHub hosted an event tonight titled ‘Dear Junior Developer Me’. I was a bit worried that this event would be just repetitious and time I could really be using to better learn rails. However, it was a good opportunity to hear what people had experienced and what their thoughts were. I was impressed by the overall supportiveness of the community and the quality of the discussion. I’m really looking forward to learning more as we move forward!

Unpackaging the Rails Magic

Hello there!

so for the week or so, we’ve dived into rails and have been working on building a website with sessions, user logins, and a few models. Now that I’ve had a chance to copy and paste, and then carefully read through the code, it’s fairly incredible how much rails puts together behind the scenes, and it can be a bit daunting trying to distinguish the magic from the user-instructed inputs and understanding how everything ties together.

In particular, I’ve been quite interested in active record, the object-relational mapping tool that interfaces between our databases and ruby-based models. Although it’s summarized in just 3 letters, its ability to connect these 2 different sides to work harmoniously is really quite amazing. As someone who is still chewing on the concept of different relations between objects, it is quite interesting to see how rails and its many gems augment the user directions to produce real, functioning websites.

As we move farther into rails, I’d love to try and tinker a bit more (and hopefully not break things) to solidify my understanding of the ‘rails way’ and its flexibility.

 

 

Aspirations

Hello again. As mentioned earlier, I’m going to strive for posts of a reasonable length. Speaking of striving, I thought today would be a good day to touch on this, because it is a topic that I’ve chewed on more frequently over the past couple of years.

As a caveat, I realize that this is a very personal topic, and in no way is this coming with negativity or judgement because I am in no position to judge. Trust me. I’ve come to break down self improvement in a very bite-size way, and I’ve broken this down into 3 main questions:

1. What could I work on improving?
2. How can I make this change starting today?
3. How do I make this change a long-term thing?

Question 1: What could I improve on?

Sometimes, the thing we need to improve on, or want to improve on, jumps out at us. I want to learn to play the trombone. I want to eat healthier. I want to be skilled at math. etc etc. The list could go on forever, and the scope of our ambitions sometimes far outpaces our commitment, which is problem 1 in making lasting changes. I admittedly struggle with underscoping or overscoping this, but it’s been massively helpful to me to take a moment and consider the scope of improvement I’m considering. Can I run a marathon if I give myself a month if I’m a couch potato? No. Can I run 5k? Probably not. Can I start using couch to 5k? Yes, yes I can. As I go through this process, I then try to ask, “why this?” “will I like myself more for making this change?”, “will I be happier?” and “will this make me a better person?”.

Question 2: How can I make this change starting today?

I think this ties back into the first question in making bite-size change. If we break down bigger goals into smaller tasks, it becomes manageable and fun. I can start playing with this rails framework and debug it when it breaks, in my quest to learn to code. I can reduce the amount of meat I eat in my quest to be more sustainable. It becomes a game, where I can challenge myself.

When one of the staff at the boot camp suggested starting a blog to chronicle our experience, I was quite skeptical and concerned that this would ultimately be an effort in publicized vanity. However, it was an immediate change that I could make and as it turns out, it’s been a surprisingly good tool for reviewing our learnings, introspection and reflection.

Question 3: How can I make this change long-term? 

To me, this is truly where the challenge lies. Managing 1 and 2 helps, but we still face the inevitable desire to go back to familiar ways. My number one step in this is to make something a habit. By making small changes but doing them consistently, I think it gets engrained a lot better into our lives than to make sudden large changes, implemented periodically. I think this is a huge part in why the boot camp model is such a great way to learn skills. By doing things persistently and continuously for a period of time, we can learn so much and it becomes a part of our lives that we learn to embrace. It’s engaging. It’s exciting. It’s fun.

On a side note, I’ve found that this approach in general has actually really changed my life over over the past couple years. I went from barely active to 10k runner. I went from eating garbage-esque food to whole grains and beans. I went from being uncomfortable with dressing in anything remotely feminine at work, to having confidence and pride in being a woman and how I look. I went from being passenger to a driver. I actually like waking up now. I am seriously excited about what we’re learning, and who I’m going to be after this boot camp.

 

 

Brevity

Brevity is the soul of wit. Undoubtedly, writing as much as you need and no longer is a good rule to go by, and I am going to make a greater effort in this regard, as we move onward (and in my code too!), or at least break my posts into readable multi-part posts.

Ok, so here is today’s technical post.

Error Driven Development

Our instructor mentioned the term, ‘error driven development’ during today’s lecture and it’s really resonated. Throughout the rails process, every step is checked by rails and any slight deviation produces an error. I think that as a learner, making mistakes is crucial in learning what the rules are, and as an approach, perhaps error driven development may not be the worst way to code (for now at least).

Taking a Step Back 

Towards the end of today, I also realized that I didn’t really quite grasp what a server is and what a framework is when we talk about “the rails framework” or “the rails server”. I think we all have a fuzzy idea of the concept, but it is important to at least try to understand what we mean when we say these words.

and a bonus side note….

On a side note, I was going through my old field gear and found some medium sized, thick-plastic sample bags. As it turns out, these are the perfect size for my mac book and case(s), for extra protection on rainy days! Freezer bags may also work, will need to check at some point!

 

Using the Right Tools

Hello there!

The past few days have been a bit of a whirlwind, so I’ll jump right in.

The right tools and Object Oriented Programming

If you recall, my last post was a rather lengthy ramble on object oriented programming, and getting objects to interact. As it turns out, I had a chance to talk about this some more with some folks, and here were the conclusions:

• in most cases with web applications, you only need the instance variable to be “alive” for the duration of that request, such as using an instance variable to store information regarding a particular object that you want to show or view or update or delete.
• if you need this class instance to survive beyond individual server requests, then this information would typically be stored in a database
• Global variables don’t seem to have much protection (i.e. limitation of read/write access doesn’t seem to be a thing), so should generally be used with caution. If you’ve got a lot of global variables going on, it’s probably a good time to step back and reconsider.

 

Databases 

Speaking of databases, we jumped into SQL-land this week! Speaking of data, this would be a good time to throw in a plug for Big Data University and Khan Academy as I’ve found these 2 resources to be quite helpful in my previous dabbling. Khan Academy was the right balance of instruction vs. sandbox for me to learn and play with columns/queries/rows, while Big Data U’s in-person meetups here in Toronto supplemented some of the rather large leaps in content I was facing with a MOOC I was taking at the time, on R programming.

HTML/CSS and Ruby Lightning Talks 

Last week, we also had a day to decorate our very first web application, using html and css. Overall, I ended up spending an embarassing amount of time on this, and quickly cycled through the following 5 stages multiple times over the course of a couple days. I’m sure everyone who is not versed in CSS positioning witchcraft may recognize this:

• Denial –  I’m sure it’s just a missing semi-colon or some syntax issue, let’s just retry float. Hmm, absolute positioning? Ok, let’s try relative. Fixed? Have we tried float yet? Ok, let’s just try relative and  float. How about absolute?
• Anger – Ok, I know that I’ve set my margins and padding correctly and I’ve got my syntax down pat. This is not me.
• Bargaining – I can live with text scrolling over the banner, it’s functional right? And who cares if these 2 columns don’t start at the same height on the page? Win the battle, lose the fight, am I right?
• Depression – I’ve spent how many hours on this? Why is this taking so long? It’s me, isn’t it?
• Acceptance – I guess this is just how my website is going to look. Ok. I think the picture below pretty aptly describes this stage. Lots of head scratching, and “what? why?  um, ok, I guess.”

Figure 1: Self portrait, created using CanvasPaint (2016).

Eventually, I got it working, but sure enough, this week, I attended a Ruby Lightning Talk event, which included a presentation on Flexbox. If only I’d known a week ago!  I guess we live and learn.

Rails

Today, we started on Rails at last! It’s been exciting so far! Finally, the content from the earlier RailsGirlsTO event on presenters was starting to click, in a vague and fuzzy way. After finishing today’s assignment, I decided to play around a bit some more with creating a web application to store hiking trails. As it turns out, I think I have a knack for playing around and breaking things (but it’s been fixed!). Here’s what I learned in the process:

• Rails is a framework that ties together many things, including ruby, a database, html/css formatting, other dependencies, and the rails framework itself. Although the rails documentation is a good starting point, you may need to go to the documentation specific to what you are working on. For example, I tried to create a database with columns of various data types including strings, integers, and arrays to store names of trails, trail lengths and latitude/longitude pairs for trailhead location. As it turns out, SQLite3 doesn’t support arrays as a column and had to be fixed through some further horsing around with migrations.
• Convention convention convention. What more can I say?

Anyways, post over, good night! Excited for tomorrow’s visit to 500px!

p.s. speaking of 500px, and being extremely out of the loop, I decided to check out the site and sign up for it yesterday. I was immediately hooked by the positive community! Check my (admittedly quite amateur) photos out! link here!