Fall’n Blocks is a Tetris-like game (you can’t call it Tetris, for obvious reasons) written in AS3. This is just for fun, no real motive behind it. And of course, the source is included below. Have fun!
A note about the code: The source code is by no means the cleanest, nor is it the best implementation. This was a fun project exploring a few areas of personal interest. It’s not the worst, but be warned. (and have fun with it)
Here’s a quick tip that you can file under “good to know.”
I typically end up using regex’s at some point in most projects. Anything with user input is pretty much a guarantee. Recently when adding some new functionality to a strip tags util I came across a situation I’ve never encounter before in ActionScript. As the title suggests I wanted to use a variable value in the expression, while this isn’t typically an issue, I came a across a situation where it didn’t work. Here is the real world example.
Original regex1:
This nifty expression works like a charm. But I wanted to update it so the developer could limit which tags it stripped to those specified in a array. Pretty straight forward stuff, to use a variable value in a regex you first need to build it as a string and then convert it. Something like the following:
Pretty straight forward. So when approaching this small upgrade, that’s what I did. Of course one big problem was pretty clear.
Guess what, invalid string! Better escape those quotes in the string. Whoops, that will break the regex! I was stumped. So I opened up the language reference to see what I could find. The “source” parameter, (which I’ve never used before,) caught my eye. It returns a String described as “the pattern portion of the regular expression.” It did the trick perfectly. Here is the solution:
You can reduce it down to this for convenience:
Anyways, put that away into the old memory bank, it might come in handy.
1Original expression from Mastering Regular Expressions, by Jeffrey E.F. Friedl
Steve McConnell sets up the dream perfectly:
With stable requirements, a project can proceed from architecture to design to coding to testing in a way that’s orderly, predictable, and calm.1
Of course anyone who has worked on anything knows this is exactly that, a dream. (He agrees) Changes are inevitable. They happen for a variety of reasons, and almost always2 results in a better end product. You know they are going to happen, so you you need to plan for them from the start. You should have a change procedure clearly outline with the client, and account for them in the initial budget. Here’s why:
A project change that takes 8 hours for a developer to implement, can easily require 16 man hours from a project budget, and cause a 5 day disruption in the production schedule.
Whoa! What? That’s right. Changes aren’t limited to the time a developer spends implementing, it can affect a big chunk of the production. Budget needs to be set aside for handling requests, because even if the change never gets implemented, there is a cost associated with it. Before you can budget for it, you need to understand it. Lets look at the anatomy of a change request.
1. A problem is flagged.
Change requests always begin with a problem being identified. Problems vary greatly, from “User flow is confusing” to “We forgot about X, which our funding requires.” These can originate from the client or internally.
2. Communication
Once a problem has been flagged, all stake holders need to be updated on the situation. This happens through emails, phone calls, and meetings (internal and external). If a developer is currently build what has been flagged, they may need to stop and wait for a solution.
3. Exploration
Once everyone agrees that the problem is legitimate, and a solution needs to be found, options need to be explored. This can be anything from a meeting to user-flow diagrams and wireframes, there might be prototyping and multiple explorations. The bigger the change, the longer this will take.
4. Spec out the solution
Once a solution has been found it needs to be spec’d out for everyone. This should be in the form of a document that a client can sign off on and the developer can use to build from. It should clearly out line the problem, solution, and affect on the project cost/schedule.
5. Approval
Approvals typically have turn around time to them where everything is in limbo. Nothing can be done between the time the spec is sent out till approval. Typically there is a fair bit communication that happens here as everyone makes sure they understand the changes. This step will have one of 3 outcomes
6. Implementation
The process doesn’t end with approval, the team now must make the change. This means undoing any of the original implementation that has changed, and then building what’s new.
7. Test
Testing! Every change needs to undergo rigorous testing. Is it a web based application? You need to test in all supported browsers/versions.
8. Bug fixing
Changes introduce new bugs. When you fix a bug you have 20-50% chance of introducing a new one.3 For every bug fix you’ll need to retest all the browsers.
Even if the change doesn’t go through, there is a cost attached to it. You need to stop productivity and spend man hours before you can even decide if there is going to be a change. If there is, you might add additional cost to the project, if not it falls into just part of the production process.
This will happen to some degree on every project, so you need to account for it. Both in your time line and budget.
1 Steve McConnell, Code Complete – Second Edition, page 39
2 I’ve worked on projects where changes happen for the wrong reasons. Internal disputes, lack of experience, “absolute” orders from higher up, have all caused changes for the the wrong reasons leaving the end user to suffer. Sometimes you have to bite the bullet, but you don’t have to work with the client again.
3 Stat from The Mythical Man-Month, page 122, 1995 print
I suck at search, YOU suck at search, everyone sucks at search. Accept it. (unless your the Google bot indexing this page) YOUR sucky search skills are killing usability on the web! But it’s ok, there are people who don’t suck, and they’ll let you drink the kool-aid for free.
I recently updated this site to use Google Custom Search. It took me 5 minutes to setup, and now anyone can search for all the everthing that rocks on this site. I was so impressed I recommended it for a client project, now their search doesn’t suck either.
It actually gives you quite a bit of style control. You’ve got full CSS control over the search box (minus a little bit of Google branding), plus color/font choices on the results page, which you can display in site. Sure the Google results page isn’t the prettiest thing you’ve seen, but it’s usable, fast, and familiar to your audience (no matter who they are.)
If you need more control, you can upgrade to their very reasonable paid service. It’ll take years for the cost of the basic plan to reach what it’ll cost you to pay a developer to build you a bad search system. And by that time you’ll probably be 2 site revisions down the road and still have crappy search. So go for it, admit that you suck, and give your users something they can actually use. I’ll be doing it whenever I can.
Now if we could just stop people from using IE.
Continuing the effort to clean up some of my code, I’ve just added a logging system to my open source code, found on the code page. This logger is designed to be easy to use, Flexible, and extendable. It uses writer objects to handle the message logging. Writers can be added or removed at anytime to change what types of log outputs you want, without modifying the actual log calls. Here is a quick rundown of the key features:
With this release I’m also doing some new things that I will be carrying into future code releases as well. These are:
Unit Tests
I will be including my unit tests from now on. Because of the nature of unit tests (simple, clear, and to the point) they make for excellent usage examples that cover all aspects of a code base.
Formal Documentation
I will be releasing more formal documentation from now on. This will include more detailed information, including topics on usage and extending. It should make the code more accessible. Click here to see the ones included in the logger.
More Focused ASDocs
I’ve included ASDocs in the past, and will continue to do so. These will be focused on what they really are, (which is a language reference), and will not include anything beyond that.
If you find it useful, and create some custom writers or filters please share!
This site uses icons created by Mark James, www.famfamfam.com/lab/icons/silk