| Home |  GO TO THE BLOG |
Downloads | Forum | Questions & Answers | Tiny Marbles Documentation |
Our Philosophy | why Tiny Marbles?
- Improved communication |
- Plan what really needs planning |
- Learn as you go |
- Publish as soon as possible
1. Improved communication
Many people take part on a software project and each should bring what they can do best to the table. Developers are smart too, so they can and should be in charge of the data modelling. They must be able to experiment and constantly improve the system. What better place to facilitate the communication between developers than at code level? Tiny Marbles improves code readability by hiding away persistence logic, so that the important code deals mostly with business logic. When the code reflects the author's intention, someone else can quickly understand it, learn from it and talk about it.
It can improve communication to non-developers as well. When people are more important than tools, new ideas – as well as misunderstanding and corrections – should be quickly incorporated into the current system, tested and talked about.
- Technical Details
- Transaction management is usually full of boilerplate code and special error handling for exceptions. We don't want developers to deal with that. Instead, we built a clever API that handles most of the work for you. Transactions begin automatically when you access the repository. After you change the repository contents, you call commit(); need to read more stuff after commit is issued? Do it! When you're done reading or writing or both, you call close(). If something bad happens, you will get an exception, of course. The good thing is, all neecessary transaction and resource clean-up is done automatically for you, so you don't mix error handling code with code that implements business logic. We also go great lengths to provide a very flexible and expressive querying syntax that reads almost like english. When talking to other developers, it's nice to be able to quickly figure out what a big query does.
2. Plan what really needs planning
We believe customers, managers and developers should spend their time planning the essential part of the application: business logic and user interaction. Often it is too soon or too difficult to make the right decision about things such as database configuration, transaction interceptors and other things not related to the application funcionality. User interaction modeling is hard in itself. Tiny Marbles allows fast, easy and constant change of the data model to reflect changes in the user stories.
- Technical Details
- What Marbles provides is an object repository that sits on top of the database and can be manipulated using regular Java code. You can define small pieces of your data model and start working on the business logic right away, experimenting and changing the UI. When you apply changes to the data model, you don't loose any data previously entered. We have focused on the simplest possible data model one would need. You define one persistent type for each business entity the system might have, and you can add attributes to a type at runtime (e.g. when the application starts, using a script, etc). The relationships between different entities are ordinary attributes too. This is all you need for most of the data models out there. All that would be useless if we didn't have an expressive querying mechanism that lets you retrieve your data quickly and easily. Tiny Marbles offers that too. Moreover, the easy handling of database transactions gives us freedom to experiment with different user stories and merge business logic from different actions without rewriting boilerplate code over and over again.
3. Learn as you go
The architecture of Tiny Marbles isolates the small parts of the data model called business entities. It's helpful when you want to try new ideas, see if they work, then remove or adopt them without loosing the data you already have. You can continue to change the model even after the application went into production, acquiring users and learning as you go forward. All the time you will have a real application to talk about: to discuss with developers, to ask for feedback, to show your users.
- Technical Details
- Your business entities are not Java Objects, they only have data and relationships. Also, there is no inheritance, so the dependencies between different entities are minimal. You evolve the data model using the same API you use for normal operation – it can be done anywhere. You can start a Beanshell script that connects to the database and concurrently modifies the data model. We normally write the business logic using the Command pattern to isolate each user interaction, so that new code can be added without breaking the existing logic so often.
4. Publish as soon as possible
We believe that user interactions are hard to get right the first time. We also want to write applications that can be deployed and tested very soon, with real users, so you can get good feedback. Especially performance optimizations can be done properly only after you have seen real usage. We like to release something fast and keep the door open for changes. Prototyping on top of Tiny Marbles instead a more rigid infrastructure can make a big difference.
- Technical Details
- Imagine this: transaction demarcation is not a problem; code readability is a matter of programmer quality; the data model can be changed at any time; and you don't loose any data when you make these changes. This is only possible because Tiny Marbles uses a fixed database schema. We call it our metamodel and it's defined using regular Hibernate mappings. We are sitting on the shoulders of giants. This way, if you find a bottleneck in your application, you can rewrite part of the model using POJOs and Hibernate mappings, then write highly customized code that handles your bottleneck. In other words, spending your top energy and skill where it's really needed.
Please send us comments, questions, criticism:
Please send us comments, questions, criticism!
