May 2003 - Posts
Paul Gielens blogged about a possible misunderstanding about the term 'Entity'. Reading his text it appears as if the general term 'Entity' has changed recently. The reason: Eric Evans created a different definition. Let me be blunt here: if a definition of a general group of knowledge is known for years by a given term, do not use that term to extend that definition so it will cause misinterpretations between people thinking they are talking about the same definition. The term here is 'Entity', and it is defined for a long time, firstly by Peter Chen if I'm correctly informed, in his article 'The Entity-Relationship Model', ACM Transactions on Database Systems vol.1 nr.1 (March 1976), and his book 'The Entity-Relationship Approach to Logical Database Design' - Wellesley, Mass.: Q.E.D. Information Sciences, 1977.
Chen's work is about a model to design databases, the Entity-Relationship model, in short the E/R model. As you can see, this model is rather old, more than 25 years, and is replaced later by the work of prof. G.M. Nijssen and prof. T.A. Halpin (Conceptional Schema and Relational Database Design, 1989) by their work on the NIAM modelling methodology, later renamed to ORM and extended by prof. T.A. Halpin. (read more about ORM here)
The cornerstone of Chen's work and also of the work of Halpin and Nijssen, is the 'Object type' or 'Entity'. Edward Yourdon describes in his work Modern Structured Analysis, Prentice Hall 1989 the usage of Entity Relationship diagrams. While, as prof. Halpin describes in his overview on ORM, E/R models/diagrams lack information about context and constraints, the concept of Entity is not changed. Yourdon describes the concept of Entity as follows:
An entity in an E/R model has three properties:
- Each representation of an entity can uniquely be identified
- Each representation of an entity is playing an important role in the system it lives in. (it has to have a reason to be there)
- Each representation of an entity can be described by one or more attributes (data-elements, like name, age, quantity)
There is no mentioning of logic in this definition, nor in f.e. the context of ORM/NIAM. The latter is logical since an ORM or NIAM model can be transformed to an E/R model, as Visio for Visual Studio.NET Enterprise Architects shows (for the people who are not familiar with NIAM or ORM).
Using this generic definition has great benefits. In a team, which has to implement a given set of functionality, team members can rely on the fact that when the database-oriented team members are talking about entities in their ORM/NIAM models, they talk about the same thing as when a middle-tier programmer of the team is talking about an entity. The definition is clear, well-known and usable by a large group of developers and software architects, even project leads.
Paul writes: In the OOP world entities are considered an abstract continuity through a lifecycle and even multiple forms. Objects not primarily defined by their attributes, but a thread of identity that runs through time and often across distinct representations. Entities have special model and design considerations. They can radically change their form and content, while the thread of continuity must be maintained. For entities to establish their relation with other object they encapsulate operations. On the other hand object with no conceptual identity, objects describing some characteristics of a thing are value objects. Within the context of value objects, instantiation isn’t a big deal (except for distributed systems, fine grained objects drown performance).
Now, the concept of 'Entity' described by Paul here (refering to Eric Evans) is not the same as the entity definition known for over 25 years. This leads to serious misinterpretations among software developers and software architects which will run the risk to talk about different things while they do not realise that. I really do not see why Fowler re-defined the definition of 'Entity' in such a way that his definition is not the same as the old definition used by Chen and others and therefor is not applicable to the older E/R model concept, which is still used by Visio 2003 to generate a database DDL script from an ORM model.
It's also unnecessary, since the concept of 'entity' as it is defined by Chen and others is perfectly usable in an OO world: you add logic to the entity, the logic isn't part of the entity, since the logic isn't saved in the persistent storage, however the entity is. To see this, consider a database which is used by multiple applications: an internal accounting system, a webapplication and f.e. a webservice exposed on an extranet. The entities are always the same in all the applications, they use the definitions of the persistent storage. The reason for this is that the database is designed by an E/R model or ORM model, and therefor is the physical representation of an abstract model which defines the entities and the relations between these entities.
Software architects designing the applications working with that database model can design the software using the same entities and know the entities they use are correct and available in the persistent storage. At any given time, a developer can grab the abstract database model and can see how the entities relate to each other, what their context is, which constraints are applied, etc. It's this power that makes the concept of the entity that is applicable both in DDL and f.e. in an OO model a valuable tool to write and design good, solid, working software. A definition which is only valid in the OO world can't, simply because it's not applicable to the persistent storage and there is no abstract model defined like an ORM model.
It would be nice if writers of IT books wouldn't re-invent definitions known by millions of developers and software architects worldwide for many years, there is already enough confusion in our industry, we do not need more.
(updated: I interpreted Paul's text as a reference to Fowler, which is a reference to Evans.)
You might have heared about the DAL generator I released last year, LLBLGen, which as a surprise to me, became a worldwide success (over 25,000 downloads). I'm currently busy developing its big brother LLBLGen Pro, which should be released later this summer. As a quick update on what this successor is capable of, some lines of example code which uses some generated code (entities, collections) that is produced with an alpha version of LLBLGen Pro.
It loads a collection of entity objects (that's right, normal entity classes) of the type OrderDetail, from the Northwind database, which contain references to the product with ID '24', binds it using databinding to a datagrid in a form, which allows full editing of the OrderDetail objects, and after that, all changed objects are saved using an embedded transaction to the persistent storage using a single line of code. I think it's pretty neat :) Of course this is one of the many ways to retrieve / construct entity objects using the O/R mapper code generated by LLBLGen Pro. More updates later on.
OrderDetailCollection collection = new OrderDetailCollection();
ProductEntity product = new ProductEntity(24);
// ...
collection.GetMulti(null, product);
DatabindTester dbtester = new DatabindTester();
dbtester.OrderDetailEntities = collection;
dbtester.ShowDialog();
// ...
// in the dialog:
public OrderDetailCollection OrderDetailEntities
{
get { return _orderDetailEntities; }
set
{
_orderDetailEntities = value;
binderGrid.DataSource = _orderDetailEntities;
}
}
private void saveButton_Click(object sender, System.EventArgs e)
{
_orderDetailEntities.SaveMulti();
}
All queries are generated dynamicly, all code is using several patterns like the DAO pattern and the strategy pattern. Everything is developed internally using interfaces.
I'm now working for a week or so with VS.NET 2003 and it has some neat features that version 2002 didn't have which are, well, neat to have, but also started me thinking why they are implemented the way they are and why there is so much ground left untouched. Below I've formulated some wishes for the next version of Visual Studio.NET (2004?), and as with every wish-list, I hope the wishes come true, or better: what's wished for is a bad example of a short sighted vision of how reality should be and the next version of VS.NET (2004?) will prove that :)
Compilation (C#)
- Full error harvesting during compile pass. I work with C#, and what I learned during my study CS was that a compiler should recover from an error and should continue with finding errors as best as it can. The current C# compiler fails in this area. F.e. if you make a typo in the name of a local variable and you do that twice or more in the same local scope, the compiler will only find the first error. This is also true for type mismatches, thus using the same variable twice in a wrong way will enlist 1 error, so you fix it (it's monday morning, your head isn't that clear and focussed) and recompile and see a similar error but 2 lines below it (or in the same line). If the compiler finds all errors at once, you can fix them in one go and do not have to recompile a lot. (on the fly error-checking would be even better, but that is performance intensive)
- If one assembly is build and it fails, do not compile related assemblies as well. When you have a solution with more than 1 project, and you want to rebuild a given project that is referenced in another project (using the 'rebuild' option in Visual Studio) and the rebuild fails, you'll also see errors in the project(s) referencing the project you just build. This can be very annoying, and is unnecessary since you didn't want to rebuild the other projects. It's also weird because if the build succeeds, you will not see any errors found in referencing projects, as if the re-compile of those other projects is not done when a rebuild of a single project succeeds.
Editor (C# / general)
- Persistent bookmarks. Now the bookmarks you set in a file are gone the moment you close the file in the editor, which makes the concept of bookmarks not that useful.
- Persistent outline folding. Now all regions (outlining) are collapsed or expanded when a file with outlining is loaded (depending on the settings) and the folding is not persisted when you close the file. This can be annoying when you have a private members region and a properties region. Both are collapsed when loaded but you sometimes want to keep open the private member variable region when you are working on a class.
- Interface stubbing should be more enhanced. The feature to stub out a complete interface is a time-saver at first but when you use it for a while it isn't much useful when you use it for your own interfaces. The reason for this is that you have to copy over your xml comments from the interface definition to the stubbed out versions, which can be time consuming. It's then faster to just copy the complete definition of the interface and add public/protected statements and a simple body. The stubber should copy, when possible, the xml comments from the interface definition, so the stubbed out code is more useful. Also, it is now placed in its own region. What if you do not want that? It would be nice to have a certain amount of configuration settings for these kind of features, like the interface stubber.
- Give 'smart indenting' a better brain. Although smart-indenting is a little smarter than 'block indenting', it has some weird issues. For example, if you hit enter twice when you are at the end of a line, you are 2 lines below the line you typed, indented. Now hit cursor-up. The cursor is all the way to the left, at the start of the line. If you want to add something there, you either have to hit enter again, start typing, erase the line above it, or hit tab a few times. This is odd because when you hit enter for the first time during that twice-hit session, the cursor was on that line, indented, so where are these tabs all of a sudden? Another nasty habit of this indenter is the fact that it gets confused with switch statements rather fast and adds a tab too many. A last thing that would be very handy (and VB.NET users have this for a long time) is the automatically insertion of start/stop braces when you complete an if expression or for expression or other statement that is the start of a block, a local scope.
- Automatically stubbing of the base class' abstract methods/properties. The override stubber is nice, but as you have to implement abstract methods of the base class you inherit from, it would be nice to have a stubber like the interface stubber, and then with xml comment insertion as well :)
- Better organization of winforms generated code. When you are designing your GUI in the form designer, it will generate code for you in the code file of the form class. This code is randomly placed in your own code it seems. It creates one region where the form initializing code is stored, however the form's dispose method is not placed in that region, and most of the time you definitely do not need that routine. It would be nice if that routine was placed in the generated region as well. Also, the definitions of the controls are placed where your own private member variables are declared as well. Even if you create 2 regions for that the form designer will sometimes place new controls in the wrong region. It would be nice if you can define a region where the generated code is placed so you'll see the code you have typed yourself and are not confronted with the generated code.
- Property getter/setter generator. Everyone who has worked with the VB6 class generator knows that it had a great property add feature which generated both member variables and get/set properties for these members. VS.NET still lacks this feature, or better: it lacks a feature that lets you add properties fast. I now use QuickCode, it helps, but it is still slower than the VB6 property generator.
- More fine-grained settings for editor customization. If you check out the option dialogs in Visual Studio.NET you'll see different options for the different language editors. Now, I can imagine the average C++ developer is focussed on other things than the average VB.NET developer, but why are some features available in some language editors while they are non-existent in other language editors? F.e. the C++ editor lacks some options that are present in the C# editor. If you, as a C++ developer, and you would have these settings and you do not want them, you can switch them off, but if you do want them, you can switch them on. Now you can't. It also bugs me why the editors do not have more settings for tweaking the editor more so it behaves like you want. It's a tool a developer uses for a long period of time during a day, so having more options to make the editor work they way the developer wants is only an advantage. An individual developer is not helped with an "surveys showed us that this is what most developers wanted"-explanation.
- Build a new ASP.NET editor. I don't know if Matrix will turn out to be the next ASP.NET editor, but the current one in Visual Studio.NET has some serious issues, while competing products like Dreamweaver do not have them. A new, better anticipating editor is necessary, an editor who knows what kind of content is edited.
IDE in general
- Refactoring tools. Every self-proclaimed good Java IDE has them: refactoring tools. VS.NET has just one, a search/replace tool (although it is rather good). At first I wasn't that in favor for refactoring tools because they imply an ad-hoc coding style. But since I use an ad-hoc coding style while writing my O/R framework (because remodelling of code is necessary a lot during OO development, you'll never get it right the first time), I miss refactoring tools a lot. Even a small set of tools would be a good start. Buying a 3rd party plug-in is an option but you don't pay top dollar for an IDE that requires you to invest even more money to make it complete.
- Multi-row tabs. I sometimes have a lot of tabs open in the IDE, 15 or more. Flipping through them is a pain, why didn't MS include a multi-row tab control for those tabs?
- A faster debugger. I work on a P3-933 with 384MB of Ram and XP. I know the machine is a little dated, but when your solution gets bigger and bigger and you want to debug an assembly and want to step through some code while having open a tree of local variables, it gets really really slow, even in VS.NET 2003. I sometimes see member variables change in the Locals view 2 seconds after the step over was completed. VS.NET 2003 is a little faster, but it also makes mistakes in enum int to enum text conversions sometimes, i.e. the snapshot of the state of an object shown in the debugger's Locals window is not reflecting the real state of the object. Perhaps this is a result of the performance enhancements, but it makes debugging more time consuming this way.
- Make editor tabs slideable to the side like f.e. the solution explorer. You can't semi-hide an editor tab to a small tabstrip at the side of the tab area for later usage, you have to close the tab and open it later.
- The help tab should be special. In VS.NET 2003, the help isn't displayed on the start page tab, but on another tab. When you flip through the editor tabs with cntrl-tab, you also come across the help tab. This shouldn't be the case. When editing code, the help tab is for assistance, it isn't part of the editing process.
- Make source control truly integrated. At the moment when renaming a file when this file is under sourcecontrol controlled by Sourcesafe, the rename is not reflected in Sourcesafe itself. Instead, a new file is added, which will cause cluttering in Sourcesafe itself plus you'll loose history information on the file because that information is still stored with the file with the old name. It should be possible to select an option to make these changes also be propagated to Sourcesafe, if you want. There are other caveats with Sourcesafe, the one I encounter the most is this lack of true integration. Overall I think a sourcecontrol system which is more focussed on heavy multi-user development is a must.
*Pfew* :) Of course there are more features to wish for and there are perhaps features I wish for which are not beneficial to others. If you have more features you want to see in the next Visual Studio.NET, enlist them in a blog so MS gets notified and perhaps the next version of VS.NET will include all this with all the stuff we already know it will contain, like generics :)
I saw several "Is IE dead?" blogs and most recently DonXML's blog about this subject and I really think this discussion is not focussing on the real issue.
What's the problem with current browsers? It's not that they can't render version ABC of a given HTML, XML or XSLT variant. The problem is that they are used as application-GUI hosts while they are intended to be used as stateless viewers of information. Through an evolutionary process, Andreessen's tool to view hyperlinked texts has become an interactive viewer of a GUI for applications but still does that using the same old techniques. Which is a result of the way HTML works, and all mark-up languages in that respect.
I read all kinds of thoughts how and why IE should evolve but it really shouldn't. It should be put to rest, and the focus should be moved to an application which is already at our desktop: the CLR itself. It's a waste of energy when you are trying to re-invent the wheel that is already available: winforms. The majority of web-applications use cumbersome HTML-forms to try to build a workable GUI, while a winforms developer can do that with ease using the winforms glyphs and controls. If there was a way to run a GUI using winforms on the desktop of the website visitor, you can build a rich and powerful GUI with common technology which doesn't suffer from the fact that there is no scripting available, all HTML form glyphs are text based and other nasties related to HTML (or XHTML for that matter) which are totally avoidable when you use a decent GUI framework, like winforms.
I've been developing websites and webapplications since 1994 (ah, those good ol' days without images on pages) and I never understood why on earth a browser is used to host a rich GUI, because HTML is not meant for that, it lacks serious building blocks available in every GUI toolkit on the planet (even the console library Cursus has them!). Trying to keep it alive for webapplication GUI's is not the way IE should be evolved, IMHO.
The problem is platform independence. When Mono sees the light of day, a CLR with decent winforms is available everywhere. It should then be possible to run any decent winforms GUI frontend for any webapplication out there on every decent system and OS. IE as an application is then not needed anymore, the browser is then obsolete.
HTML, or its markup successor, will not go away of course. It will be rendered by components embedded in other applications, like helpviewer, blog readers and other tools. Such a component can be embedded in winforms as well, as a control.
The concept of the 'browser' is a concept of the past. Let it rest, let it die in peace, it's about time users move on to richer environments and technologies which truly connect user with application, no matter what type of connection (local system pipe/lan/wan/Internet via modem/ADSL/WiFi, you name it) is used and whatever flavor of browser and client side settings.
Yesterday, the Firebird team released their .NET provider for the Open Source database Firebird (based on the Interbase code). The provider is also open source and of course free. I haven't played with the Firebird database recently but according to the features Interbase had and looking at what the Firebird team added / updated in the source code, it is a massive alternative for those developers who need a true RDBMS with ACID compliance throughout the system and full stored procedure and trigger support but can't afford SqlServer (or alternatives which cost even more money).
The links:
Firebird works on a flavor of operating systems including windows.
A quick note on the Hungarian Notation/Coding blog I wrote this morning and which was food for some good replies from Patrick and Chad. I now am a full day clean, that is, no Hungarian Notated member variable or parameter left my fingertips. The arguments I had this morning, about the naming problems of some parameters I had and the prefixing of private member variables, were not that hard to overcome.
As mentioned in the comments and also by Chad's clear posting, I totally forgot the 'this' statement in my arguments, which is my own fault, I never use 'this' (due to HN), and it didn't occur to me. 'this' however is a good statement for non-HN style development, you can totally abandon the prefixing, if you feel you have to. The naming problems I had also occurred with class name clashes and parameters which suddenly had similar names (the class name PasCal cased, the parameter caMel cased), so I had to come up with new names for these parameters, and at first I thought this was a disadvantage, but it turned out quite OK, re-thinking your names for parameters is good, you come up with better ones over time, and in the end the result was much better than I expected in the beginning.
Now if I only could find that phone-number for that AA-meeting for ex-HN coders...;)
Today, is a memorable day for me. This morning I had to bite the bullet: get rid of my Hungarian Coding style in C#. Not because I hate Hungarian Coding, on the contrary: I love it, but because I have to. The reason for this is that when you want to sell a library which targets .NET, you simply can't feed your customers a library with interfaces which use input parameters like cmdCommandToExecute or efEntityField. I did convince myself when I started this project, it was my code and I should decide how the interfaces looked like. But this is just plain stubbornness. A customer doesn't give a you-know-what about the zillion + 1 reasons you can bring to the table why you had to make the interfaces of the classes inconsistent with the rest of the classes used in the application (f.e. the .NET classes).
Does it hurt? Well, a little. I'm still convinced Hungarian Coding is necessary. F.e. I had an input parameter 'iOperator'. You can't change that to 'operator' because that's a reserved keyword. So you have to come up with another name for a parameter that's perfectly described with 'operator'. Member prefixing is another advantage, however you can also have that with your caMel cased members, f.e. by using a '_' prefix. Microsoft avoided every guideline for private member variable naming, and if I have to guess I think the reason for this is that with a prefix you can use the same name for a member and a parameter which supplies the value for the member in a constructor or method, without forcing you to come up with 2 names for the same value.
I'll miss it though, as I missed my own scheme when I switched to Hungarian Coding back in 1995 (doing C++ work is driving you towards Hungarian Coding, like C# is driving you to PasCal /caMel casing). I already fear the Cold Turkey syndrome I expect when I re-read my own code without a type prefix in sight. *iShiver*
Which concurrency control method do you use most of the time? "First Save Wins" ? (optimistic locking in ADO.NET) "Last Save Wins" ? (Overwrite the row, no matter what). Ever wondered what the difference between the two is when it comes to efficiency? Most people haven't and think "Last Save Wins" is BadTM and "First Save Wins" is GoodTM. But both make at least one person loose his work to preserve the work of another person. I read a thread today in the microsoft.public.dotnet.framework.adonet newsgroup where one person asked how he could make the SQL generator in Visual Studio.NET to use the Last Save Wins method and another person stepped in and bashed him for using a not very smart concurrency control method like Last Save Wins. But does it matter which one you pick when both are as inefficient as you can possibly make them to be (i.e. someone looses work) ?
What is a concurrency control method?
A concurrency control method is a method to regulate multiple requests (transactions if you will) for modification of a shared resource, for example a source file in a source control system or a table row in a database. Several different methods are known and each have their pro's and con's. Not all methods are usable in all areas of software development: the concurrency control methods often used in source control systems (if conflict then merge) is not usable most of the time in a database world. However, when there are more than a few methods, which one is the best? To answer that question, we first have to define what 'best' means in this context. Let's see why we should think about using a concurrency control method in the first place to formulate our answer.
Most developers just write the software they have to write and focus on a single user using the software, interacting f.e. with a shared resource, probably a database. When multiple users reference and modify data in a shared resource, the resource manager (f.e. SqlServer or Oracle) should take care of the issues related to the multiple transactions accessing the same table or row, or at least that's how a lot of developers think. In a way this is understandable because the developer is a user of the resource manager, and the resource manager should have that kind of functionality, right? Well, in a way it should but if it does have it, do you want the functionality in the way it is provided to you?
A simple example of a common problem: Joe and Jack want to modify the same row in a database. They do that using the same tool. Joe starts the functionality to edit the specific row and starts working on it. Jack opens the functionality a little later, but because he's the quicker thinker he beats Joe in completing the modifications and saves his work to the database first. When Jack is done editing the specific row, Joe finally completes his modifications of the same row and saves is work too.
Now... what should happen?
- Joe should be able to overwrite Jack's data. Jack looses his work. (Last Save Wins)
- Jack's work should be preserved, Joe shouldn't be able to save his work and thus looses his work. (First Save Wins)
Though call. If you like Joe, you probably would opt for option 1, if you like Jack you obviously opt for option 2 and if you are their boss, you should look for another tool because this one makes you loose money: the used application has a not so clever concurrency control mechanism implemented: more than one person can edit the same data. If the tool had option 1. implemented, the loss of Jack's data gets unnoticed, which can be very bad. If the tool had option 2. implemented, the loss of Joe's data is notified at the end of a modification process, like "Thanks for the work you've done, pal, but I can't use it. Throw it away and count to 10.".
Besides the emotional stress this can bring (this is no joke, there are applications who have screens which require 10 or more minutes to complete and at the end the user gets a notification that it was all for nothing because he can't save the work due to a nice concurrency control mechanism), the time spend by Joe on the useless modifications can be spend better. Both methods are inefficient: always at least one person looses time and work. Other known methods, like 2-phase locking (2PL / Strict 2PL), Multi-version-concurrency-control (MVCC in Oracle), other database-locking variants, they all cause the loss of work at the end of a workflow cycle, when the work performed is stored.
So there is no best method?
If you focus on the resources in the database and use low level methods to prevent multiple changes on a shared resource on that low level in the application stack, there is no best method: all are causing the loss of work in some form. The only true method that works is the method of good organization and an application which helps you with that, sometimes called Functionality Locking. In the example above, Joe and Jack are both modifying the same row. If you didn't wonder "Why?", start this article at the top and re-read it. If you did, you are on the right track. You see, the less concurrency you create in your application, the less problems it will bring. If Jack, who starts later with the same functionality, isn't able to start the editor for editing the same datarow, because Joe is already busy with the row, he can do something else with his time, because the modifications he has to make will or be lost or will cause that someone else looses his work.
It would be better if Jack then would be notified that a user "Joe" was already working on that row, which then would enlighten an inefficient way of working in the organization, which is fixed by transferring the work Jack had planned for that datarow to Joe, because he's working on that row already. This can be implemented with a common gateway, today we call them webservice. A common gateway to your shared functionality among users can control functionality locking for one application and also for more applications who want to modify the same shared resource.
So, every time you write code to pop up a window to notify the user he can't save his work because another user has already modified the rows he tries to overwrite, ask yourself this: "wouldn't it be better to notify the user before he started working on that rows?". Software is not created to keep us busy (ok, some is ;)), it is created (or better: should be created) for making processes more efficient and thus organizations which have a lot of such processes should perform more efficient. Software which tosses away even a fraction of the work done by a single employee because some other employee has done the same already, is inefficient and should be replaced, since it doesn't help the processes be more efficient, on the contrary, software should help the organization with the implementation of more efficient ways to perform the processes encountered in the organization.
On May 20, HP regained the TPC-C performance crown for non-clustered (you know, "Big Iron") , using Microsoft Windows server 2003 Datacenter Edition and SqlServer 2000 Enterprise Edition 64-bit. It almost also nailed the clustered (you know, "Little Iron") record, also HP/Windows/SqlServer, result which was submitted September 2001. A stunning 707,102 transactions per minute were clocked on this beast with 64 Itanium 2 processors.
And who was that little fellow who said Microsoft's products do not scale well? :)
Yesterday I blogged about a problem ISV's can run into when they are selling .NET class libraries compiled with Visual Studio.NET 2003 to customers using Visual Studio.NET 2002. Today I've found a solution, which seems to be used by other ISV's already, and which solves the problem which caused me to post my rant yesterday. Below I'll first describe in a few words the exact definition of the problem and then the solution which works without any problem for your customers. After that I'll enlighten a bit the things you have to keep an eye on when implementing this technique.
To read the complete article, click here
(It's stored as a story because it's quite long)
More Posts
Next page »