Thus, I have issued myself a one-month challenge:

The Challenge

Contribute to the web design world at least once per day for a whole month.

The Rules:

• I need to perform 30 contributions over 30 days, not necessarily 1 per day (I have a life, or at least I like to think that I do)
• Contributions can be:
  • writing articles on my blog
  • offering small tidbits of code that I believe would be of some use to others
  • provide meaningful comments on web design articles
  • tweeting about other well-written things that better the community
  • answer questions on sites such as StackOverflow, Quora, etc
  • review of a number of similar products

It Starts Today

My contribution today comes in the form of this blog post, and is a request from every web designer out there who reads this.

If you read the article and agree with what it says, take up your own 30-day challenge. Tweet this blog post, write about it in your blog and link me for a pingback, write me a comment, do whatever you can to get the word out. The evolution of the world's web design community begins with every single regular developer striving to offer something to the rest of the community. I hope this blog and the above article will inspire even one or two people to do the same as I am.

Semi-static pages are used everywhere on websites. They're those pages like an "About" page, which has content on it that doesn't really change that often. Typically, a controller would have to house these actions (/about, /faq, /contact, etc.), and  the routes specified manually. Railscasts came up with an ingenious idea to create a controller which was routed to /static/*, so that semi-static pages could be created on-the-fly and modified easily. It also allows for modifications to change without committing to a repository and going through the process of deploying all over again.

For those needing a quick Rails primer before going on, here's the quick and dirty of what you need to know to understand this:

• Rails is a MVC-based web application framework that runs on Ruby. In short, Ruby code is written to create webpages on-the-fly.
• Every request in Rails is first put through the routes file in config/routes.rb. This file tells Rails which Controller and Action is run.

Okay, let's get started. Let's create our static pages scaffold (which includes model, views, and the controller). Obviously, there are sections of this that you would want to require authentication for (editing and deleting, for example), but that's outside the scope of this tutorial.

script/generate scaffold pages title:string permalink:string content:text;
rake db:migrate

Now we need to modify our controller slightly. More specifically, our show action. Right now, it will respond to showing an element only when the ID is displayed. We want to modify it to handle a permalink as well (/about and /contact look better than /pages/135, don't you think?). Here is your modified show action:

1
2
3
4
5
6
7

def show
  if params[:permalink]
    @page = Page.find_by_permalink(params[:permalink])
  else
    @page = Page.find(params[:id])
  end
end

Before we go any further, we need to create two custom methods in our model. These will format the permalink to remove any unwanted characters for the custom route name (replacing all unacceptable characters with an underscore) and for the URL (replacing all unacceptable characters with a forward slash to allow for nesting of pages). It's also important to note here that previous validation should be done to ensure that the permalink does not have leading or tailing non-alphanumeric characters, but I removed that for simplicity's sake.

1
2
3
4
5
6
7
8
9
10

class Page < ActiveRecord::Base
  def route_name
    p = self.permalink.gsub(/([^A-Za-z0-9])+/, '_').downcase # Change non-alphanumeric characters to an underscore
    "static_#{p}"
  end
 
  def uri
    self.permalink.gsub(/([^A-Za-z0-9])+/, '/').downcase # Change non-alphanumeric characters to a forward slash
  end
end

At this point, we can create and modify our pages as we would regularly expect from a new controller. All of our pages are accessible via /pages/1, /pages/2 etc. We now need to make our controller act as our catch-all (so that all requests that do not match any of the other controllers get routed to our Pages controller), and we also need to provide permalink support. Finally, we will dynamically generate customized, name routes for all of our semi-static pages. All of that gets accomplished with a few short lines of code. Add the following code to the top of your config/routes.rb file, starting at line 2 (inside the ActionController::Routing::Routes.draw section):

2
3
4
5
6
7

def map.static_page_actions
  pages = Page.find(:all)
  pages.each do |page|
    self.send("static_#{page.route_name}", "#{page.uri}", :controller => "Pages", :action => "show", :permalink => page.permalink)
  end
end

Finally, we need to call this method close to the bottom of the code, right before our default catch-all routes.

map.static_page_actions
map.connect ':controller/:action/:id'
map.connect ':controller/:action/:id.:format'

What this method does is retrieve all of the static pages in the database, then creates a customized, named route for each page, telling Rails what each URI should look like, and where to direct the request to.

Hopefully this helps some people out with their dynamic page creation. I'm pretty sure there's a pitfall or two here, but I think it could be taken care of by doing some simple route housecleaning in the Pages CRUD controller. The perk of this option is that it allows the routes to be named, and hopefully that is of some benefit for others.

1. Buy a new car

With the potential of a great new job headed my way (possibly more on that later), I should have some disposable income in the near future. To celebrate this, I think it's time to get a new car; my current car, although it holds 5 people, is hardly what you consider sporty, is developing a bad case of rust, guzzles gas like nobody's business, and isn't fun to drive at all. I plan on buying a 2003 Hyundai Tiburon with a 5-speed manual transmission. They come in around $9000 before taxes, so on a financing plan I'll be able to buy that no problem.

2. Build a customized car trunk sound system enclosure

I'd love to put my DIY skills to the test and create a proper molded sound system enclosure for my new car. It's a lot of work, but it'll be a lot of fun. This will also be very useful to work on some woodworking skills and some custom fabrication work.

3. Start my development website

For about two years, I ran a security-based site, but eventually shut it down because my interests simply did not coincide with my interests and life aspirations. As such, I've decided to start a development-based website. I can do the security-aspect within the programming and development, but I can also get into graphics design. It fits into my interests much more at this point in time, and I think it will be more beneficial to the internet as well.

4. Develop Thimbleberry

I have a new site in the works with a friend. That's about all I'll tell you for now. Either way, should be a fun time.

5. Start actively contributing to the open source community

The open source community is amazing. Those of you that have heard of a little operating system called Linux may know that it's open source. That's right: it's free to use, free to modify, and free to redistribute. There are tons of open source projects available online, and I'd like to start contributing to one or start a new one that people will actually use. I've been using open source software for a long time, and it's about time that I gave back to the community that has helped me out in so many ways.

Well, it may be feeble, but it's a start at getting back in the writing groove. Soon I'll start doing a bit more technology writing again, and will hopefully do some stuff on interface design. Thanks for sticking with me through my creative drought, and we will hopefully see you Monday.

Extra brownie points go to those who can answer the following questions about the screenshot:

• How many cores does my desktop have?
• What music player am I using?
• What scripting language server is running in the command line?
• What is the symbol on my desktop, what is it's significance, and who came up with the idea to use this symbol for this purpose?

Anyways, I have some new photos that will be going up tomorrow, as well as some of my experiences with using an off-camera flash. Stay tuned for that!

I was approached twice after our presentation was over. The first gentleman, to paraphrase, suggested that the presentation would be more useful had it included a mitigation strategy to prevent and (hopefully) eliminate the possibility of attack. I thought he might be on to something here. After all, wouldn't it be great to have a check list to go through, and making sure each item is checked off would result in a secure application? For the rest of the day, I spent a lot of time going back and forth on this idea. On one hand, this check list would be nice, but I also firmly believe that a large amount of the prevention relies on the skill level of the programmer, debugger, and penetration tester, and a check list simply wouldn't be sufficient to protect yourself from attacks. But, having the check list would be a good start. Sort of an "if you've done these things, you've covered the basics" check list. It would be a good reminder sheet for pro programmers, and a good stepping stone for those who are just starting off. To that person, your suggestion has been heard, and the check list has been added to my to-do list, hopefully to have a first draft out within a month or so, so stay tuned for that.

The second gentleman asked if the slides to the presentation would be online for later viewing. At the end of the presentation, although we took almost an hour, I was well aware that we were rushing; we probably had too much content that we wanted to cover. Before the presentation I had already planned to put the slides online as a reference; although it's nice to see the slides during the talk, it's also nice to go back and view them at a later date. Thus, my slides will be online here for anybody to take a look at. I will also be posting my source code, but that will be a bit later (ie. probably next week), since there's a few sections that are a little finicky right now.

While this is all fine and dandy, things like development and multi-tasking can prove to be a little frustrating when connecting to a remote location and requiring more than one window open. Although a typical command line pretty much prevents this from happening, using GNU Screen or Byobu can make things a lot smoother. One window, multiple command lines.

As most developers will tell you, having multiple windows available to you is a godsend. It's particularly useful when you have scripts to run in the background that generate output, but you don't want to fork them as a daemon. Now, with GNU Screen and Byobu, you can do this easily, and even make your screen look snazzy as well. The only drawback to these utilities is that they are a little hard to get used to. In this post, I will quickly outline some of the key combinations which I use regularly.

GNU Screen and Byobu Simplified

The number one thing to remember about every command you use is Ctrl+A, which will be written as C-a. This is picked up by screen and will tell the utility that the next characters typed will be commands for screen to interpret. Keeping in mind that all keys are case-sensitive (as most things are in Linux), take a look at some of the commands below:

C-a c - Create a new screen window

C-a A - Rename the screen

C-a C-a - Go back to the previous window

C-a <0-9> - Switch to screen #0-9 (quick toggle)

C-a " - View a list of the current screens, which will allow you to select one from the list

C-a ' - Enter a screen number to switch to (slower version of C-a <0-9>)

C-a d - Detach the whole screen session and fork to the background. Very useful for remote sessions you want to leave open. The command "screen -r" will resume your screen session.

C-a <Escape> - Scroll up through your command line "history" and see what output you previously got. Hitting <Escape> again cancels it.

With the introduction of Byobu in Ubuntu 9.10, you can also get some statistics added to the bottom of your command line window to help keep you informed about the state of the system you are running on. Hitting F9 in session will bring up the menu for customization, which can make your screen session look pretty awesome. Instead of using screen to start your screen session, simply use byobu instead. Easy as pie.

If you have any questions about GNU Screen or Byobu, let me know and I'll see what I can do to answer them. Stay tuned on Friday for another issue of "Five Things" (hopefully).

On the way home from an event a couple weeks ago, I was talking with a friend about the hassle of all the paperwork we have to go through every time we have a lesson; we need to fill out transaction logs for each payment, keep track of every person's attendance for each class, and also mark it on their membership form that they attended and paid for that class. A single person dropping in to that class requires writing on three sheets of paper. When you're trying to run everybody through quickly, that starts becoming an issue.

This friend, being the kind of person that seems to regurgitate good ideas on demand, suggested to me, "Brian, you're a developer. Just write a program to do it for you. You're learning Ruby and Rails, so you can do a web-based backend and a GUI frontend. Problem solved!". Thus, I sat down and started planning. Rails seems to be yet another one of those languages that lacks any decent documentation or tutorials. If you plan on learning it, pick up "Agile Web Development With Rails". It is by far the best development book I have ever read. If it's any sort of selling point, one of the authors created the Rails framework; if he doesn't know how to use the framework, nobody does.

As a method for potentially helping me brainstorm, I've decided to spill out some of my ideas and goals here. I'm only going to discuss a few ideas here; while I would normally immediately distribute this idea into the public domain, I've decided to keep this one closed source. If you have any suggestions or ideas, let me know and I will give you credit. Better yet, if you're interested in this software, get in touch and we can discuss it.

Goals for Dance Site

• Members: Keep track of all members, regardless of how long ago they joined. Eliminate the need to fill out a new membership form every semester. Each member should be assigned a member number, which can be put on a barcode. Keep track of personal information, interests, and attendance. Gather statistics/metrics from attendance vs. month/day/semester, etc.
• Memberships: Handle multiple membership types, including drop-in. Integrate with finances to determine when a user has paid for their membership through drop-ins. Support for online payments through Paypal (ie. Mastercard, Visa, eCheck, etc.)
• Finances: handle per-lesson incomes. Support for multiple lessons per day. Keep track of what is taught during that lesson. Provide unlockable content for each lesson; attendance to that lesson unlocks the content for that member; refresher videos, class notes, etc. Support for discounted membership dates/times.
• Graduated system: attendance of X number of events allows you to attend higher level classes. Ability to override by administrator.
• Mailing List: Separate old members by current members, allowing for class updates to be sent to current members, while global events to be sent to all. Ability to unsubscribe.

I've been recently programming a proxy in the Ruby programming language, which is known for its code elegance. When you know how to use it, it's a great language. The problem, however, comes when to learning about the API in the language. To put it bluntly, the documentation is crap. To be more specific, a good amount of it is incomplete, and those sections that are completed fail to follow a consistent fashion. To put things in perspective, there are 108 core libraries included in the Ruby documentation; over half of those libraries have incomplete documentation.

Now, this isn't that much of an issue if you know how to use the language; after all, there's no need to go to the documentation when you know the language. The problem comes when you are like me, learning how to use the language, and don't know what any of the constants for the sockets library do, which is a bit of a problem when you need to program a proxy. See where I'm going with this?

Maybe I'm complaining because I've been spoiled on PHP's phenomenal documentation, which is an amazing feat when it comes to documentation. All of the functions are properly laid out with plenty of cross-references, and tell you exactly what to expect for each and every function. The documentation is a work of art, I kid you not. Don't believe me? Try learning how to do something complex in PHP using the documentation only, then try to do the same in Ruby.

I have heard some people make the argument that Ruby is open source and relies on its members to do the documentation, hence the lack of it. While I understand this argument, it doesn't entirely make sense. Ruby has a large band of dedicated followers (think Jehovah's Witnesses-style) who should have filled in the 1.9 documentation by now. Thinking about it from another perspective, PHP is a free and open source language as well, and look at the detail in there compared to Ruby.

All I'm saying is that Ruby needs to step up its game a bit, otherwise it will have trouble competing for those people looking at learning a new language. If it wasn't for an amazing IBM document on Ruby socket programming, I would have moved on to another language by now.

Anyways, tune in this Friday for something different. I realize programming isn't everybody's cup of tea, so I'm hoping to branch off into something a little different for those of you who either find computers boring, or those of you that simply don't understand them. As always, I appreciate you reading, and I appreciate even more those of you who tell a friend about my blog .

In the past week, I have gotten a number of experiences that I would not have gotten any other place. My first two days were spent trying to break into a web application on a VM. Although I managed to get access to a few things, I never really got that far.

Today presented a similar scenario. In a virtual network, there were a number of computers: some desktops and some servers. I had to gain access to some "fianancial information" hidden on a server, using exploits in the other machines to gain access. Although I needed a few hints here and there, I managed to get the sensitive information using a variety of tools, including two kernel exploits, sqlmap, Nmap, Metasploit, and RainbowCrack. It was a really fun experience, and I'm glad I got to take it for a test drive.

The icing on the cake for today, however, was using a decompiler to disassemble a fake program requiring activation and bypassing the registration. From the information gathered we made a keygen using 3 different methods. Doing so requires a bit of smarts and a lot of assembly knowledge, which is something I don't have a lot of. With some help though, I managed to crack the registration, which was an exhilerating experience.

These experiences are pretty much all thanks to Ron Bowes, one of the guys I'm working with. I'd call him an IT Professional (he's certainly skilled enough), but he might laugh at me for such a remark. The virtual network was all designed by him, and he walked me through the application hacking, showing me every step and how it was done. I certainly have no intentions of using any of that knowledge to break the registration information for any program for any reason other than my own personal development, but it was still a really amazing experience. He keeps a blog on his homepage (I'm mentioned in a recent post), and it's certainly an interesting read.

A final thing that I'm working on at work is a suitable replacement for Burb Suite, which is an application for attacking web applications. It's a really powerful program, but there's three main problems with it: it's closed source, you have to pay for it, and the Swing interface is god-awful ugly. Other free utilities lack in either power, the user interface, or both. So, upon approval from a supervisor, I might be helping to develop a free open source alternative which would be released into the public domain. We've decided to program the backend in Ruby, and so far it's going really smoothly. In just one day I almost have the proxy designed, and I'm looking forward to getting the backend completed.

All in all, work is great so far. Getting paid to do something you love is amazing.

As many of you may know, I run a site called H2H Security Group, which has been an ethical hacking knowledge base. Over the past few months, there has been little-to-no contributions to it, and it doesn't seem reasonable to keep the site up and running without any participation from other members. My interests have also shifted (matured, if you will) to encompass development-related topics rather than hacking, and I believe that another style of site would suit my interests more than this one. As such, I have decided to take down H2H. It was a hard decision to make, but I believe that my knowledge and expertise would be more suitable in a development site. Therefore, rather than simply removing a part of myself from the internet, I have decided to replace it with a development site. I realize that there are a lot of them out there, but this is something that I am much more passionate about, and will coincide much more with my interests in web development. Hopefully I will be able to attract more people interested in topics similar to this.

H2H spent a lot of time up and running because of its members. Specifically, I need to personally thank Aaron Goldsmith (aka AltonRashmire) and Sam Jenkins (aka Satal Keto) for their donations, dedication, and hard work. Their support, both technically and monetarily, has meant that H2H has survived for much longer than expected. They have earned both my respect and my friendship, and I will no doubt keep in touch with them, hopefully on my new development site.

One thing that certainly held H2H back was the hosting I went with. I have been with Lunarpages for 2 years now, and I have decided to move on due to lackluster tech support (a phone call I made to them which was not toll-free resulted in me yelling at the person because he was completely unaware of the DNS exploit which resulted around that time which crippled my site) and significant downtime as of late, which has been severe enough to even take down their own site. Add to that the additional costs for simple things like installing SSL certificates, and you have one unhappy customer. I am now starting a web hosting company with a few friends, which will be an eco-friendly web host. If you are looking for a good deal on hosting, contact me; mention this blog post, and I'll take $1 off per month, which works out to 20% off (this offer good until the end of September 2009). I'll bring you more information on the new host when it is purchased.

Finally, I start my new job in a week and a half, at the Manitoba Information Protection Centre. I have been looking forward to this for quite a while, and I expect it to be an amazing experience. This will certainly be a great learning experience, and definitely be a great source of income, which will be needed to fund my technology addiction.

That's all for now. More later. Sorry for not following my schedule. I'll work on that.