AJAX. I’ve been thinking a lot about AJAX recently, trying to relate new discoveries in Rails back to my introduction to Backbone.js and more recently, the excellent tech talk about Ember.

The whole idea of calling a server and loading webpages repeatedly, feels so…2005. It seems so much cleaner and more professional to make one request to a server to load the entire page and be done. Pages have become incredibly complex and so much can happen on just one section of a page let alone the entire page. Not to mention, mobile use is revolutionizing the entire concept of what our web experience is and the last thing we want as web developers is to limit our mobile users’ experiences. In addition, with what is already being done with WebGL and the canvas element in HTML5, I simply can’t imagine how much our web experience will change in the next 5 years. Given this paradigm, it is absolutely imperative I embrace AJAX and all the possibilities it can provide for a more efficient and joyful web experience. I have to face the facts, the web is getting more sophisticated, elegant, and abstracted.

First, too quickly review, AJAX provides a channel for passing back and forth data from a web server without having to make additional calls to the server to reload the entire page. Below is the chart I presented from my last post that provides a visual explanation of AJAX.

Rails of course already integrates the use of AJAX into its framework and it is quite effective, especially in how it handles forms. Without AJAX, if a form is filled out and the submit button is pressed, and event is fired off and a Post call is made to server which refreshes the entire page. AJAX sends the information without refreshing the page. In my case, for practice, I created a simple, very simple Rails app to try and get a form working in this new format. Here is my controller:

In this form I tried a variation on the responds_to method placing it at the top of the controller so it affects each action.

Next, I created an html.erb file that holds the mark up language for the page. This page is pretty straight forward and holds the references for the JQuery.

Next I created the js.erb files that integrate ruby/rails into js files to manipulate the forms on the page with toggle methods.

These files are where the action takes place. I feel like the js.erb file is where I need to spend more time learning how ruby integrates into javascript.

One of my goals for my group’s project is to integrate some AJAX functionality into our web app to make it more efficient and user friendly. I decided to experiment with some hidden forms after reading about them online. The hidden forms are AJAX forms that display on a toggle

Though I’ve tried to change and move different elements around I’m still not able to get the form to appear. I’m really excited to figure this out though because integrating a Rails backend into an AJAX controlled front end will make for a dynamic and more sophisticated web site.

This past winter, I spent the last week of my Front End Web Dev course with Jon Grover going through a marathon of 7+ hours of video, learning Backbone JS. I didn’t really understand much of what was going on and was just barely keeping up with the syntax wondering what the point of create, update, and destroy were and how to keep up with all those damn semicolons during the code along exercises. If only I knew then what I know now. After Wednesday’s lab review, I think I am beginning to put the pieces together.

First, let’s discuss what is going on between Ruby/Rails on the back end and the web browser/Javascript on the front end. It’s like juggling chainsaws keeping track of everything in a Rails app. Throw in Javascript and jQuery in the browser on the front end and it’s like juggling chainsaws while trying to code along with Steven during a morning lecture! After the lab review with Steven, I decided it was time to make a diagram of what is going on…

Okay, maybe that’s not the best description of what’s going on, but hey, we’re in project mode man. Alright, all jokes aside, the diagram as promised:

I think of the server and browser as being two separate containers holding completely unrelated content. In the middle, is AJAX which functions like a bridge. On the bridge the only possible thing that can cross is a “string” we refer to as JSON. Even though Javascript is in the acronym, JSON is still just a specifically formatted “string” that can be translated to various programming languages. AJAX is the channel for passing the JSON through front end events(think mouse clicks) in the browser.

When JSON is passed from the browser to the server, it gets converted in the Rails controller into params that can be read by the Rails action/methods. Going the other way, the params get converted into Javascript object attributes by Rails through the ‘responds_to’ block. The one key is to remember the entire time, this information is being passed through in the format of a “string”.

Does that mean creating two sets of objects in models into separate containers? Yes, yes it does. I write JS I write Ruby at the same da…

They’ll probably never read this, but I gotta give a shoutout to my future coders and ALL of my former students from Parkway down in Miramar on the Dade County line.

The database is probably the most important part of a dynamic web app and the database is organized as Ruby objects. Given that the only thing the server and browser containers can share is a simple “string”, both containers need their own objects to keep the app organized. This dictates how the database will be presented in the browser. Object oriented Javascript becomes the method for maintaining consistency across the bridge that is AJAX/JSON.

