DEV Community: Charlie E. Paterson

A Rubyist's guide to Javascript

Charlie E. Paterson — Mon, 17 Feb 2020 15:04:48 +0000

To start this post of, I feel it fitting to put one popular misconception to rest: Javascript is not, in fact, related to Java. Mine, at least, is beginning to seem like a distant cousin of working script (and sometimes, of the kind that does things!) I've come to learn a couple of things about the language along the way, and similarities/differences to Ruby.

Semi-colons, semi-colons everywhere!

At the end of most lines of code that are run, the developer needs to put a semi-colon unlike in Ruby. Exceptions can be made, however, when defining a function (what a rubyist would call a method) or even some simpler logic.

This is less extreme and consistent than languages such as C++ which outright ignore whitespace and only move to the next line after a semi-colon, but it appears to nonetheless be possible to use a semi-colon in place of a linebreak (as evidenced by some rather unsightly source files... looking at you, JQuery!).

..Don't forget empty brackets!

If I've learnt anything from struggling with some particularly nerve-wracking bugs, it's that you need parentheses in front of any method call more complex than to return a stored value. Your method doesn't take arguments? Empty parentheses it is!

C'est ne pas 'puts'

Firstly, as a Rubyist you may be familiar both with puts (or sometimes print) for outputting text and with p for displaying the value of a variable during specs.
When first learning of console.log in javascript, many will see parallels to the former but it is in fact in between the two.

The actual 'puts' of JS

If you really, really want to say something to the user, you want to use either document.GetElementById(element_id).innerHTML = desiredText, (swap out for GetElementsByClassName or GetElementsByTagName as desired) to manipulate the content inside a HTML element.
Because you see, reader, Javascript is a front end language intended to manipulate HTML (and sometimes CSS).

Function? Class? Was this ever meant to be?

While the most recent standard for Javascript (ES6) does have a class syntax of sorts (and has long had a syntax for 'prototypes' of functions), the distinction between classes and methods which exists for many backend languages doesn't translate as cleanly on to JavaScript for the most part as a matter of design. Functions are added to a 'class' by means of className.prototype.functionName = function(){ code here }, and instances of said class defined by var instanceName = new className.

Javascript, ultimately, is a front end tool intended to manipulate HTML and CSS on the fly.
Few could have anticipated the complexity of logic which it has evolved to be able to take on - especially of the kind that traditionally would be relegated to back end logic - but methods exist to create essentially the entirety of a web application's logic in Javascript.

It is for this reason I think it is felicitous to touch on two main approaches that can be taken:

Front end single page web app:

Usually the fact that pure JS can only really perform actions within the scope of the rendered page can come across as quite daunting; how on earth do you carry data entered or produced within one part of your app across the app as a whole? But what if we don't move between pages at all, and do all our logic manipulations right there and then? Well then, reader, this curse can be made into a blessing.

The great thing about not moving between different pages in a web app is that you don't have to go to all the trouble of constantly sending out requests to the server.
This can be a lifesaver for an app's users (in figurative terms, but sometimes literal depending on what your app does) if it just so happens that their internet is pretty terrible or their provider charges a lot for that precious extra traffic.

Using Node.js:

While Node.js is a technology I must still delve further into and learn, its main appeal is that it allows both the frontend and the backend logic to be unified under a single language. From the outset, this makes it far easier to take calculations made by interactive elements on the frontend and update records held on the server-side accordingly, and in turn carry these between pages.

In conclusion

JavaScript is a surprisingly versatile - and at times confusing - language which has grown from a controlling medium for dynamic frontend elements to hosting capabilities on the level of a backend language.

It is by understanding its history and the way its scope has grown profoundly from its original intended purpose that we can understand the quirks and conventions that distinguish it from other languages. There are many more I could list, but I wanted to cover what was most striking to me about JS coming from a Ruby background.

On the front-end frontier: my venture into web-apps

Charlie E. Paterson — Mon, 02 Dec 2019 12:38:11 +0000

Having a grasp on ruby is fantastic and such, but this raises the question of what next to do with one's impressive smorgasbord of classes, communicating the way they should with the right methods and having braved every possible edge case.

That is to ask, how do we now make something that begins to actually look a little bit like a website or, better still, a web app?

...To be honest, I'm still not entirely sure myself, but there are a couple basics and tricks to building web apps in Ruby which I wish to cover.

Sinatra

Sinatra is a ruby gem which serves as a framework for implementing ruby code as the backend language - that is, the language through which objects, the data they hold and relationships between pages are controlled. When elements coded in HTML call for either a GET or a POST request (links typically are confined to GET), it's typically in this backend code that any page redirections or manipulations of form or other data are written.

One of my personal favourite things to do here - which I took some time to warm to - is the Post/Redirect/Get pattern, wherein a post request assigns input to variables, then redirects to a page with a get request.

