At work we already had a CI server configured and running, so I'll skip the basic Jenkins configuration stuff here. But the upshot is, it was configured for a fairly standard procedure:
We now want to add "run some Selenium test suites" somewhere in step 2, and "show me reports" somewhere in step 3. I'm going to assume that you can install the Selenium IDE Firefox plugin and author some simple tests, which is very easy: just open the plugin window, start recording, click around, and save the results somewhere. For getting-started purposes I made one test suite, consisting of two test cases: one to check that an unsuccessful login attempt keeps me on the same page and shows an error, and one to check that a successful login takes me to the page I expect. These are saved as "Selenese" HTML files for now. (How to write good test suites, and what specifically to test, seems like a topic in and of itself.)
First, a quick overview of the different bits of the Selenium project:
So, we know we need to author tests (IDE) and we know we need to run them against a browser (RC). For ease of setup and because I don't have more than one machine to play with at the moment, I'm not going to set up Grid for now (although it definitely seems like a good idea, to cut down on the time it takes to get feedback on a build).
Additionally, we need to decide what machine to run the RC server on. I had a couple of choices:
I chose the latter. Our CI server is actually an EC2 instance running Ubuntu, but Selenium needs an actual browser to do its stuff against and obviously we don't have (or want) that on a remote server. However, it's possible to run GUI apps headless in a virtual display. This was not difficult at all, thanks to these three posts. Summarizing those, first we need to install some packages:
sudo aptitude install xvfb # virtual display sudo aptitude install x11-apps # installs xclock (to test things are working), and xwd (for taking screenshots) sudo aptitude install imagemagick # for converting screenshots sudo aptitude install firefox
Then, we start the virtual display, launch the GUI app xclock (so we have something to look at), take a screenshot of it, and (since xwd uses its own image output format) convert that into a regular image file:
/usr/bin/Xvfb :5 -ac -screen 0 1024x768x8 & xclock -display :5.0 & xwd -root -display :5.0 -out outputfile convert outputfile outputfile.png
I scped that image back to my desktop, and voila, there's a clock. Now we can copy up our HTML test files, and the Selenium server file (part of the Selenium RC download), and on the server, try running our tests:
export DISPLAY=:5.0 # firefox needs this to know where to find a display to run on java -jar /path/to/selenium-server.jar -htmlSuite *firefox "http://www.example.com/" "/path/to/tests/suite.html" "/path/to/results/results.html" w3m results.html
Sweet! Note that you'll want to set up your server to somehow launch xvfb on startup, so the virtual display is always available. Ok, onwards.
If you noticed above, our previous Jenkins build steps only configured the bare minimum Python environment to run our Django tests: just installthe necessary packages, make sure PYTHONPATH is correct, etc. We now need a complete setup of our site, including a database with known data to test against, and a way to reach it in a browser. Documenting this in a generic way is obviously not possible, since it's very project-specific. But Jenkins build steps are nice in that they're just shell commands, so just do whatever you need to do. I had to do stuff like set up a test domain name, configure Apache to point to the directory with the project code, dump in some known data into a test DB, copy a settings file to the right place, compile our JavaScript code into a production file, etc. And if you haven't already, be sure to add your Selenium test files to your code repository, since obviously we don't want to have to copy them up manually like we did above. You could potentially wrap all that up in a shell script, or, I guess people are using Ant or Maven for this kind of thing as well. Make sure you can visit your site and it looks normal before proceeding.
Also, be sure to first run your tests manually from the server (adjust the above command for any new paths) against the test site before attempting to get Jenkins to do it. Doing this I discovered that I needed to make a custom Firefox profile; since our site is using an SSL certificate and our test app is not using the correct one, my sample tests begain failing because the Firefox that Selenium launches was presenting the security warning page first (where locally I had confirmed an exception). This is easy to resolve, but yet another step. On the Mac, launch /Applications/Firefox.app/Contents/MacOS/firefox-bin -ProfileManager -no-remote, choose to create a new profile and name it Selenium-something, and then navigate to the test app. Get the warning, confirm and save the exception (or install the certificate), then quit Firefox. Then find that profile you just created, and copy it up to the server. Then you can launch your tests from the server like:
java -jar /path/to/selenium-server.jar -htmlSuite *firefox "http://www.example.com/" "/path/to/tests/suite.html" "/path/to/results/results.html" -firefoxProfileTemplate "/path/to/profile/foo.Selenium"
Now when you view your results.html, they should be all nice and green!
So now that the test site is available and Selenium is happy running tests, we can (finally) get to having Jenkins do all this for us. This simply involves adding another build step to kick off running the test suite and getting the results. We'll need the Selenium HTML report plugin (note there is also the Seleniumhq plugin, but I couldn't get that to work). From within Jenkins, go to Manage Jenkins > Manage Plugins, click the Available tab, find and select it, click Install, and restart Jenkins.
Now, add the additional shell build step to your project and simply enter the same command that launched your tests above (don't forget to set the DISPLAY env var as well). Finally, under "Post-build Actions" check off "Publish Selenium Html Report" and point it to the directory of where your results are -- that is, if the command is outputting to /path/to/results/results.html, you enter /path/to/results, since it can parse more than one HTML file of results (meaning you can add as many build steps to run other test suites as you want, as long as they output to the same place). You should get details in the Console Output for a job (for debugging) and can see the results by clicking "Selenium Html Report" in the left column.
That's it for now, and I hope it works for you -- happy testing!
]]>xorg.conf, so I switched back. And now here we are again. This latest round I think has to do with my feelings about Apple as a company and where it's headed, but I don't think it really matters at this point.
However, I would like to document this round; that way I'll have something to refer back to, not only so I can say "What happened the last time I did this? Oh yeah" but also so I'll have something to gauge progress with. Perhaps by next time these issues will be resolved, and we can settle the matter.
Anyway, I recently nabbed a Thinkpad at work, installed Ubuntu 10.10 on it, and spent a week or so with it as my primary machine. The time was right for this experiment:
OK, first the positive:
And, stuff that is still irksome:
"+p. That is, I had to maintain context-aware copying and pasting, which was severely annoying.My overall impression was that Ubuntu is now in a kind of OS uncanny valley. The community has made some amazing achievements since I last was a regular user, and they deserve much admiration and appreciation. Unfortunately, that's not how it works. Like in the security industry, if you do your job really well, nobody notices and nothing happens. And that also means that any tiny missteps are magnified and come immediately to the forefront, where the experience is very jarring. So we're out of the era when using Linux meant "you're going to have to invest time learning this". Now the expectation is that users can jump right in -- which is simultaneously a major accomplishment and a major hurdle to overcome.
So, I'm typing this back on my Macbook. If I were solely a backend developer, I would probably officially make the switch. However, I'm not, and while I occasionally have multi-hat abilities -- indeed this is likely the source of my perennial switching investigation, ultimately I'm a frontend at heart, and there's something that still feels appropriate about the Mac, so here I am. Maybe next time, though.
]]>curl. This is basically just my quick notes, the short version of the HTTP API docs, which are obviously more thorough.
Installation is easy: sudo aptitude install couchdb (or brew install couchdb). You can verify that worked by visiting Futon, the web-based interface that ships with Couch, at http://localhost:5984/_utils. But of course we want to use curl here, so:
curl http://localhost:5984/
==> {"couchdb":"Welcome","version":"1.0.1"}
Create a database:
curl -X PUT http://localhost:5984/testdb
==> {"ok": true}
curl -X PUT http://localhost:5984/testdb
==> {"error":"file_exists","reason":"The database could not be created, the file already exists."}
Add a document with a POST request. Couchdb will automatically create a UUID for you:
curl -X POST http://localhost:5984/testdb -d '{"name": "Dieter"}' -H "Content-Type: application/json"
==> {"ok":true,"id":"4f761d4dc3b4d602ffdc2be02600140b","rev":"1-40b62334f3dc02ca64532fbec03f3a35"}
Or, to do a PUT request, you need to provide a UUID yourself (ie, make one in your application):
curl -X PUT http://localhost:5984/testdb/youruuid -d '{"name": "Joe"}' -H "Content-Type: application/json"
Either way, use that UUID to read the document:
curl -X GET http://localhost:5984/testdb/4f761d4dc3b4d602ffdc2be02600140b
==> {"_id":"4f761d4dc3b4d602ffdc2be02600140b","_rev":"1-40b62334f3dc02ca64532fbec03f3a35","name":"Dieter"}
You can also read all documents with the special:
curl -X GET http://localhost:5984/testdb/_all_docs
==> {"total_rows":1,"offset":0,"rows":[{"id":"4f761d4dc3b4d602ffdc2be02600140b","key":"4f761d4dc3b4d602ffdc2be02600140b","value":{"rev":"1-40b62334f3dc02ca64532fbec03f3a35"}}]}
Couchdb stores versions of documents, so to edit one, you need to provide the revision as well:
curl -X PUT http://localhost/couchdb/testdb/4f761d4dc3b4d602ffdc2be02600140b -d '{"_id":"4f761d4dc3b4d602ffdc2be02600140b","_rev":"1-40b62334f3dc02ca64532fbec03f3a35","name":"Dieter Limeback"}'
==> {"ok":true,"id":"4f761d4dc3b4d602ffdc2be02600140b","rev":"2-5fc171bc10cb2c7cff75741dff04fa0d"}
...unless what's currently in the db doesn't match what you're doing (ie, you're trying to edit an old revision) at which point you'll see:
{"error":"conflict","reason":"Document update conflict."}
To delete, you pass the rev as a parameter:
curl -X DELETE http://localhost:5984/testdb/4f761d4dc3b4d602ffdc2be02600140b?rev=2-5fc171bc10cb2c7cff75741dff04fa0d
==> {"ok":true,"id":"4f761d4dc3b4d602ffdc2be02600140b","rev":"3-7b5d2673af36e2fd42b7f356b9bc6c7b"}
which looks weird, since it looks like it created a new revision, except if you try to GET it again:
curl -X GET http://localhost:5984/testdb/4f761d4dc3b4d602ffdc2be0260014b0
==> {"error":"not_found","reason":"deleted"}
Delete the entire db with:
curl -X DELETE http://localhost:5984/testdb
==> {"ok":true}
That's it for now; nothing too crazy. If I end up making similar notes when learning about Couch views I'll be sure to post them as well.
]]>The most common JS templating options seem to be mustache.js, jQuery's Templates plugin (which is destined to become part of jQuery core at some point) and Underscore's template method. Unfortunately my backends are usually provided by Django, and as there are some implementation challenges with this I thought I'd note down my options, although I have no nice solutions. (Also note that the more you move template rendering out to the client with JavaScript, the more you are basically yanking page assembly out of Django's responsibility, and as one of the three MTV pillars that Django provides, perhaps it begins to make less sense to use a large framework and you want to start investigating another tool. But that's a different argument for another time. For now I think it's still a viable option that Django handles drawing the initial page load or the non-JS version, and then everything else is done in the browser.)
So the first "hello world" you see with templates is that they get defined inside your JavaScript files:
var artistTemplate = '<div class="artist">{{ artist-name }}</div>', artistData = { 'artist-name': 'John Coltrane' }, artistHtml = Mustache.to_html(artistTemplate, artistData); $("#someDiv").html(artistHtml);
The problem with this is obviously that you mix HTML into your JavaScript, which is ugly -- you lose nice linebreaks, syntax highlighting, it's harder for making markup changes, etc. You can of course pull in these templates via AJAX calls, but that seems a bit more heavy in that you have to deal with setting that up on the backend somehow.
The other place you can put JS templates is inside your HTML templates. As John Resig first described back in 2008, you can declare a script block with a nonsense type attribute. The browser doesn't know how to parse it and so ignores it, but it can then be grabbed and used like any other DOM element from within your jQuery code.
<!-- in html source --> <script id="artistTemplate" type="text/x-jquery-template"> <div class="artist">{{ artist-name }}</div> </script> <!-- or {% include %} a reusable template to avoid DRY violations -->
// in javascript var artistTemplate = $("#artistTemplate").html(); // ... same rendering as before ...
But here we run into trouble, because {{ and }} are parsed by Django looking for template context variables, so this means both Mustache and jQuery templates won't work as expected. This is a known issue with jQuery templates but it remains to be seen if/when it will be addressed.
Some workarounds:
1) Use Django's templatetag tag instead of {{. This seems quite unreadable for anything other than trivial snippets.
<script id="artistTemplate" type="text/x-jquery-template"> <div class="artist">{% templatetag openvariable %} artist-name {% templatetag closevariable %}<div> </script>
2) Use a different set of characters to delimit template code (eg., [[ and ]]) in your script blocks, and use a regex to replace occurrences of them with the correct ones. This seems kind of ugly I guess.
$("script").each(function(){ var new_replaced_txt = $(this).text().replace(/\[\[/g, "{{").replace(/\]\]/g, "}}"); $(this).text(new_replaced_txt); });
3) Use Underscore's templating, which uses ERB-style tags:
<script id="artistTemplate" type="text/x-underscore-template"> <div class="artist"><%= artist-name %><div> </script>
If you can tolerate that it will work, but for me that markup will never get under my fingers (and is kind of heretical to a Django person ;). Note you can change what Underscore uses for delimiters, but that basically does the same regex behind the scenes.
So essentially, no quick easy elegant solution that I can see. If you have a better solution, please let me know!
]]>OK, most obvious things first. I am a single founder, working a full time job, with a wife and kids. This is basically the holy trinity of what not to do, and I understand why now.
I settled into a routine of working a full day, coming home to be with family, and then working again after the kids went to sleep. This is actually sustainable, but you have to be careful: (a) you must ensure you don't shirk your other responsibilities — set aside time to do your share of the housework and spend proper time with your family (and when you're doing that your laptop is closed); and (b) it's easy to throw off your sleep schedule, not sleep enough, or get annoyed by the need to sleep when you're on a roll.
Working by yourself, you can also dry up on motivation — cf reason number 1 on Paul Graham's list of mistakes that kill startups. So you need to do something, even if it's small, every day. This seems deceptively doable — after all, you'd break tasks down into small subtasks anyway — but in reality it doesn't seem to work like that. And if you step away from it from a small period (like a few days), it becomes harder to pick it up again, not only because it's not loaded fresh in your head any more but also to summon the motivation to get excited. This also means it's catastrophic if you take a real break. I did this, and I think it was a mistake that might be unrecoverable.
You also need inspiration. It can be envigorating to see the cool stuff that other people are doing, but again you need to be careful not to let that lead you into prioritizing the wrong things, or actually demotivate yourself by being reminded how large your task is and making it look more insurmountable.
A lot of startups grow out of a need the founders have (the well-known "scratching your own itch") or as a hobby/learning project to play with on the side. When you're merely writing for yourself, you're not necessarily focusing on building a business; you just have a problem you want gone. Which is fine, but you need to understand how it's affecting your decisions, and how they'd change if at some point you do want to start making money. For example, if I want to learn more about frontend work, maybe I write all my own HTML/CSS/JavaScript — but if I want to buld a business, maybe I just spend $35 on some template somewhere and slap it on. It can be tricky to figure out where you are.
With so little time to dedicate, you're obviously going to be moving at a slower pace. Thus you can't gauge your progress based on what you're used to; you're going to work for two months, look at what you end up with, and say to yourself "Pssh, I could build that in about two weeks". Well, you did build it in two weeks, just broken into tiny pieces and spread out a lot.
So it's hard to avoid feeling like you're in a rush. Unfortunately it's important that you do, because being rushed can lead to poor decisions. And nothing is worse, when time is tight, than having to go back and redo something or start over again.
Additionally, work is harder and slower when you're wearing more than one hat at once. It's common to end up thinking about UX and frontend code at the same time, for example, or backend and deployment. Break these into discrete subtasks if possible, so it's always clear what you're working on.
A common attraction about bootstrapping is that it appears to basically be free: apart from trivial server and domain registration costs, there's nothing preventing you from starting. And if it doesn't work out, "the only thing lost is time". This is true, but I think it drastically underemphasizes the opportunity costs involved. If you're going to spend most of your spare moments working, you'll have less time to attend meetups, contribute to open source projects, have any other time consuming hobbies, or for that matter do anything that's extra stressful or occupies a lot of brain space, like take a new day job. There's lots you can't do when you're trying to get the ball rolling.
This all doesn't paint that rosy of a picture, agreed. But I think it's still worth doing. You learn a lot and get to keep your skills sharp. It can be fun and exciting, and it definitely beats 2 hours of TV every night. And let's face it, as dedicated geeks we know we're going to be working on something on the side anyway, so it might as well be something that might have a future. I don't belive the difficulties mentioned above are insurmountable; it's just that they're not necessarily obvious, so you don't know to look out for them. But with experience you do, and you gain the meta-wisdom from putting in the work learning how to work.
]]>