Project Anvil

Ever heard of the Joel Test?

It's a simple test to measure how well a software team performs. It takes less than 3 minutes to complete, because its a simple yes/no answer test to twelve questions:

1. Do you use source control?
   
2. Can you make a build in one step?
   
3. Do you make daily builds?
   
4. Do you have a bug database?
   
5. Do you fix bugs before writing new code?
   
6. Do you have an up-to-date schedule?
   
7. Do you have a spec?
   
8. Do programmers have quiet working conditions?
   
9. Do you use the best tools money can buy?
   
10. Do you have testers?
    
11. Do new candidates write code during their interview?
    
12. Do you do hallway usability testing?
    

So for fun, I thought I would take the test.

Do you use source control?

Yes. Anvil's source code is maintained in a Subversion source code repository. Some of my previous posts included screencasts where you see Subversion in action (indrectly).

Can you make a build in one step?

Yes. We use Automated Build Studio. I blogged about that earlier today.

Do you make daily builds?

Yes. See above.

Do you have a bug database?

Yes. We use FogBugz. I blogged about how we track defects earlier this month.

Do you fix bugs before writing new code?

Yes. Although everything is new code right now. :)

Do you have an up-to-date schedule?

Yes. I use a mindmap to track requirements and project plans. I blogged a bit about how I use mindmapping for project planning.

Do you have a spec?

Yes. Sort of. Although we don't use spec docs like Joel defines it, I screencasted how we use functionality mindmaps , technology mindmaps and threat models.

Do programmers have quiet working conditions?

Yep. I telecommute quite a bit myself and use a lot of quiet space in my home, including a full home office. Most of Anvil was written on my back deck this summer, while I listened to the rustling leaves of the huge trees in my backyard in British Columbia, Canada.

Do you use the best tools money can buy?

Yes, I believe so. There is a list on the right side of this blog.

Do you have testers?

Yes. And we use automated functionality testing with the use of TestComplete.

Do new candidates write code during their interview?

Yes. Although I didn't hire anyone for this project yet. Remember... it was supposed to be just me.

Do you do hallway usability testing?

Yes. Although to be honest I don't pick people out of the hall. Two days ago I had the gardener try the Anvil Manager. Yesterday I had my wife try it. Today it was a potential customer. I will have a few more people check it out before I ship a public beta.

So there you have it. Looks like I pass the Joel Test with an A+. If you work with software in your business, take the test yourself and see how you do. And make sure you read Joel's article on the subject.

Posted by Dana Epp at 09:28 PM | Permalink | Comments (3) | TrackBacks (1)

In the current state of software development, with projects becoming more and more complex, building, testing and releasing of software projects consumes an ever-increasing amount of time and resources.

Amen. That quote comes directly from AutomatedQA. They are the makers of Automated Build Studio (ABS), the tool that I used to create an automated build environment for Anvil.

I routinely get asked how we can manage the deployment of our software so effectively. With such a small company, people are surprised when they here that we automate a LOT of the daily tasks that are needed in building software, replacing the need for warm bodies that are typically used in software companies. These days I believe I have eliminated the need for a few employee positions with the use of automation. And that directly benefits the bottom line, since human resources is one of the biggest costs in a software company.

With the main pieces of technology now built for Anvil, I wanted to create an automated build environment so that during the beta I can consistently and constantly have daily builds available to my testers. So I decided to record a screencast introducing how I used ABS for Anvil, and how easy it is to set up.

Anvil Automated Builds Screencast [Flash ~21MB]

Posted by Dana Epp at 03:34 PM | Permalink | TrackBacks (2)

The last piece I was waiting for from CryptoCard came in yesterday, and I finished implementing it today. I can now initialize their KT tokens, and offer the ability to import tokens directly into Anvil.

I can also now automate the manufacturing of tokens for distribution. Not a really important piece right now, but a piece I will need once commercialization is ready to go. Since these tokens have barcodes on the back, I think I will write a barcode scanning app that can read the serial, initialize the tokens, create the AES keys, set the seed and generate the first challenge all with a single scan of the barcode.

Fun stuff. But stuff that can wait until the beta ships.

Posted by Dana Epp at 02:58 PM | Permalink

Ok, here goes the acronym game.

