Coding

Browsing category
tumblr_mmv9s7sbqf1qh7n7no1_1280

How to plan your next rails app

For me, there’s no such thing as too much planning. When I travel, I pack 3 or 4 days early, to make sure I don’t forget anything. It’s a little extreme, I know, but hey, I haven’t forgotten anything super important in 15 years of traveling on my own!

I’m writing this blog post because while I’ve seen some good answers to this question around the internet, they’re all scattered around in random places, hidden in stack overflows and under various neglected corners. This is an attempt to consolidate all the information I’ve found and stick it in one place.

When I’m building something as potentially intricate as a rails app, I sure as heck want to know beforehand EVERYTHING I’m about to do.

So it comes as no surprise that I have a keen interest in what the ‘best’ way is to plan out your app. And yes, I’m aware of the ‘draw out the path of your app’ way and the different visualizing applications out there designed to help you solidify your plans, but I wanted to know if I could go further with it. Is there a truly foolproof process? One that is repeatable as well as documentable?

Here’s what I found:

Primary Questions

There seem to be three big questions (hereafter referred to as ‘the big three’) people ask when discussing app design, and these are: Do I plan out the Front-end/User Interface or the backend/models first? When should I start testing? And how do I make my app as efficient as possible?

UI or Backend first?

Of course, this falls to preference, however there seems to be a common thread: Anecdotally, those who started with the backend and left the front end for later found that they had to do significant refactoring later on, mainly because it turned out that the way users were going to interact with their app didn’t fit into the rigid constraints of their models and associations. User interaction, like human beings themselves, are not so easily encapsulated. This is one reason why they’re fun to design for (as opposed to cats. Have you ever designed an app for cats? Oh my GAWD) but its also why this aspect of app building is so difficult. Users will find ways to interact with your app that you never even dreamt of- this is good and right, in my opinion, as long as it’s safe and respectful (and legal), but it does make design tricky.

Here are two great threads, one from reddit and one from stack overflow, for further reading:

REDDIT

STACK OVERFLOW

When should I start testing?

In short, as soon as possible. Developers who said that their teams used a ‘build tests later’ approach sincerely regretted it because going back to write tests for code you may have written days or weeks ago is difficult. It’s easiest to write tests as you write the code the tests are for, according to several of the articles I read.

Like this ARTICLE

How do I make this thing as efficient as possible?

In order to answer this question, you should ask yourself two others: What will my app do? And perhaps more importantly: what will it NOT do? It is incredibly important to not overreach in the design phase of your app. Yes, go ahead and dream big, make your app the best thing ever, but then plan it and pare it down, then pare it down again. Kill your darlings, break it down to its absolute essentials. Make it so that your app does one thing great, not two or three things in a confusing, poorly designed way.

I have to come clean, I saved the best for last. Here’s a great guide to help you design your next app: THOUGHBOT’s GUIDE

This is thoughtbot’s playbook on how they make stuff, from the first post-it sketch to when the first user interacts with the finished product. There doesn’t seem to be anything else quite like it out there on the internet. It is incredibly thorough, informative and inspirational, and I suggest you take the time to read through every part of it.

Thanks for taking the time to read through this article, hopefully it gave you a decent idea of where to start when designing your next big project. As always, I’ll update this article if I come across any new and exciting info.

Processed with VSCO with lv03 preset

Know Your Options: Alternatives for Live Data in Rails

Or: Alternatives to web sockets/action cable (in case, you know, you’re a masochist)


For the uninitiated, web sockets allow for a continuous connection with data- our gmail account’s fancy ability to fancily deliver emails in fancy real time is one example of this, as would be a stock ticker that updates in real time (real time meaning milliseconds). Action cable is rail’s fancy new way of integrating web sockets, and while everyone is terribly excited about action cable’s potential and web socket’s capabilities I figured I’d give a little bit of back ground as to why web sockets are considered to be so neat.


Back before web sockets, there were three popular ways to open a continuous data connection-


1 Polling- Polling involves the client asking the server, on a set interval (say, three seconds) if there is any new data.Returning to the “live comments” example, let’s say we have a page with a comments section. To create this application with polling, we can write some Javascript to ask the server every three seconds for the latest comment data in JSON format. If there is new data, we can update the comment section.


The advantage of polling is that it’s rock-solid and extremely simple to set up. For these reasons, it’s in wide use all over the Web. It’s also very resistant to network outage and latency – if you miss 1 or 2 polls because the network went out, for example, no problem! You just keep polling until eventually it works again. Also, thanks to the stateless nature of HTTP, IP address changes (say, a mobile client with data roaming) won’t break the application.

However, regarding scalability… You’re adding considerable load to your servers by causing everyclient to hit your server every 3 seconds. There are ways to alleviate this – HTTP caching is a very good one – but the fact remains, your server will have to return a response to every client every 3 seconds, no matter what.


Also, while polling is acceptable for “live” applications (most people won’t notice a 3-second delay in your chat app or comments thread), it isn’t appropriate for rapid back-and-forth (like games) or streaming data.


2 Long-Polling – Long-polling is a bit like polling, but without a set interval between requests (or “polls”). The client sends a request to the server for new data – if the server has new data, then it sends a response back like normal. If there isn’t any new data, though, it holds the request open, effectively creating a persistent connection, and then when it receives new data, completes the response.