If the objects get duplicated then the controllers must too. Controllers with Post/Get internet actions, models/objects for organizing the data, and views for organizing how the data will be presented in HTML have to be created. One area that I think is confusing is understanding how the erb files work on the internet. The key to remember is that the browser only uses Javascript so the views must be a composite file of Ruby erb for the database, Javascript/jQuery for the browser, and HTML for markup of the pages. It gets pretty crazy keeping track of 3 different languages in the file that a person visiting the site experiences as the entire web app!

THIS, pun intended, can be very confusing. Given how effective Rails is at abstracting away a lot of the clutter, why not do the same on the front end? What if I told you…no just kidding. I won’t go into too much detail in this blog post, but there is NO “what if I told you” in this blog post or in the real world. I am still figuring all of this out for myself, but nonetheless there are several competing JS frameworks including Backbone, Ember, and Angular that attempt to reconcile the conflicts between Rails and the browser and follow the principles of conventions over configuration and RESTful paths. When consideing which framework to choose, this comes to mind…

…unfortunately there is no clear choice, only corgis…or cats…

…and all these frameworks ultimately do the same thing, hence the confusion.

Initially, I thought I’d stumbled onto the holy grail when I went back and reviewed my Backbone labs, but then I went back to my chart and realized there was a problem. There is only one view shared by both Rails and the browser! There is no way to create separate views that detach the Ruby from the Javascript. To say it succinctly, there is only one browser window and it is written in Javascript. After doing further research on the internet about these frameworks, the whole situation becomes a lot more complicated. There is no magical “what if I told you” moment for reconciling the conflicts between Rails and Javascript in the views, only lines on lines on lines of code…or racks…

RACK UP!!

There is only a range of options with various strengths and weaknesses based on need and personal preference. I am beginning to see why at Flatiron we have not received a clear answer to our questions about which JS front end framework to use with Rails or if we even should use a JS framework with Rails. In addition, I am also beginning to see why some developers just turn to Node and create an entire full stack JS web app. Finally, I think I understand why Steven is so excited about Volt as it appears to abstract away JS entirely, letting Ruby covert to JS, a layer below the coding, while maintaining the consistency and elegance of Ruby on Rails.

Till next time when I break down the choices on the front end, in honor of the end of labs and green lights, and it being Friday, I leave you with…

Peace out we in project mode!

Octocats Rule!

At this point in my Flatiron journey, I am rapidly approaching the deadline for my first presentation and project mode is just around the corner. Man, I wish it was still week 2! Anyway, the more I’ve thought about building an app the more I’ve thought about where and how to start, beyond of course, an idea for the app. Based on the brief research I’ve done, planning the models and database seem to be the place to start.

One major concept that has come up in Rails lectures is the idea starting with a vertical slice(thanks Steven) and in doing research on the internet, I came across an acronym, MVP which stands for Minimum Viable Product. From the beginning of Rails, I have been very concerned with the idea of planning before implementing during project mode and have been reluctant to accept how flexible and modular Ruby on Rails is in practice. Now though, after spending some time reflecting on what we have done so far and researching on my own, I am beginning to develop a sense of how to approach development and planning and I’m ready to take the plunge.

If I’m not mistaken, vertical slicing and MVP are very similar in nature. Vertical slicing means to create one model from top to bottom as opposed to trying to build out horizontally an entire collection of models. This is very similar to MVP in that the theme is to get the app up and running first and then build out the entire scope of the app. An example of this might be in a generic app getting the user registration finished before trying to build anything else. I’d start by creating the view, model, and controller and creating the routes and actions to create a user database and then get the routes fully functional in the browser before expanding the app. It’s useful for me to be aware of this kind of approach as I am the type of person to start out thinking I’m building a simple app only to draw up some crazy collection of tables on a whiteboard and decide to build them all at once.

Planning out associations at this point is also essential. One critical question I learned from research is: Is this feature necessary? This applies to both models and associations. In getting the app up and running, every model and association should be very intentional and the build process should be methodical. Using the MVP strategy is especially important when working on a deadline. Before starting a project, having the specific goal of what the app should do at a minimum allows for more focus on creating the app as opposed debating what to include and being forced to pare down features at a later point in time. Like any significant undertaking, I imagine this is much easier said than done.

As I started to write the blog post and reflect on process, I am beginning to think perhaps there should be two separate diagrams drawn up in the early stages of an app’s development. Having two physical diagrams to compare is useful for communication between team members and building consensus about what are the absolutely necessary features to to be added to the app.