Seems installing IAS on a server with ISA where a DC is involved causes extension DLLs to not load thanks to an authentication DLL from ISA. *ugh*. Get all that? IAS and ISA are different products. One's a RADIUS server, and one's a firewall. And they aren't playing nice together.

Not quite sure how I can programmatically handle this. For version one, I will just document this in the installation guide for the IAS installation. On top of that, ISA installs a "Connection Policy" into the IAS server which has to be modified so my extension DLL can work properly. Good news is, I now have a working IAS DLL. Bad news is, its a week and a half late. *sigh*. And I still have to rewire it to communicate with the Anvil Web Service I got working last week.

Good news is, the major hurdles are now all overcome. The next few days will be a bit easier, even though I can see we are already a week and a bit behind. Then again, writing a RADIUS extension is pretty much its own product. Guess I shouldn't be complaining. I wonder if that entitles me to an extra 30 days of development :)

Ya, I didn't think so either.

Posted by Dana Epp at 05:13 PM | Permalink | Comments (4)

Thats right folks. After an amazingly challenging week, I can now authenticate my CryptoCard hardware tokens against Anvil! The most difficult and important piece is now done.

I wanted to share in the experience with my readers, and recorded the first officially working authentication request and response to the Anvil Web Service in a screencast. Watch it to see how easy it is to send a SOAP request or HTTP post to communicate with the strong authentication server. Thats right... only a few lines of code are needed to consume the web service and offer strong authentication in pretty much anything... from PHP and Ruby on Rails to Perl and ASP.NET.

If the demo feels a bit slow, thats because it's in debug mode, on a slow TabletPC with tonnes of tracing turned on while Camtasia records everything. Even still, the responses come in pretty fast considering all the crypto behind the scenes.

You may notice the response is a simple XML message with a boolean. You may be asking yourself how come there is no detailed response on a failure. The details ARE in the audit log... but I chose NOT to disclose the reason for the failure against the request. During threat modeling I decided that was too much information disclosure that a potential attacker could use against the server. If a valid user truly is having troubles (which I believe will be rare), they will have the ability to resync their tokens and reset their PINs in a future release. I decided not to pursue those features for version 1 of Anvil.

I am really happy with this piece falling into place before the week ended. I expected this would be the most difficult piece of the puzzle, and with it out of the way I can now focus back on the IAS issues that Microsoft PSS is still working on.

Have a great weekend! I know I intend to.

Anvil Web Service Screencast [Flash ~9MB]

Posted by Dana Epp at 06:08 PM | Permalink

Well, progress on Anvil has been slower than I would have liked this week. I seem to be tackling challenges that I wasn't quite prepared for. Its quite interesting problems which has made it enjoyable, if it wasn't for the pressures of the end of month coming up.

Microsoft PSS still doesn't have a solution for me. I am disappointed to see that the support guys aren't using virtualization for testing purposes. The engineer assigned to my case actually contacted me and said it may be a few days (and up to next week) as he has to build an SBS environment. WHAT?? I would think there is a working VPC image for every product they have. It should take no time at all to bring up an image to work with. Guess they aren't dogfooding their own VPC stuff for this kind of thing. Thats really to bad.

The AuthEngine stuff has also had some of its own challenges. The guys at CryptoCard have been working well with me to get this stuff working in .NET. They have written a new COM object that I can use so I don't have to PInvoke the C library. Problem is, they still have to document it and provide some tests, which means its been a bit hit and miss for me as I try to learn this stuff. On the flip side, I have rather enjoyed working with the guys over at CryptoCard as every time I come across something I don't understand, they are able to fill in the blanks for me with very little effort. Typically with internal documentation they have in hand from others who have come across these challenges.

So right now I am waiting for both Microsoft and CryptoCard to get back to me on some stuff. In the meantime, I am mindmapping the workflow process I expect to use for the deployment and enrollment of tokens to users when in the field. While talking with Cryptocard they have offered some interesting advice on what sort of difficulties they have seen in the field, and I am leveraging that information to make Anvil more user friendly... while meeting compliance needs of different market verticals.

Hopefully tomorrow will come with some solutions to these challenges so I can make some serious progress. This week has been killing my schedule.

Posted by Dana Epp at 03:02 PM | Permalink

... is to never have secrets to protect. Does that make sense?

So today I got an email from someone who challenged my post on using regular expressions for data validation on the PIN field in the Users table. His position isn't about the regex itself (which he liked), but the fact I was storing the PIN in the first place.