For example, let us say we wanted to take a name and email address and submit them to a list page, but didn't want to risk submitting the data anew every time we refreshed the target page? In the case of, say, a shopping app where such could lead to duplicate payments?

One could have a form submission for a name and email address activate a post '/submit' do end block which takes the text input into the form and stores the contents of each parameter in variables.
If one chooses to enable :sessions within their core web app file, these variables can be values tied to keys within the session hash created by sessions.

Now, the post block can redirect to another page address with the redirect method (in this hypothetical, redirect '/list'), tied to a get '/database' do end block that takes those session key-value pairs and does whatever it is we want to do. This particular feature I'm not quite yet sure how I would build, but there is a more pressing question that must be answered first. Namely, how do we take data from the backend into the front end?

Interpolation of ruby code

Within a GET or POST block within the central controller, one can set instance variables, and then invoke these in the code for the associated .erb file (the file format we use for front end units).
Given a variable @instance_variable in a GET/POST block, followed by erb(:page), one can then print the value of the variable into page.erb using the syntax .
One can again make use of the session hash by enabling sessions if one wishes to make these variable values available across the entirety of the web app session.

Alternatively, one can make certain elements within a view in the web app subject to certain conditions determined through the backend.
The way to implement if statements on the front end is to open them with <% if condition %>, enter the elements which you only want to execute on the page if the condition is true, and close with <% end %>. You can also add elsif and else clauses with <% elsif other_condition %> and
<% else %> respectively.

These are just some of the ways in which you can invoke ruby code directly on to the front end in order to regulate the presence or presentation of content.

Testing

It can be tedious at times to continuously have to close own and restart your web app in order to fully test out its functionality. You can use software such as Shotgun to make this easier for you, although I personally have had errors with Shotgun as while I can launch my web app successfully from the command line with it I find that it raises Sinatra doesn't know this ditty. It is, nonetheless, a useful piece of software for ease of interaction with and fine-tuning of your web app. Rackup is also recommended.

Ultimately, the most important thing to do is write adequate spec tests for your code. Thankfully, there is a testing framework known as Capybara that can work with Rspec and other backend ruby TDD frameworks.

A full cheatsheet and documentation for working with Capybara can be found at https://devhints.io/capybara and contains tests for the presence of links, buttons and content amongst others.
The practice I am familiar with for front end feature testing of .erb files is that one creates a separate /features directory within their spec directory.
Here one should endeavour to have a separate spec file for each view that they create and ensure to be thorough in test coverage. This way one can minimise the number of times they need to reload the page if they cannot find software that can successfully do this for them (I can only speak from personal experience).

If one wants to test out tweaks to elements or CSS styling on the fly, google chrome does offer the tools for this. Simply select the button in the top right with three dots vertically stacked, scroll down to 'more tools' on the menu that presents itself, and click on 'developer tools'. This can also be a useful accomplice to your core web development learning resources as it allows you to peak into some of the source code and allow you to inspect specific elements to better understand how they were built.

These are just a few tips which I have managed to take on in my current and very basic understanding of building web apps with ruby.

Getting into programming with classes

Charlie E. Paterson — Sun, 17 Nov 2019 23:53:07 +0000

There's a certain threshold that one must eventually cross when getting to grips with any language (although I currently can only speak from a basic grasp on ruby). You might be thinking, iterating over hashes perhaps? Or is this wrapping our heads around control flow and how to get data to travel properly between methods? Or perhaps even committing to memory - and coming to grips with the workings behind - methods with hashes?

Well, no, not quite. But hashes, arrays, strings and so forth respond to the methods that they do so because these methods are part of their class.
The array class has it's own methods, the string class has it's own methods...and can even have a range of array methods called upon it, but that's beside the point (even if all too useful!).
For you see, reader, one can make their very own classes, as follows:

class SomeClass
def initialize(argument, other_argument)
@argument = argument
@other_argument = other_argument
end
end

One might be lead to think there's little much else to making their very own methods but this, too, has some exciting quirks that it's important to get a handle on if one wishes to properly harness the potential of custom classes!

As you may have noticed, my example contains an initialize method - this is standard practice if one wishes to individualise the data held by instances (objects) belonging to the class (such as name, age, temperature, you name it!), and will run whenever you do
"some_object = SomeClass.new"!

The '@' symbol I've placed before the variable names in the body means that their assignment in the method will apply across the entire instance, rather than just that one method (remember that the only data methods will usually provide outside of themselves is that which is 'return'ed).

Of course we could set about coding methods to return each of these instance attributes we have set, but a much quicker way to be able to return them is as follows:

class OtherClass
attr_reader :argument, :other_argument
(initialize variable and so on)
end

With attr_reader, you're all set to return the value of any of the chosen instance attributes without having to code methods to return each and every one of them. However, if you want to be able to change these values you need attr_writer, and to do both you'll need attr_accessor.