It’s all too easy to get caught up in trying to build and do everything. Having distinct stages allows for more dialogue and shared purpose as the development progresses. The first, and most important stage is the initial brainstorm/discussion about what the idealized image of the app could be. At this stage no idea is a bad idea and the discussion can hopefully avoid conversations about what can’t be done. In other words, think “And” here, not “But.” Also, knowing that there will be a second more focused diagram of the app allows this stage to be about inspiration and vision.

The second stage can then focus on exactly what will be built, what features are absolutely essential, and in what order features will be built into the application. At this stage the process can be about paring down the app using the principal of MVP to work towards exactly the app will do after initial development. Focusing on the minimum number of models needed to get the app up and running allows for a more thorough discussion about associations and the order in which models will be built, employing vertical slicing. Also by separating this stage from the first, the team can now focus on building a consensus about the stages of construction of the app and how tasks will be distributed to team members.

Hopefully, this reflection on planning will help me get off to a more effective start to building an app and that I’m less likely to get stuck even though I’m sure I will at some point.

Last week when discussing Rack in class, Steven mentioned the notion that with the advent of Rack and Rails, web development experienced something of a revolution and explosion in growth. My ears immediately perked up at this comment and I became intrigued with idea of a web revolution. In addition, as our course has shifted into more explicit work on the web, I really started to appreciate how all of what we have learned so far seamlessly integrates with the latest and much larger concepts we are beginning to tackle now.

My own perception of the history of the internet before this class consisted of 3 distinct stages, the first was my earliest memory of a screeching modem followed by the “You’ve got Mail!” announcement as I sifted through random emails from people who were also on AOL.

Next came the pets.com era as NASDAQ went above 5000 on its index only to crash even more quickly, decimating the web sector.

Finally the 21st century arrived and the internet stabilized, matured, and everybody focused on mobile devices or so I thought…

Now I know there is far more to the story. In December of 2005 David Heinemeier Hansson released Version 1 of Ruby On Rails as a web framework for Ruby. Perhaps as important, in August of 2006, Apple announced it was releasing Ruby on Rails as part of its next system release, Leopard. Of course this meant nothing to me at the time, but now I know better. What a monumental development this was! Ruby, a relatively new language along with a very new and comprehensive web framework was being put on every new Apple computer being sold starting in 2007.

On a timeline, this was occurring during a period of massive growth for Apple as iTunes was pushing its way on to computers of all kinds through the iPod, increased sales of laptops, and of course the iPhone was just around the corner.

This meant huge exposure for Ruby on Rails to a community of users many of whom already appreciated the idea of a unified, well designed, and codified approach to computing and tight integration of the internet. The similarities in rhetoric for Apple and Ruby on Rails are a bit spooky and cool all at the same time. They both just “work”, prioritize the experience of the user over the machine, and both celebrate the ideal of beauty through good design.

If there was ever a moment for a for a new innovative approach to the web this was it and Rails was the perfect unifying framework for the time. First, the underlying language of Ruby as we all know by now is a wonderful introduction to coding. The syntax and words of the language itself just beg to be used, but even after two weeks of intensive work at Flatiron, I still did not see what beyond this philosophy made the language specifically appealing for web development.

But then, we dove into databases and I learned how seamlessly SQL integrated into Object Oriented Programming in Ruby. I began to see the light. Next, as we shifted into ActiveRecord I started to see everything lock into place as it became clear to me there was specific codified pattern and structure in how Ruby objects interact with a database. Sinatra made that even more clear to me, but I still could not quite see how Sinatra and Rack could create the kind of “revolution” Steven mentioned. I was still curious and wanted to know more.

I discovered Ruby on Rails is the source of the revolution Steven discussed. Ruby on Rails has created a unified concise structure for back end web development that arguably never existed before its inception. In a sense, it has codified an approach to web development that consolidates several very good if not best practices in coding. First Ruby is unapologetically an Object Oriented Language that prioritizes flexibility and organization in code. Next, SQL is an excellent database language to use given its widespread adoption and integration with the web. In addition and maybe most important, Ruby on Rails utilizes the MVC structure that is easily adaptable and even includes templates. MVC is critical not only because it is a good design approach to many web, desktop, and mobile apps, but it is also widely used across many platforms, making it that much easier to adapt to Ruby if coming from another language or platform such as iOS or really any Objective C background.

In 2011, Rails integrated jQuery and Bootstrap which are also widely used in the front end community, giving front end developers a nice entry point into back end development. jQuery and Bootstrap are incredible tools to use especially after being exposed to making webpages without them.While many may criticize Bootstrap in particular, it can be fully customized and is far more appealing after one has tried to create a custom set of responsive columns without it. At this point, Ruby provides an entire framework that uses best practices, integrates a flexible and expandable backend database, and integrates a widely used customizable front end component as well. No wonder everybody seems to be building websites.