And he is right. I didn't really go into detail in that post, but I never designed the final Anvil database structure to actually store the PIN. This was actually one of the things exposed during the threat modeling process. There is no reason an administrator should ever know a user's PIN. So why let them see it? Why even store it? In Anvil, the PIN is not actually stored. A 32 byte MD5 hash is actually stored in the database, and a regex of ^[abcdef0-9]{32}$ is used as the data filter.

I am pleased that someone actually noticed this and pointed it out. It's a great lesson on why we shouldn't store secrets if we don't need to. The Token Validation Web Service takes the PIN inputed by the user, hashes it, and compares that hash to what is in the database. If it matches, then we have a valid PIN. No need to expose the PIN directly in the database.

While waiting for Microsoft PSS to get back to me on the IAS issue I am having, I am spending time working through the new AuthEngine COM object CryptoCard have designed to use with .NET. I should be able to add that to the web service in the next few days. Once that snaps in, a lot of things will fall into place.

Lets hope I can get the RADIUS side worked out with IAS soon.

Posted by Dana Epp at 05:57 PM | Permalink

Well, made SOME progress on the IAS issue. Had a developer from Redmond give me a call, and we quickly found out that one problem was the fact the Platform SDK build environment was mapping the C compiler to the VS2005 stuff (MSVCR80). One problem... the C runtime on SBS is for VS2003 (MSVCR71), except on R2, which we don't run here in any environment.

Running "depends.exe" quickly showed that the runtime was missing. So I copied the latest Platform SDK SetEnv.cmd script and altered it to force it to pick up the VS2003 C compiler. Voila. Now that side of things is working properly.

Of course, IAS still won't load the bloody DLL. *sigh*

Back in Microsoft's hands. Hopefully they will be able to figure it out tomorrow and give me a call.

Posted by Dana Epp at 05:45 PM | Permalink

So this morning I called Microsoft's Professional Support Services to look for help with my IAS extension problem on SBS. After 2 hours of being on hold with the networking group, it appears I have bounced around in the SBS group, the SDK group and finally now to the "Microsoft Development Team". And that requires someone to call me back in 24 to 48 hours. *sigh*

Meanwhile, for two hours I listened to 70s disco music, peppered with some country and weird early 80s music. I guess I shouldn't complain... as it could have been some Bollywood tunes that I wouldn't have quite understood.

All I want to do is load an extension DLL in IAS on SBS. Why is this so hard. *sigh*

Well, off to do some work on the web service while I wait.

Posted by Dana Epp at 11:10 AM | Permalink | Comments (1)

So it seems I came across a wall today. Trying to get an IAS extension to load in Internet Authentication Server (IAS) on SBS2003 seems to fail. A bunch of different issues ranging from permissions for EventLog access for IAS to the extension DLL code not even loading, I burnt a LOT of time today trying to get this working.

I did complete the code for the IAS extension framework though. That was a lot of good progress. I plan to ship a RADIUS test DLL for RWW-Guard later this week, once I get this deployment issue worked out. And thats an extra benefit for my RWW-Guard users during testing.

So whats next? It's not worth the expense to spend the next day or two trying to figure out this problem. Valuing my time, I will call Microsoft PSS and spend the money to get them to tell me why the heck IAS on SBS acts this way. Even using the default samples in the SDK seem to fail on SBS. No idea why. Hopefully they can help me figure it out so I can get back on track.

Posted by Dana Epp at 11:30 PM | Permalink | Comments (3)

I am so pleased with deciding to go with SQL Server 2005 Express for Anvil. I recently learned about an extremely powerful feature that makes data validation in the database a breeze.

Whenever you use input from an untrusted source, it needs to be validated. Especially if it comes from or can be accessed by the user. The best way to handle this is to put an input sentry at any trust boundary, as it crosses from an untrusted to trusted border. Ultimately, the last line of defense will be the database, as that is where the final storage ends up... at least for our application.

You can easily apply CHECK constraints on fields in the database. But that is a very rudimentary method of validating the input, since you can typically only do basic checks.

Enter the fact that in SQL Server 2005, you can now enable CLR in the database, and write user-based functions in your favorite .NET language. And more importantly, you can CALL these functions AS constraints on fields in the database.