From here you can write methods to make your classes do all kinds of things: maybe one of these instance variables is an array, and you want a method to push instances of some other class into it? Or maybe you want said instance to have a method to push itself when called upon it? Maybe a class called 'Villain' or 'Student' could hold a whole slew of information in the form of class attributes, allowing a whole different approach to the student directory project of yesterweek?

While I do have to admit that custom classes do still feel ever-so-slightly ominous in their novelty, I'm looking forward to really playing with the full roster of their capabilities in my journey through the world of code.

Getting ready to code for real: Thoughts and things to do

Charlie E. Paterson — Wed, 06 Nov 2019 16:56:39 +0000

My learning and challenges so far

Over the last couple weeks I've learnt a thing or two not only about the core workings and features of ruby as a language, but also about how to manage all my files and the git repositories I keep them in through the command line.

While at first I was getting lost in the march of 'no such file or directory' messages, I have now come to a basic understanding of navigating files on the command line. I have even completed a fun 'murder mystery' challenge which really emphasised the use of grep and related commands to extract and store relevant information to solve the mystery.
One can imagine how hard it must be to search a file for a crime scene report buried within the full text of 'Alice in Wonderland' without some command line sorcery!
While I still have many more tips and tricks to pick up in order to really make full use of the command line, these should come in time.

I've also tried my hand at doing a range of interesting and challenging things with code itself, namely ruby. The most unusual of these so far was to take an array containing various strings representing 'levels' of a river and create a game wherein the user (represented by 'P') navigates down the river and must avoid bumping into ravenous crocodiles (represented by 'C's). At this point I have some basic understanding of all the main structures (arrays, hashes, loops) but still have yet to really make full use of classes, lambdas or procs.

A couple things so far that have really stuck out or been useful to me about ruby as a language are:

Many methods reserved for arrays can also be used on strings, treating them as 'arrays' of characters.
There are all manner of interesting alternative syntaxes, such as the format 'condition ? "outcome_a" : "outcome_b"' for an if-else statement or the use of 'array << element' instead of 'array.push(element)'. However, they are only more elegant in some contexts!
The language feels a lot more elegant and approachable than Java. The latter I hope to get used to in time.

I've also noticed a couple things I still need to get used to:

Making sure I don't use '=' where I should be using '==', and proofreading in general
Getting some more built-in methods under my belt! There are many with a number of valuable uses, but I don't know many off by heart so my capabilities are still limited.
Ensuring proper flow of control with many methods. The penultimate exercise of weeks 2-3 of my precourse, programming a game of blackjack, challenged me a lot for this reason.
I found it difficult to ensure that methods were communicating with each other properly in terms of transferability of variables and return of information from variables.

My current project

More recently as part of my pre-course, the time has come for me to try my hand at building something more elaborate: a directory of student names! So far, I have implemented and played with a couple of features.

A very basic way to do this with only rudimentary coding knowledge would be to 'puts' each and every name as a string on a new line, and then 'puts' a string declaring the number of students.

The intuitive and first model for such a program is instead to store the names all in an array as I did, and iterate 'puts' over each of these when we run the program.

But we can also, in turn, make the student count statement dynamic and able to stay accurate to the actual student count automatically.
This I did by calling '.length' on the student array within the string via interpolation, which resembles this:

'puts "We currently have #{array.length} students total"'

I went even further and created three seperate methods for printing a header, the list of students, and a footer stating the number of students respectively.

But what if, in turn, we wanted to include some extra information? Say I wanted to store not just a name, but a cohort month? For this, a possible solution is to store hashes in our array.

Hashes differ from arrays in that you typically call the 'values' not by numerical index, but by keys. These can be integers, strings, symbols and other objects.
Multiple different keys in an array can be assigned to the same value, but in this particular case I made use of the fact that the same key can be used to return a different value per array (two different values on the same key doesn't make as much sense within a hash).

A 'name' key can be used on each hash representing each student to return their names, and a 'month' key to return their cohort.

From this we can fill our array with a hash per student, instead of strings of their names, and plug the same keys into each such hash to return the value that each hash uniquely assigns to said key, as follows:

"array.each {|student| puts "#{student[name]},#{student[month]}"

I never thought I'd see the day when I built an array of hashes, over which I would subsequently iterate with a side-serving of string interpolation, but here we are. And we're not done yet!

A set of features I'm looking to implement as part of my learning exercises over the rest of the week are:

Getting user input: perhaps to add or remove students, or even change their month cohort if there's been a mix up!
Even more information per student
Centred text if possible
An interactive menu allowing users to navigate and call the different methods of the program at will
Saving output from the program into files
And more!

How exactly I am going to do all of this is something I am excited to find out along my journey through the world of code!

~ Charlie Paterson