Now that I have a foundation for the Clay project's release roadmap, I'll starting filling in some plans the milestones will hopefully implement. Clay 1.0 is mainly a cornerstone release, not a lot of new features will be added between now and then. It's missing a lot of features I have been wanting to add, but most of those are applications that will be worked in through the regular release cycles.
Here's the unofficial breakdown of changes to come:
- 1.0 - Between now and the August 1.0 release, I'm mainly plan to tackle documentation and making Clay easier to learn.
- 1.1 - By December I'd like to have some key features built in that are lacking from the Core, such as hooks and interactions between applications. I also plan to have more applications and themes included in the regular release.
- 1.5 - This release, planned for February '14, will include a built in development environment and focus on completing the 1.0 series.
- The last major release of 1.x, releases working toward 2.0 begin here.
- 1.6 - The first release toward 2.0, a new application object and working toward generation applications from within Clay's built in development environment.
I've created a Google Doc containing the Clay Development Roadmap. It can be viewed here:
It's still a work in progress...
I'm in the process of putting together a roadmap for regular Clay releases. I think having a public release schedule will provide enough motivation to work on it more frequently than I have, with possibly fewer gaps in development, Lately I haven't been able to work on Clay a lot, but I should be able to now that things are settling down for a little while. There's a lot of work to be done toward an official site and things like that, so most likely the initial releases will just be posted here and on GitHub, but I may surprise myself and get Clay-Project.com up earlier.
Right now I'm looking at a June alpha followed up with a beta close behind. From there out it will be mostly beta releases with sporatic alpha versions, depending on the code state and the kind of changes being implemented. I plan to do a full version update once a year, with a 0.5 increment every 6 months. Stable releases will be released quarterly, along with a schedule for the following quarter's beta releases.
The part I'm trying to figure out is mainly the increments between x.5 and xx.0. The x.5 release will be a final release for x.x, with x.6 being the beginning of the roadmap toward xx.0. It's kind of confusing, but the purpose is to maintain x.5 as stable and move on toward xx.0 on a regular release cycle. For instance, 1.5's repo would be cloned into 2.0 and the development would shift to the 2.0 branch, which would really be 1.6 to 2.0. The 1.5 branch would be preserved for bug fixes and maintainence updates. Basically, x.0 and x.5 would be released once a year each, being used as long term support releases, while any 0.1 increments in between would be a beta for the next LTS.
I hope to do a good review of the code and my private roadmap and release an updated plan next weekend.
I've been prototyping Objects, which is similiar to a node in Drupal or Dynamic Data in Xaraya...to an extent. Objects builds on the Data Objects library and adds the persistent data backend that it was lacking. The idea is to provide input and output interfaces for a developer or admin to build custom applications. I say admin, because the way the objects connect allows you to plug in functionality directly into an input or output mechanism, without adding any code. In simplest terms, it's a hook - an application provides a property that performs some type of functionality and you hook that functionality into whatever you want (within reason). The most obvious use of Objects is for forms, where you want a user to input a date, so you plug in the date field property and allows the user to actually pick a specific date from a calendar. On the output side, after the date is input, the output side will allow the admin to format the date in a particular way or use it within another property for some other type of output, such as getting the weather for today's date.
That's just an example. I plan to implement different sources for input, such as user, database, remote, etc, which means there are a lot of other options that then come to the table. I'm hoping to have Objects in a stable beta within the next couple of months.
A lot has changed since my last post. I've moved to Italy (awesome!) and started working here. I love Italy, by far the most beautiful place I've ever lived. The food is awesome, the wine and beer is really good (and cheap), and it has already been a life changing experience. I can't wait to do some travelling and see the as much of Italy and Europe as I can.
"The FCC proposes buying back spectrum from TV stations that would allow for what theWashington Post is dubbing "super wi-fi," as the commission wants to cover the country with wide-ranging, highly-penetrative networks. Essentially, you can imagine the proposal as covering a majority of the country with open-access data networks, similar to cell networks now, that your car, tablet, or even phone could connect to. That means no one is ever disconnected, and some folks–especially light users and the poor–could likely ditch regular Internet and cell plans altogether."
One of my concerns about this is government control. If the FCC was serious about this they would remove fees charged to ISPs and give them spectrum instead of charging millions of dollars for it. I'm all for public Wi-Fi, but only if there is a barrier between the users and government censorship or snooping - although I realize that barrier is paper thin.
I've been working on some updates for the Blocks app in Clay. I've added a new table for block instances in block groups and added JQuery UI drag and drop for sorting the blocks from the Dashboard. This isn't possible from the page displaying the blocks yet, but that is in the works as well. I'm also adding more customization options to blocks display and divorcing individual block instances from a specific block group - which makes it possible to have a single block instance in multiple block groups. Each block has overlapping options that allow you to customize the title, template, and features enabled spanning multiple block groups, without creating copies of the same block instance. The block content and unique name will remain the same.
The updates havent been pushed to GitHub yet, as some features arent complete and I dont currently have an unstable branch on GitHub. I expect to finish the updates in the next couple of days and push them to the repo.
I've decided, mostly by convenience, to start doing pro bono projects again. I used to have 2 or 3 pro bono projects a year, mostly church web sites and things like that. I moved away from that when I started working on some projects that would end up becoming Clay.
Today a friend, I haven't seen in over a year, asked if I would build a web site for his new photography and design company. We discussed what he wanted and when we got to the prices I couldn't put a price on the project. It's going to be a lot of work, but I've mentioned to him in the past I would build him a web site to host his photography gallery. So, pro bono project #1 for 2013 has begun.
I'm not going into details about his company or what we're building, yet, but I will keep you updated on the progress and eventually post a link to the project. I have some fairly cutting edge ideas I want to introduce in this project, so it should be fun.
I committed a lot of new code to the Clay repo on github. I pushed the updates I talked about the other day, as well as an alpha version of an Eve Online app I've been working on.
There are also some bug fixes: App manager now correctly verifies upgrades are available; ClayDB now fully supports multiple database connection resources. There was something else, but I can't think of what it was at the moment.
I've been thinking a lot about how I want to do community-building apps in Clay. I want to begin building a message board system, but I don't want it to be exactly like phpBB or anything out there right now. I had been thinking of doing an integration, but it would probably just end up as a fork as it's hard to keep up with another development team like that (I've never seen an integration strategy work unless there were developers dedicated just to that project). I've also considered a bridge application that just hooks the sessions together, but then you have to worry about the user databases being synced. So, I'm going to do my own message board system. I think my primary goals for it will be simplicity in platform, but powerful on the addon side. I'm not all that concerned about the way it looks, because Clay's template system is entirely customizable. I also want to focus on real-time updates and building it into as much a chat room as it is an archiving forum.
I'm going to start with a comments system for the Blog app and work from there. I have some code from a while back that I never finished that should be a decent starting point. It uses ClayDo-style objects that I think will need a few tweaks to be a full forum, but will lead to something easier to maintain than many of the comments systems I've worked with (read: cried about) in the past. I do not want to use placeholders and things like that in my implementation. Sure, they may make sorting and things like that easier, but I think it's just a mess to work with.