The closest frame of reference I can come up with for what Ruby on Rails is laying the foundation for is the discovery and adoption of standardized machine parts in the 19th century and the Industrial Revolution that followed. While Ruby on Rails is only a step toward a more unified set of tools to create, organize, and present data on the internet it is still a massive step in that direction and most definitely is a major part of the new revolution in web development and how we look at the integration of the web into all of the various computer devices we now use.

Tweet

As someone who is very new to coding and very right brained, I find myself often perplexed by the problems in front of me. During labs, wanting those green lights to turn on, I can’t help but wish on occasion there was some special method…a Flatiron Method…to make lights go green!

Imagine having one of these for those nasty pigeons that just won’t push into that darned array containing the hash with a value of yet one more hash key, value pair that finally leads to nested goodness for that darned…I mean precious little pigeon. If only there was some magical method that just turned those lights green. Well ladies and gentleman, for the ever so reasonable price of just $19.99, I present the Flatiron Method! Jobs would be jealous of this amazing innovation in code that I debut today.

Well, as we all know that just isn’t true. Sorry to get anyone’s hopes up, but alas there is no magic method, except that there actually is. The Flatiron Method does exist after all, we(I in particular) just have to use it. What is this method I speak of?

First, recognize that the Flatiron Method actually consists of many smaller more manageable methods that are all organized by task so as not to cram too much code into one single method. A well composed method must be organized, concise and only serve one purpose, executing its one instruction which in this case is delivering a green light. While I’m always ready to jump at the keyboard and just start coding my little heart away coming up with random variables, conditionals, and now Classes, is this really how one should approach a complex problem? Of course not.

The first method we will call in the Flatiron Method is the run_your_spec_in_bash method. This of course is a very simple method with a very helpful optional condition we will throw in called —fail-fast. After seeing the overall scope of your lab, reduce it to the first and only test spec you need to satisfy. Call this method inside of your method as many times as necessary and if it makes you feel more comfortable throw it inside a while loop.

The second method we will call inside of the FM is called the read_me_twice method which itself actually consists of two separate components, the first being the readme file which is called that for a reason hint hint and the second component is the spec.rb file which in particular often feels neglected and is just begging to be read to let you know when a ‘return’ or ‘puts’ is called for at the end of a given spec or a string output requires an exclamation point!

The third method we call is known as use_pry. Very simple, but oh so powerful. Inside of the pry method itself we see two components, the implicit return value, require ‘pry” which leads to more a more sophisticated gem, and the beloved jack of all trades, binding.pry. Use this little swiss army knife of a method to plug into code anywhere you like and as often as desired…it’s free! When this method gets called inside of the Flatiron_Method, it gives us a magnifying glass and a pause button to examine our code. Yes that’s right, it actually PAUSES THE PROGRAM in the middle of all those nested pigeons so you can keep track of your keys and values!

Think of the next method as more of a very useful comment in your code left by some long forgotten(except at the Flatiron School) Neckbeard who would sound like Gandalf if he spoke through the comments on the page. What is this old Neckbeard telling us to do? “READ THE DOCUMENTATION! BECOME FAMILIAR WITH THE CLASS METHODS! IN MY DAY WE DIDN’T HAVE THESE…WE WROTE THEM OURSELVES…IN LISP…WITH LOTS OF PARENTHESIS!!!”

Finally, the last method we shall call is a very special one as it actually connects to a very new and special form of JSON and AJAX. Through this simple little method called talk_to_teammates, we’ve actually devised a way to activate the human voice so that people can interact with one another(have no fear you can still use a phone, there’s a free app that works like Yo). Some hackers even, in what will be a never ending debate of proper method names, refer to this method as the collaborate_with_teammates method. Yes, I know that sounds a little too radical and there is no Yo-like app yet, but you may decide for yourself which you prefer. WARNING! Just know this method dabbles in the dark arts and lives in the deep recesses of 16 bit integer caves where only tiny little unix based organisms known as regular expressions survive without light or food, well except for the Ramen they are fed by still living Neckbeards.

My friends that about wraps up our discussion of the Flatiron Method. It will be uploaded to GitHub for anyone to add onto or amend, but remember, please keep it simple, keep it concise, and above get it to work! Happy coding and stay tuned for posts of a more technical nature in the future weeks!

Hello World!