This is really impressive stuff. In my case, I wrote a generic regular expression validation function that allows me to do the deepest of validation checks on the data before its inserted. If the data fails the regex validation, the record will not be committed.

I decided to screencast the authoring of this powerful regular expression validation method. Feel free to use it yourself on your SQL Server 2005 databases.

And remember... always assume that input is malicious until proven to be safe.

Anvil SQL Server Data Validation Screencast [Flash ~14MB]

Posted by Dana Epp at 12:20 PM | Permalink | Comments (2)

An important aspect of software development is managing bugs. You know, those defects that make the software work in unexpected ways, that the users don't expect. We all have bugs in our code. In the commercial world of today, it is impossible to design software this is 100% bug free and make it deliverable on time, and under budget.

There are plenty of different methods in tracking bugs. I used to be a fan of using Bugzilla... but a few years ago I became a customer of Fogcreek Software who make an excellent Defect Tracking System called FogBugz.

What makes FogBugz such a great product is in its design for simplicity. It is optimized to be the easiest and most efficient tool for managing the defect tracking process and case management in teams of any size. It cuts through the clutter and gets to the heart of the bug tracking process, while at the same time is easily leveraged to offer customer relationship management. You can use it to communicate with your customers, track feature requests, and ensure that vital communication is not lost.

While going through the project schedule today I had to set up FogBugz to support the Anvil project. I decided to screencast the process so you can see just how easy it is to use FogBugz, and talk a bit about how you can use it in small teams to reach unprecedented defect tracking prowess.

Anvil Defect Tracking Screencast [Flash ~16MB]

Posted by Dana Epp at 03:51 PM | Permalink | TrackBacks (1)

As I mentioned in the last post, I have been getting a bit behind as I came across a bit of problems with the threat modeling tool and other revenue generating work in the office needed to be taken care of. I believe I can make up some of the time next week, and that is in part due to the fact I manage my time rather well with a combination of project planning with mindmapping and respecting Rule 1440.

You don't know what rule 1440 is? It is the fact that you only have 1440 minutes in a day... and you should respect that and maximize the limited resource as best you can. It is so easy, especially with the Internet of today, to get distracted... or waste time in useless meetings and frivolous conversation. Rule 1440 puts it in perspective.

A balanced lifestyle means you can't let work consume you. Trust me. It took me years to learn that. You HAVE to have passion... and you MUST have a driven desire to succeed... but it doesn't mean you have to spend 16 hours a day in front of the computer every day of the year. An intense and productive 8 or 10 hours of work a day is much better than 16 hours of poor performance.

This is a common failure with most startups. They are consumed with their work... but are rather ineffective with their time. They FEEL they are giving all their time, energy and life to the project... when in reality they would be far better off focusing their efforts with PRODUCTIVE time which is balanced with life outside the office. A business is supposed to serve you... not the other way around. And more importantly... if you don't do this you need to ask if are you building a business that can grow and be executed by others, or are you creating a JOB for yourself where YOU are the company? If you ever expect to exit your business and profit from it... it has to have value MORE than just you.

To show you what a project schedule mindmap looks like, I have done a quick screencast to show what it looks like with MindManager.You will notice how things are broken down, and how we can track our progress with progress icons.

The weekend is here, which means my birthday has come. I am using the time to take my wife to go see The Phantom of the Opera (the one opera she has always wanted to see), and to visit some of my pilot friends at the Abbotsford Airshow. I also hope to catch the Snowbirds, my favorite precision acrobatics team in the world. See you next week!

Anvil Project Scheduling Mindmap Screencast [Flash ~2.5MB]

Posted by Dana Epp at 11:21 AM | Permalink | TrackBacks (3)

At the end of last week I mentioned that the next thing I was planning on doing was some data flow diagrams for Anvil. I decided instead of using Visio and following the typical drawing method that I would use Microsoft's latest version of their Threat Analysis and Modeling Tool. Doing so I get the benefits of Trust Flow Diagrams and Call Flow Diagrams. Problem was, I had to first complete the threat model before I would get the benefits of the diagrams.

At the same time, some other work in the office required my attention for a couple of days, which has made it difficult to keep up with my commitments with Anvil. A regular problem for small companies with over extended resource allocation. I hope I can make up some of that time next week.

