This is the second, and final, post in the series about starting off on a Rails application. In the first post the basis for a “Planets” application was created. I ended up with a database (model) and a functioning mechanism around that database that let me create, edit, and delete records (views). All of that was knitted together into a working application by a controller. However, those views have no validation on them. That means the database is not protected from bad data. I’ll fix that here and then focus a lot on how Rails apps are tested.
Category: Development
Starting a Rails App, Part 1
Many testers these days will find themselves in Rails shops and, even if that’s not the case, Rails is a good environment within which to build custom test solutions that require a database and a web interface. This is largely because when using Rails, you are using one of the most concise and expressive languages out there: Ruby. I plan to document some of my learning of the Rails ecosystem in two posts.
Learning the Rails Way – A Tester’s Perspective
In a previous post I talked about learning Rails in a way that I wished it had been presented to me. Here I’ll focus a little on the salient facts about the framework that you will no doubt find elsewhere, but sometimes you have to distill it from surrounding material that gets in the way. Near the end, I’ll explain why any of this has relevance to me writing as a tester.
Continue reading Learning the Rails Way – A Tester’s Perspective
A Tester Learns Rails
I played around with Node.js in a previous post for web framework design. Now I want to explore Rails a bit. I haven’t found tutorials that I really like on Rails, at least for those getting started. Now that I have gotten started, some of those tutorials I did find are more helpful to me, but they weren’t as helpful starting out. So here I’ll write in a way that helped me learn more about how Rails is actually working, rather than just relying on the “magic” that everyone tells me is happening behind the scenes.
Building Simple Web Apps with Ruby, Part 6
In this post I’ll continue what I started in the previous post: using Sass. We’ll explore a different option around how to use this engine. Also, while I’ve focused on changing the CSS and HTML elements of our application, I’ve done very little with the JavaScript portion. So here we’ll explore that a little bit as well.
Building Simple Web Apps with Ruby, Part 5
In this post I want to switch around some of what we already did regarding HTML and CSS, by using “variants” of these. Specifically, I’ll look at Slim (to replace our HTML/ERB) and Sass (to replace our CSS).
Building Simple Web Apps with Ruby, Part 4
Following on from the other posts in this series, here I want to focus more on the static and dynamic content aspects. This will actually be fairly tame stuff for the most part but it’s a way to make sure we can do some of the basics with Sinatra — just in time to change them all around a bit.
Building Simple Web Apps with Ruby, Part 3
Here I want to focus more on the particulars of constructing a Sinatra web application. Up to now you basically have something that can serve up static or dynamic web pages. It’s time to get an application structure in place. This in turn will let us deploy our web application.
Building Simple Web Apps with Ruby, Part 2
This post continues on from the first one. That first post was a setup to getting the tools you needed. Here we’re going to put Sinatra through its paces and make sure we understand how it works so we can get on to creating an application.
Building Simple Web Apps with Ruby, Part 1
As a tester I’m often in a position where I want to write web applications for a variety of purposes. Most recently I wanted to make a simple test application that could be used to prove out my Symbiont test framework. Then I realized I wanted to deploy this application so that it would be available for a variety of purposes. I started looking into the simplest solutions I could find. This series of posts will cover what I learned.
Build Your Own Language, Part 6
Here I’m going to try my hand at creating the start of an interpreter. This obviously follows on from the previous posts in this series.
Build Your Own Language, Part 5
If you’ve followed this series up to this point, you now have a lexing and parsing engine that, while not doing much, is passing its tests. What we don’t have is a way to really say that our language works because there’s no runtime. That’s what I’ll start to address in this post.
Build Your Own Language, Part 4
We left off with a parser test we wanted to execute (in parser_spec.rb) and a grammar file to generate a parser (in grammar.y). The actions specified in the grammar file, and thus what will be tested in the spec file, are nodes. So getting those nodes in place will be the focus of this post.
Build Your Own Language, Part 3
Following on from the second post in this series, a lexer has now been created that can tokenize some input for a hypothetical language. Given what was accomplished, theoretically I can use my language to create the most minimal sort of class definition. I’d really love to know if I’m completely on the wrong track here. So I’d like to get started on the parser at this point rather than fleshing out the language more.
Build Your Own Language, Part 2
Following on from the first post in this series, I did a development spike that proved to myself I had some clue as to what I was doing. So now I want to get into actually building a language from soup to nuts: meaning I want an interpreted language that executes via a runtime. Granted, this will be a very simple language (and not very unique). It will also be a very simple runtime. Let’s see what happens, shall we?
Build Your Own Language, Part 1
In previous posts I talked about how one of my goals was to come up with an alternative to Gherkin. This is not in the “just to see if I can” category but rather because I believe it could be useful to roll your own Gherkin-like language. This post, however, will be in the “just to see if I can” category. Here I want to take what I learned about lexing and parsing and apply that to creating a simple programming language. Fair warning: I have no idea how this is going to turn out.
A Tester Learns Rex and Racc, Part 3
This post continues on directly from the second post in this series. Assuming you’ve been following along, you’ve broken your input into a stream of tokens. Now you need some way to recognize higher-level patterns. This is where Racc comes in: Racc lets you describe what you want to do with those tokens. That’s what I’ll be covering here: how the parser works with the lexer.
A Tester Learns Rex and Racc, Part 2
In my previous post on this subject I started off on the learning process for building a lexer with the Rex (Rexical) tool. Here I want to update the logic I provided in that post to show how to make it more testable. I then want to expand on the example of using Rex with something a bit more substantive.
A Tester Learns Rex and Racc, Part 1
As a tester, I like to know how things work. So when I started investigating the basis for the tool Cucumber, I came across the concept of Gherkin. That was written with the help of a system call Ragel. What I was curious about was whether I could build one of these languages on my own, perhaps for a customized testing tool. This caused me to stumble upon Rex and Racc, which are two Ruby-based tools that help you build your own languages. The documentation on these tools, however, is on the bad side of awful. This post is purely to document and share what I learned.