Creating dynamic attribute accessors

Paweł Bartulewicz — Fri, 26 Apr 2019 14:30:49 +0000

Metaprogramming, the art of messing with the internals of a programming language, is one of the most powerful learning tools an aspiring programmer can utilize. It's very easy to take the workings of the given language as they are for granted, but there's hardly any room for improvement in doing so. Quite the contrary, being oblivious to how the things work behind the scenes may make you unable to grasp many of the concepts that you may use in the project on daily baisis. Unfortunately for metaprogramming, as the most the projects don't really delve into this arcane realm, the opportunity to put it into use may not come for a long time, if ever.

This is not good. Let's warp the reality and create our own opportunities. What else could you possibly do in your free time anyway? Play video games? What a nerd.

For the higher purpose of expanding our knowledge, we must forget (just a little) about practical usage of the fore coming examples. For now, only our goal matters and the means of how we achieve it. Let's say, that for some weird, possibly sexual reason you'd want to create an initializer for your class, that would take any number of hashed arguments and create corresponding accessors for each of them. Why would you want to do that? I don't know nor care, but we sure as hell are going to do that.

So we want this:

to be as viable as this:

And to be able to access values of these variables like this:

And set them like this:

So, to unpack it all: we need to make our initialize method accept a hash of arguments, iterate through them, set them as instance variables and create an accessor for each of them. Let's try this:

Looks good. Double splat operator (**) is an indicator of arguments being processed as a hash. 'Instance variable set' is our go-to way of...you know, it's pretty self-explanatory, so I'll just let you figure that out yourself. The last line is the call to our class' private method with an arguments being names of the variables that we previously set as the instance variables and which we want to be able to access or set. OK let's find out what the fallout is:

Ok, seems to be working well...if you are willing to disregard this:

You see, our 'send' method have been acting directly on our class, so the accessors we set like this aren't going nowhere and are freely available to all future instances of this class. This is a mess and we can't have that. Accessors we set should be constricted only to the arguments which we initialize our class instances with and available only for given instance. So what we really need to do, is to kinda cheat our way into the accessor-like behaviour by creating per-instance methods which simply return out previously set instance variables or set new values for them. Here comes the question: did you know that singleton methods can be created for instances as well? I know what you'll think: it's almost ultra rare in the environment of run-of-the-mill projects. Most certainly, but why bother with boring reality, when we can create our own occurrences? Let's do this right now:

This time we completely make do without 'attr_accessor' business. Instead, iterating through our arguments we create two singleton methods per argument - one of them simply named as your variable name which simply call the inverse of previously used 'instance_variable_set' - 'instance_variable_get' to get its' value, second - with equal sign following the variable name (and also acccepting additional argument) for setting new value to our variables. Let's find out where the whole affair has gotten us:

Voila. No access to the first instance's variable from the second one, getters and setters working as intended. Now, as far as metaprogramming goes, this is a pretty basic and primitive example, but it's only meant to show that generally, programming languages hold many neat tricks, that can enable you to bend the rules of the game to your will.

How to use AJAX events for parallel requests

Paweł Bartulewicz — Fri, 19 Apr 2019 13:05:10 +0000

AJAX (Asynchronous JavaScript and XML), which gained serious traction in mid-2000s, is a set of techniques consisting of sending asynchronous (hence “A”) requests between the browser and the application server, containing XML objects (hence “X”) with the use of JavaScript (hence “J”) and allowing dynamic content changes without the need of reloading the whole page. At the very heart of the AJAX’s API object lies a powerful XMLHttpRequest that gives us the power to retrieve the data (any data, not just XML obviously) from the server and then process it client-side. After the advent of many JavaScript abstractions, biggest of them all being of course jQuery, utilisation of AJAX required less and less effort making this technique still relevant as of today. And this is why we’ll talk about the AJAX in the conjuction with jQuery events, or to be more precise - how to make parallel AJAX requests using ‘beforeSend’ and ‘complete’ events.

Our application relies heavily on external API calls that allow collecting data which is then saved to the users table in our database. This synchronization takes place at several points in app’s “runtime”, one of which occurs during login process. Let us examine the simple AJAX login method.

(A little disclaimer - in our code we are using ‘js-routes’ gem, which allows us to use helper-like paths in our js files)

It’s pretty straightforward - we prevent the submit action, serialize form data, then send the request to our controller which then checks credentials and whatnot, ultimately resulting in JSON containing our error message or, in the case of success, the call to the function responsible for data collection from external APIs and redirection to the home page. This function will consist of two AJAX calls hitting controllers responsible for HTTP calls to respective APIs (let’s call them api1 and api2). Single request would look like this:

On its own it would be as simple as that, but we have the other controller to hit. We could do something like this:

The problem with this solution is that the second function has to wait for the previous request to resolve and the strength of AJAX’s asynchronicity is lost. What we need is to make these requests parallelly and redirect only after both are resolved. This is where ‘beforeSend’ and ‘complete’ events come in handy. First one occurs before the request is sent, second one after it is fully resolved, whether it was successful or not. In this case, we technically could forego the ‘success’ event completely cause we want our user to be redirected to home page regardless of our functions results, since we cannot lock them out of the page because of the external API’s downtime. One thing that needs to be resolved is they way we determine when to redirect, or to put it differently - are all of the functions resolved or not. To do this we’re gonna create a counter flag and update it in aforementioned ‘beforeSend’ and ‘complete’ events. So let’s start building our getData function.

First we set our counter to 0, obviously, then proceed with the “first” (it’s not exactly first, since they will proceed parallelly).

Now for our events. What we want to do, is to increment a function_counter as the request starts to indicate that there is one ongoing.

Then, as it completes (again - regardless of it’s success), we decrement the counter, check if all of the requests are resolved (the function_counter equals 0), and if so - redirect user to home page.

And voila. Let’s add the second request now.

We could clear that up by moving the urls to the array and then iterating through it to remove repetition, but I will leave that to you. What we can do, though, is to add error events to gather potential errors. We will start with the empty array at the beginning of the function and then push error messages to it in each of the requests ‘error’ event. Then you can pass these messages to redirect function and then as a params to our path, so you can use them to set flash messages for after the user is successfully logged in. Our function should look like this now:

And just like that, our two requests are processed at the same time utilizing the full potential of AJAX.

Forem: Paweł Bartulewicz

Creating dynamic attribute accessors

How to use AJAX events for parallel requests