During the process of threat modeling over the last couple of days I found a few bugs in the tool and some features I would really like to have that would have made the process easier. I have contacted the ACE team at Microsoft who are responsible for the tool and they are now aware of the bugs and my feature requests. I wouldn't be surprised if I see some fixes coming down the road shortly.

I completed a screencast showing an overview of how I use the tool, and how you too can benefit from it. I still have some work to do on the threat model tonight, but I wanted to make sure I recorded what was going on while I had a chance.

Anvil Threat Model Screencast [Flash ~16MB]

Posted by Dana Epp at 05:31 PM | Permalink | Comments (2) | TrackBacks (1)

Once the functionality mindmap was complete, I started digging deep into the Microsoft Developer Network (MSDN) to find the appropriate technology I want to use. I have been thinking about Anvil for the last couple of months and have had some ideas, even doing some preliminary research... but now is the time to put rubber to the road and make sure it will actually work together.

After writing some test code to make sure I understood how things worked together, I have quickly drawn up what the architecture looks like in Microsoft Journal, and then pasted it into my Functionality Mindmap. You can get a look at it in the screencast below.

The next step will be to build a set of data flow diagrams (DFD) based on this architecture so I can better understand the inputs, outputs and trust boundaries. I guess I will start working on that next week. Next Monday is a civic holiday here in British Columbia, so I plan to sit on the deck and enjoy the weather. Chances are, I will start drawing the DFD then.

Anvil Technology Map Screencast [Flash ~2MB]

Posted by Dana Epp at 03:05 PM | Permalink | TrackBacks (1)

There are a lot of great resources on the Internet about building software. One of my favorite insights happens to be from the 37 Signals blog. And that is that great software should be simple and intuitive, and can be built with small teams. Taken directly from their website:

We believe software is too complex. Too many features, too many buttons, too much to learn.

Amen.

So today I want to talk about the features that will be in Anvil, at least for version 1. While sitting in in Starbucks enjoying a Chai Latte, I have recorded a screencast on my TabletPC of me creating the first version of the functionality mindmap that I will use during the project. This will be used as the base when I start to schedule things and monitor the progress of the development.

From that mindmap, I will build some use case scenarios that I will later use in the threat model. I will have those done tonight or tomorrow. I also plan to work on deciding what technology I will use, and what the topology will look like. Chances are, tomorrow I will screencast the drawing and explanation of the technology mindmap.

Anvil Functionality Mindmap Screencast [Flash ~12MB]

Posted by Dana Epp at 01:25 PM | Permalink | TrackBacks (1)

So I have already talked about WHY its important to understand your customer's pain points. Now I am going to talk directly about my customers, and the pain they have.

At Scorpion Software our latest product that is currently going through final beta testing is RWW-Guard. RWW-Guard protects our customers and enhances their remote access security with the addition of two-factor authentication directly into Remote Web Workplace, a web based portal which gives businesses who run Microsoft's Small Business Server 2003 (SBS) web based access to their email, the corporate intranet, and even to their workstations and other servers at the office. Combining the standard RWW domain credentials with the use of one time password (OTP) from software and hardware tokens, we provide new assurance levels of who can access our customer's corporate resources remotely.

Its a feature may small business owners with sensitive information assets that run SBS have always wanted. I even wanted it myself. In our office, we spent around $1000 implementing an extra layer of security with a Sonicwall firewall and the CryptoCard strong authentication server to get something that works similarly to RWW-Guard, but with extra technical hurdles that were sometimes cumbersome, and definitely not intuitive to my employees.

With RWW-Guard, you can use any strong authentication server that supports RADIUS to offer two-factor auth. That includes players like CryptoCard, RSA, Verisign, SecureComputing and Authenex. When personally asked which strong auth server we prefer for the RWW-Guard beta, we normally recommend CryptoCard or a dedicated RSA SecurID appliance. And here lies some problems. MOST strong auth solutions are just too expensive for small business. If you have the need for only a few remote users with strong auth, you STILL have to spend thousands of dollars to implement the solution, with wasted tokens sitting at the office that aren't used. An RSA appliance runs anywhere between $2500 and $5000, depending on the number of tokens needed and the implementation costs. CryptoCard's CryptoServer is much less expensive, but has the drawback that it is UNSUPPORTED on SBS 2003. I have it working in our office, but MOST of my beta testers couldn't get it to work. The combination of TomCat, a Java server and a MySQL database with ISA was just too resource demanding and complex for most SBS environments.

