For game reviews, actual critique should be the standard. Leave the brief overviews to 'First Look' and 'Preview' articles, please.Read More
I've been learning clojure in my spare time and I think I'm at a point in my understanding of the language to produce something fun and useful. Well, not necessarily useful, but definitely fun! I like to specify my plans in great detail in order to organize my thoughts and decompose large problems into distinct and unrelated bits. Here's a sort of 'dump' of my mental DB from the last week of erudite Subway-meditation:
Because I'm an internet person with what I like to think is an exquisite sense of humor, I will be writing a easily-deployable server that can create memes for you from given templates. Potential features of the server itself are as follows:
- Upload templates
- List current templates
- Create a top / bottom caption style meme from any template
- Create a demotivational style meme from any template
- Store files on either an S3 bucket, local folder or maybe Imgur (pending API research)
- List images generated from each template
None of these features should be too difficult for someone new to Clojure. I expect the largest complications will come from interfacing with external APIs.
So far, I've neglected to discuss how users will interact with the server. This is actually the most interesting part of the project for me. I'm not very interested in re-hashing Memegenerator.net or anything like that. I'm interested in creating alternative interfaces that would fit better in my workflow. (Yes, my lulz workflow.)
Initially, there will be two ways to speak to this server:
- HTTP (REST-like API)
- Command-Line (Using single commands like
meme --gen y-u-no "Take out the trash!"or running a sort of REPL that does this)
I spend pretty much all my time on the command line, if I can, so not having to open Photoshop or go to a pretty ugly and obnoxious website to provide 'quality entertainment' is nice!
My choice of front-ends to the server also afford me a great deal of flexibility. My primary design goal here is absolute separation of concerns between client and server. I've always felt like there are so many applications with very useful backends, but utterly crippling frontends. I can offer the simplest tools first, and use these tools as building-blocks for more complex interfaces. The HTTP interface means writing a client library, rebuilding Memegenerator.net or anything else will be simple and require no code changes to the backend.
This very strict separation, inspired heavily by the UNIX design principle of building complex tools out of modular pieces with a single concern is what I will be most proud to see enacted once this is over. I also have plans to build a version of Catan to run in the office to play asynchronously during a slow evening / turn-based throughout the day without having to deal with the setup / teardown of a board game when it's just not feasible. That's the subject of a later post, but I plan to re-apply the lessons learned here to that project.
That's all I've got for now, but I will be regularly blogging (Hopefully with code.) about my progress on this silly little project. I think I've got an interesting idea for a debugging tool for the image manip. library inspired by LightTable. Time to get started!
Level 6 of the challenge takes place on a server that hosts a sort of social network. Users can log in and post things to a public 'Wall'. There is another user on the system that logs in to check on recent posts approximately once every five minutes. There is also a page on the application which will show the current user's password in plain text (!).
My first approach was to use XSS to ebmed a harvesting script in a post. The script would make an XHR request to the page that shows the current user's password and post it back to the wall automatically, leaving a landmine for the other user. Getting anything executable on the page involved some breaking parsing on the JSON string embedded in the page that showed the recent posts, and a single tag in any message body will do that. At that point, the various client-side encoding / filtering that happens when a new message is posted cannot run.
Stripe really created something great with this competition. I feel much more confident in my understanding of the subtle ways in which browsers protect users from malicious content and that my own code is (hopefully!) better protected than some of these challenge's sites! ;)
Thanks, Stripe. It was fun.