Matt has been working on and off as a contractor for Angry Monkeys since we started 2 years ago. He's been a great help in times when we've needed it, and we've been able to help him out on a few of his projects as well. As time has gone on, it has become more and more apparent that our collaboration was going to be a long term deal, and that the need to formalize it has become more important. From his point of view, a regular income means he doesn't have to whore himself out to a dozen different companies, and from our point of view we get the security of having a designer who is always available.
So I'd like to be the first to say welcome to Angry Monkeys! Enjoy your stay and don't drink all the coffee!
After getting a lot of feedback from our users, we're excited to announce that we'll be releasing an update to the Fivesecondtest Beta this Monday. There are a lot of changes, and a lot of little tweaks. We're not ready to call it Beta 2 just yet, because we have a lot of things planned for Beta 2 that aren't quite ready to go live yet! At the moment, we're trying to really nail the basics before we move on to some of the cooler things we have planned!
So this new version is more of a refinement on what we already have, lots of bug fixes and a lot of little improvements based on the feedback we've had so far.
So... in no particular order, here are some of the things you can look forward to come Monday!
- The Classic test is back! - Due to popular demand, we're bringing back the original fivesecondtest! Whilst everybody loves the click test, we've had a lot of people comment that for their particular needs the original test actually gave a better result. We listened, and so it is back!
- The Click test has been revamped - We found that clicking is great, and keywords are great...but clicking and then remembering WHAT you clicked is tough! In this update, we'll unhide the image for Click tests! This means that users can flag the most prominent areas without having to play the memory game to remember what the saw.
- Keyword report has been improved - A common request was to have manual sorting of keywords in addition to the auto-sort. In many cases users would refer to the same item by two common terms that weren't auto matched. E.g. "woman" and "girl" or "jersey" and "jumper". The updated keyword test will allow users to drag like-terms together and combine the results!
- Better instructions - Maybe it's because we keep changing stuff....or maybe it's just because we got it wrong.... but a lot of people asked for clearer instructions on HOW to participate in a five second test. We hear you! Instructions are now clearer (we hope!) and tests are easier to participate in!
- BUGS! - Yes we had bugs. We've been fixing them...we promise!
Migrating databases has always been a pain the ass.
In the past, I've used tools like RedGate SQL Compare to get the job done. The last major project I worked on (with a team of a dozen developers) we used a custom solution of managing sql updates and change scripts. Nasty business.
The main issue with updating databases is not only making sure that your test database matches your staging database which matches your live database, BUT that the database of each instance matches the code running alongside that database. Regardless of which method you use the code-sql versioning has always been a pain. I can't count the number of times an SQL update has been applied when the relevant code patch hasn't!
This problem is magnified when you are working in an "Agile" environment. When you're making frequent code updates and with a scope that is constantly changing, databases changes unfortunately are a necessary evil. The Ruby crowd have been using database migrations for some time now, and it's only recently that the .NET community is catching up.
I've recently begun using MigratorDotNet. It's not perfect, and is still fairly immature, but it makes managing databases a lot easier than keeping track of change scripts! My particular implementation probably isn't the most recommended method...but it works for me and it saves a lot of messing around with build targets and project configurations. If you haven't already, take a look at the wiki and have a read of the "getting started" page...cos I'm going to assume you know what this code does.....
[Migration(1)]
public class _001_Init : Migration
{
public override void Up()
{
Database.AddTable("dbo.tbl_Tokens",
new Column("TokenId", DbType.Guid, ColumnProperty.PrimaryKey),
new Column("UserId", DbType.Guid, ColumnProperty.NotNull),
new Column("DatePurchased", DbType.DateTime),
new Column("DateUsed", DbType.DateTime)
);
}
}
Where I change my process is how I set up my projects and how I run my migration. This is for a web application obviously btw.
Do this much (taken from the getting started Wiki):
1. Add a new class library project. In this example it's called Called DBMigration.
2. Create a lib directory in your DBMigration project, and extract all the dotnetmigrator DLLs into it. You can exclude database-specific DLLs that you don't need. e.g. If you're not using Oracle, you don't need Oracle.DataAccess.dll.
3. In your DBMigration project, add a reference to the Migrator.Framework.dll. That's the only additional reference you need in the project.
Now....Ignore the rest of the steps, and do this instead :)
4. Create your first migration class (like the one above).
5. In your web application, add a reference to Migrator, Migrator.Framework and your DBMigration project.
Here's the trick for the lazy peeps that can't be bothered messing with MSBuild and build targets!
In your Global.asax file... you want something like this:
protected void Application_Start()
{
string strConnString = ConfigurationManager.ConnectionStrings["AspNetSqlProvider"].ConnectionString;
Assembly a = System.Reflection.Assembly.Load("DBMigration");
Migrator.Migrator m = new Migrator.Migrator("SqlServer", strConnString, a);
m.MigrateToLastVersion();
}
Whenever you update the code for your application, on first run the application will automagically update the database using your migration scripts! Nifty!
A few important things to take note of here!
The first thing to understand is the connection string. I set up my connection strings using an external XML which is referenced from web.config....like this
<connectionStrings configSource="connections.config"/>
And in my connections.config file I have the connection string for the Live OR test OR staging server. There is different version of this file on each respective server (thus make sure it's not in your solution if you use VS deployment!).
Why? So that when I deploy my application to the test server, or to staging, it will be updating the database for THAT server only. This means I have a seamless means of updating my database at the same time as updating my code. No batch files, no configuration, no build targets! Just run it, and it updates the right database!
Now, obviously this is NOT ideal for all situations. You'd really need to be sure that this approach is suitable for what you need. For us, we do infrequent updates to the live server, but are constantly updating our staging server. This approach means that whenever we deploy and run the website, we know the database is going to be update and correct!Recently I got talking with one of the guys who created the popular fivesecondtest. He was looking to do something a little new and different with the site, and was going to go it alone and redevelop the whole thing. I had a bit of spare time on my hands and decided to lend a hand.
The result is just about here. Whilst some features have been cut for the time being, they hopefully will make a return...if in a slightly different form. As well as a redesign of the site, we've redesigned how tests are conducted. The focus at the moment is revisiting what information we can learn from someone in a teeny weeny amount of time.
In the coming days we'll be launching a Beta version of the new site for regulars to take a look at and have a play with it. This is a real Beta, not a Google-esque Beta that will last forever. This will be 4-6 weeks of focused testing and gathering of feedback. We're putting this out there to see what the users think, get some input and then go back and do some more development. We hope that the new design, and the new test format will make it easier to do tests, and easier to learn from the data that is produced. We could be completely wrong, but we'll find out soon enough.
In the next couple of days I will be getting Matt to join the discussion here and explain where fivesecondtest came from, and where he believes it is going. Until then, we'll continue working hard towards a beta release!
Alan
I love JQuery. I used to hate it. But now I love it. I especially love it when working with .NET MVC.
I'm building an app at the moment which allows a user to upload a file, and during the process they can choose to have a link to the file sent to them. It's an optional thing, just to save them having to cut and paste a link. It's a nothing feature... a bit of a freebie, and I didn't want to spend a lot of time on it.
More importantly, I didn't want to stop the user in their tracks to do this particular task. The email field just sits there in the Nav, and if you want to use it you can and if you don't want to you don't have to. Most importantly, however, if they user did choose to fill in the email box at some point, I didn't want to take them away from what they were doing by doing a full post of the page. Enter AJAX!
Ajax is nothing new, and neither is MVC. But in the world of .NET they're both still kinda fresh. So here is how I went about creating a neat little emailer in the middle of a page.
First of all, some HTML. The simpler the better!
Then some JQuery....<form id="EmailForm" action="/test/email" method="post"> <input id="emailAddress" type="text" value="email address" /> <input type="submit" value="go" /> </form>
OK, so far so good. All pretty straight forward. That, of course, would work with any server side technology...not just .NET MVC. BUT, the reason I like this so much is because with MVC we don't even have to bother with a responding page. Previously in .NET you'd have to create an ASPX page or web service just to handle this AJAX request (or a library of them perhaps). If you have a route setup already, all we need is a method in our controller class to handle the AJAX request!$("#EmailForm").submit(function() { //capture the submit event of our form $.ajax({ //create an AJAX request type: "POST", //use POST (we could also load this from the form if wanted to) url: $("#EmailForm").attr("action"), //get the URL from the form data: $("#EmailForm").serialize(), // this one line turns our whole form into tasty AJAX snacks! success: function() { alert("win!!!1!1!") //we got a 200 back...it worked! }, error: function(XMLHttpRequest, textStatus, errorThrown) { alert("epic fail!") //something went HORRIBLY wrong! } }); return false; //don't forget to cancel the event so we don't submit the page! });
That's all there is to it! Of course, this particular method doesn't return anything to the AJAX callback (except an error if something breaks!)..... so you'd probably want to return something if the address is invalid and show a nice error to the user. But I'm keeping it simple here. The crux of what is cool about this, however, is the separation between HTML and code. Because MVC doesn't have tightly coupled Pages/Classes/Code behind, you can not only reduce the amount of code you write (by doing away with superfluous aspx pages and reusing existing functions), but you increase the number of ways you can use the code you have already written. Doing an AJAX request becomes nothing other than another type of View.... the Controller doesn't have to care where the request is coming from and it means neither do you![AcceptVerbs(HttpVerbs.Post)] public void Email(FormCollection form) { string emailAddress = form["emailAddress"]; // validate the email address ..... //create the email message MailMessage msgMail = new MailMessage("info@angrymonkeys.com.au", emailAddress); // do some email content stuff ....... // send the email! smtp.Send(msgMail); }
So you've worked out how to use MVC and the Entity Framework. You can add objects to the database, and you can get them out again, update them and save them back. Awesome! But have you found it cumbersome to create instances of objects just so that you can maintain referential integrity with your foreign keys?
I've been reading about on the web about inserting entities to the database, and including references to primary keys in another table. I'm actually surprised the number of ways I've seen this done. This is the most common way I've seen people do it:
When I first saw that, I thought... yeah ok. That could work. I've seen plenty of similar methods as well, revolving around selecting a customer, user, book or whatever by id, return the customer, user or book and then adding it to the object we want to save... and then saving it. The problem here, as far as I can tell is that you end up making an unneccesary select from the database. If we already now the key for the Customer, then we SURELY can just insert that into the table along with the rest of the data?!? Am I right? Yes. I am. Next time you go to create an Order, have a look just under Customer in the intellisense drop down.... you'll see CustomerReference. If your data model is right, this should be an Entity Reference to your customer. This is the key to inserting your Customer ID (pun intended).Model.Order order = Model.Order.CreateOrder(); order.Customer = (from c in Customer where c.Id == custId select c).First(); db.SaveChanges();
That's it. That's all you need to do! The only trick to this is sometimes working out what the hell "Model.Customer" should be. The easiest way to find that is to type:Model.Order order = Model.Order.CreateOrder(); Model.CustomerReference.EntityKey = new EntityKey("Model.Customer", "Id", custId); db.SaveChanges();
...and let Intellisense come up and remind you what your entity sets are called. By default it can create Customer as CustomerSet or something equally strange (Of course, "db" is whatever your ObjectContext is called). Also make sure you get your casing correct, as customer != Customer :) Alandb.
So I've been using .NET MVC and Entity Framework for a while now. I originally started learning about LINQ to SQL about a month before MS announced they were dropping it in favour of EF. Yeah thanks guys. Anyway, my latest project is a collaboration with a guy who has done a bit of Ruby development. Specifically, the website I am helping him rebuild was built using Ruby on Rails. I did spend some time learning Ruby, and getting the app up and running, but given all my stuff is Windows based (hosting, development environment, databases etc), it really was a case of going back to being a beginner. Not such a bad thing, but we wanted to get all this done quickly
Given that I am the developer, and I am a fan of .NET, the logical compromise was to go for .NET MVC. We can reuse a lot of the logic from the Ruby MVC app, and simply reimplement it in .NET. In fact, for the most part the views from Ruby translate directly to .NET with little to no work at all.
For an ASP.NET developer (and an ASP dev before that) the whole concept of MVC is a little odd. When you've been working within the page model for so long, it is really quite hard to break out of that mindset. "What do you mean there's no Postback!?!?"
Once you get your head around routes, controllers, models and views the rest flows on pretty quickly. As I said, I'd been doing a bit with Entity Framework last year, so at least the Model part of MVC already made sense!
I think the best way to explain MVC to a Page model developer (i.e. me) is to think of it in terms of standard Page model app with URL rewrites.
In the past we'd get a URL like /home/news/article/10 and rewrite that in the Request_Start method of Global.asax to go to something like /news/showArticle.aspx?id=10
In MVC, instead of writing a redirect in Request_Start, we add a Route (e.g. {controller}/{action}/{id})
Now, instead of redirecting to a page with some "code behind", we redirect to a View with a controller. The concept is still pretty much the same stuff. Rather than having 1 to 1 pairing of pages and code behind, we have a set of views that all operate off the same controller. The idea here being that all "news" functions will be handled by the News controller, rather than by a dozen different code-behind pages. Conceptually it is a lot neater.
The MVC structure also forces you to be a lot more strict with your HTML design. You will find that you're forced into using partial controls (or user controls as we called them in normal ASP.NET), simply because it is the only way to effeciently get data to the view without duplicating code everywhere. It tends to allow you to focus more on the HTML as one component and the Data as a seperate component, which is how I prefer to think anyway. The two become fairly loosely coupled, unlike ASP.NET where the code-behind and the HTML are joined at the hip.
The other benefit is that you only need to worry about requests coming in, and the data that you need to spit out. You can leave the HTML to the designer. MVC isn't a one-size-fits all solution of course. It isn't particularly well suited to applications that rely heavy on user state for example. But it works wonders on Action/Result type applications! The highlight for me, however, is that I don't have to use RoR to acheive RoR-like results!
I've had this blog up and running for about 18 months, and have so far managed to make two posts (make this three!). It's not that I'm lazy, it's that I've been very busy working. I had a realisation this morning, however. A lot of the stuff I am learning is hard to find information on. Specifically, .NET MVC, Entity Framework and things like Object Queries etc. I figure when I eventually do work out the answer, It'd probably be useful to other people looking to solve the same problem.
So (hopefully) from now on, when I solve a tricky problem. I will take a few minutes to do up a blog post about my findings. Hopefully others that are out there crawling the web looking for answers may find some help here.
It seems like only yesterday that I was making my first post here. Now, here we are 12 months later already!
A lot has happened over the past 12 months. We've built a lot of websites, applications, flash banners and even a couple of desktop applications! My what fun! Of course, coming up to Christmas things are winding down, resting up before we start it all again in the New Year. The upside of this is that we've now got a little time our sleeves to start doing some of our application development. We have a couple of applications on the go; some which we hope to release soon, and one or two that are at least 6-12 months away. But we're moving closer, and that is better than moving further away!
Angry Monkeys will be open throughout the Christmas season, so feel free to get in touch with us at contact@angrymonkeys.com.au.
The last few months have been a crazy time for Angry Monkeys, so much so that we’re seriously considering a name change to Crazy Monkeys. We've been so focused on doing paid work; we've completely forgotten to work on our own projects. We have a number of world-changing web solutions on the go, but just haven't had the time to get them over the line. Heck, we still haven't gotten around to building our own website! This is making our Angry Monkeys even angrier! So, what to do? Get more Monkeys of course!
We're looking for talented, enthusiastic, experienced developers with a keen sense of what makes the web tick. Being a small company (well, there is only me), the role involves a whole lot of responsibility, and a whole lot of opportunity. This is a chance to get on at the ground floor of company that is truly going places (we’re actually on the 13th floor for the superstitious). Most importantly, it is a chance to control the direction of your own future.
We won't be offering a whole heap of cash to the successful applicant, because if that is what drives you, then you don't have what we need. We need someone whose passion is developing cutting edge web applications and technical solutions to some pretty scary problems. We need someone with uber .NET experience, extreme JavaScript knowledge, top notch SQL Server design and development skills, and a heap of prior web development projects up their sleeve. PHP, Flash, Photoshop and Bow hunting skills are a bonus. We can offer ultra-flexible working hours, the opportunity to work from home or from the office when you choose, your own computer with big-ass LCDs and most of all; that warm fuzzy feeling you get from making a real difference.
All applicants will need to display a passion for web development, be able to demonstrate the ability to create cutting edge web applications, self-learn and most importantly, have a serious commitment to quality. We don’t create half-assed solution, and “hacks” are definitely out.
Please apply via e-mail to givemeajob@angrymonkeys.com.au including resume, examples of work and references.