This quickly became a problem for both our customers and us. We have all these people WANTING RWW-Guard but who are having some difficulties deciding on what strong auth server to purchase. These customers are in extreme pain in trying to find an inexpensive solution that just works in their Windows environment, and we saw this as an opportunity.

So I contacted CryptoCard and explained the problem. And together, our companies decided that it would be more effective to build a strong authentication server for small business. Walla... Anvil is born. After deciding we COULD build the solution, I went and interviewed 25 potential customers directly. The idea was to make sure they would actually spend money on such a solution. I now have 5 pre-orders, and another 15 potential sales in the pipeline if I actually pull it off and show it to them. Only 5 of the people I interviewed said they wouldn't pay for the solution. When pressured to find out why, it ends up they just don't feel the risks to their business are worth the investment. I will note that a majority of those businesses are barely getting anything out of their SBS investment yet. I will go revisit them around Christmas and see if their attitudes change.

So with the cooperation and support from Cryptocard, Anvil will be a strong authentication server for small business. It is being built directly on the Windows stack, and will be built to natively support SBS 2003. We have an agreement with Cryptocard to purchase their KT1 key fob tokens and have gained access to their authentication engine, which means we don't even have to build our own. We can focus on building the right strong authentication solution for OUR customers, to solve THEIR pain point. And that is an inexpensive strong authentication server that "just works" on the Windows platform natively. No complex and cumbersome settings. Oh, did I mention it will "just work" with RWW-Guard at the same time? And scale up to larger businesses who are running Windows Server 2003?

So whats next? Well now that we know what pain points Anvil will solve, we need to decide on the scope and feature set of version 1. During my interview with the potential customers, I asked them what they would want. Tomorrow, I will talk about that as we brainstorm the features and start putting it together in a mindmap.

Posted by Dana Epp at 01:14 PM | Permalink

In various books, articles and writings on building a software business you may hear from time to time that for small businesses, you should find a pain YOU have and solve that. The theory is that if you have the pain and can solve it, you will have a great product others will want to buy.

I hate to tell you this, but that's false. Well, more to the point, its an incomplete thought. What really should be said is that you need to find a pain point you have that many other potential customers ALSO have; and the size of that market will be a gage to determine if there is a real business opportunity for you or not.

Think about it for a second. If you were a colour blind coder with only your right hand, it might make sense to make software to make your life easier. But if you wanted to make money at it, how many colour blind, right handed people are out there that can really use your product? Not too many. So you either have to have something amazing you can charge a small group of people a lot of money for, or consider that perhaps its not a good business opportunity to pursue. You definitely will NOT make it up in volume.

So when looking at what sort of project you may want to work on, you need to be looking at your CUSTOMER'S pain. You should be looking for pain points where the customer would be more than happy to throw money at you if you can solve their problem. And if you find the right pain point, it will hopefully have a substantive market size so that you can benefit from that. At the same time though, its important that this pain point be strong enough that people are willing to pay for a solution. If it just annoys them, or they are willing to live with it, its much more difficult to determine if a market exists or not for the product.

As a small software company I also look for another key element in determining project feasibility that I want you to consider. Does the project fit in a scalable vertical where you can OWN or DOMINATE it? I would rather be the #1 software company in a specific market segment than the #10 one in a wide market, even if that market is 20 times the size of mine. Why? At some point you will want to differentiate your business from the others, and focus your limited marketing and sales resources where you can get the best returns. Fishing in a big lake with 50 other anglers is much more difficult that having a small pond all to yourself. That means you have the potential to "catch" more, and in the end that means you may make more money. Of course, its also nice since you don't have big software companies coming in to compete with you. It's typically not worth their time. Where you and I may think 1 or 2 million in revenue potential is nice for an opportunity, someone like Microsoft or IBM may feel its just not worth their time. And that is a great opportunity for you.

So why am I telling you all this? Because in the next post, I am going to talk about MY customers, and their pain points so you can see why "Project Anvil" is something I believe is important, at least to Scorpion Software. Understanding your customers and their pain can go a long way to building a healthy relationship, which will in turn net you more revenue potential.

And before worrying about writing a single line of code, we need to know that its worth our time to do so.

Posted by Dana Epp at 10:26 AM | Permalink