Exactly how this is accomplished varies. There are several “sub-techniques” of long-polling you may have heard of, likeBOSH and Comet. Suffice it so say, long-polling techniques are considerably more complicated than polling, and can often involve weird hacks like hidden iframes.


Long-polling is great when data doesn’t change very often. Let’s say we connect to our live comments, and 45 seconds later a new comment is added. Instead of 15 polls to the server over 45 seconds from a single client, a server would open only 1 persistent connection.


However, it quickly falls apart if data changes often. Instead of a live comments section, consider a stock ticker. A stock’s price can changes at the millisecond interval (or faster!) during a trading day. That means any time the client asks for new data, the server will return a response immediately. This can get out of hand quickly, because as soon as the client gets back a response it will make a new request. This could result in 5-10 requests per second per client. You would be wise to implement some limits in your client! Then again, as soon as you’ve done that, your application isn’t really RealTime™ anymore!


3 Server-sent Events are essentially a one-way connection from the server to the client. Clients can’t use SSEs to send data back to the server. Server-sent Events got turned into a browser API back in 2006, and is currently supported by every major browserexcept any version of Internet Explorer.

 


Using server-side events is really quite simple from the (Javascript) client’s side. You set up an EventSourceobject, define an onmessage callback describing what you’ll do when you get a new message from the server, and you’re off to the races.



Server-sent event support was added to Rails in 4.0, throughActionController::Live.


Serving a client with SSEs requires a persistent connection. This means a few things: using Server-sent events won’t work pretty much at all on Heroku, since they’ll terminate any connections after 30 seconds. Unicorn will do the same thing, and WEBrick won’t work at all. So you’re stuck using Puma or Thin, and you can’t be on Heroku. Oh, and no one using your site can use Internet Explorer. You can see why ActionController::Live hasn’t caught on. It’s too bad – the API is really simple and for most implementations (“live” comments, for example) SSE’s would work great.


(All descriptions from THIS fantastic article written by Nate Berkopec:https://www.nateberkopec.com/2015/09/30/action-cable.html)


So, how does this effect us? Well, I think it’s only a matter of time before all of us, in our new development jobs or in our awesome, shinny side projects, will want to at least take a shot at creating a real-time updating, persistent data connection enacting, super fantastic application, and when the time comes to create it, it’ll be nice to have a head start in knowing what your options are.


HAY_2537 (1)

Hello world, indeed

Howdy. I’ll start this off with a bit of advice I received from one of my great (and now deceased) all time heroes, Jonathan Waiter. Jonathan was a  fashion photographer, and he was one of the only fashion photographers who acknowledged my existence not only as a VALIS (voice activated light stand, as Joe McNally calls his assistants) but as a human being. I have no idea why he did this. Maybe he saw something in this scruffy mid twenty something, still holding onto his dreams with bloodied, boney fingers tips, the death grasp of someone too stubborn to quit and to stupid to do anything else. I’ll never know, sadly.


For what ever reason, he answered my email, and one cold winter’s day in Brooklyn there I was, helping out with a shoot. When we broke for lunch we grabbed sandwiches along with the rest of the crew. We got to talking, and we bonded over our apparent mutual romantic entanglements with europeans (he’d been married, briefly, to one, while I was in the throes of a long distance relationship). At one point I asked, as one often does when eating sandwiches with a bonified hero of one’s own, how he went about becoming a photographer and if he had any tips.

I sat, waiting with bated breath, expecting to hear a long, eloquent speech about working your way up the ladder, of doing good work no matter how humble that work was, of being nice, of the need to sweat it out over back breaking grunt work to get your shot. Here’s what he said: “I went on exactly one assisting job and I fucking hated it. I was also terrible at it. Then I just said ‘screw it’ and started sending out my portfolio to magazines and publishers and editors. If you want to be a fucking fashion photographer, just go be a fucking fashion photographer. Don’t wait, or ‘work your way up the ladder’, just do it. There’s no secret. ”


This, for a bright eyed, painfully innocent and naive sort like me, was shocking. I thought there was some sort of karmic system worked out. I thought there was this whole track laid out, tough but fair, of points that got connected until boom, all your hard work paid off and you were where you wanted to be, roughly. It never occurred to me, as I am now painfully aware of, that life isn’t that fair or orderly, that assistants work their asses off for much longer than I ever did and never even come close to getting their shot. It never occurred to me either that you could jump the line, or that there wasn’t really even a line.



But of course there isn’t. Lines, systems, maps- These are all our modest attempts as a species to apply logic to our larger issues, a way for us to pat ourselves on the back and tell ourselves that it’s all going to be ok, the universe is looking out for us because things make sense, and if they make sense than surely it will all work out for us, right?


Wrong. The universe doesn’t make sense. It is a cold, harsh, unfeeling thing that will crush you and your dreams without so much as a glint of recognition. This might sound harsh, I know, probably because it is, but it also means something else: FREEDOM. You have as much of a shot at getting what you want as everyone else does.

 

So, in conclusion, let me start this blog off with this: IF YOU WANT TO BE A PROGRAMMER, WORK YOUR ASS OFF, LEARN EVERYTHING YOU CAN AND JUST BE A PROGRAMMER.

Another one of my favorite quotes, this one from William Wordsworth:

To begin, begin.

connect

Categories