Posted by David Harris
Sun, 30 Jul 2006 19:44:40 GMT
Ok, so first of all I’m sorry I dropped the ball on the Fictiverse series. It was probably a bad idea to start those at the same time as my job was picking up AND I was working on my own Rails apps. Hopefully I can get back into those in the next month.
Currently, I’m knee-deep in Rails junk, and realizing that the shiny goodness of Rails goes away when you get farther into application development. However, that’s where the clever right-brained Ruby language picks up and leaves you able to program without getting burned out. However, having a 40-hr/week job using C# plus trying to develop in Rails at home gets a little tiring, and it’s taking me a lot of effort to complete my first app.
However, much of my pain may be alleviated thanks to the guys at RightCart. I recently received an email asking for feedback on the cart. Now, as cool as the app was, I didn’t have much use for it. I have no products to sell or ship, and even with the latest improvement to allow digital content purchasing (like ebooks or mp3s) I had little use. I don’t sell things off my blogs, except if you want to buy my eternal love and gratitude, linked on the previous post. :)
But, while doing my own apps and some for a friend, I ran into a real problem… how do I actually accept money for this? Now, I know the basics, having set up shopping cart systems for people using open source stuff like Comersus or such. I know about merchant accounts, etc., but my real problem is that I didn’t want to spend time to find the perfect payment gateway that was easy to use but also allowed recurring payments (for monthly subscription models), etc.
How nice would it be just to drop in two lines of code, and have a cart that automatically handled your subscriptions? I’ll tell you: it’d be awesome. I was looking to use Google Payment (because let’s face it, if they wanted to buy me out I’d flip it in a heartbeat, and they’d have an easier time with it). In fact, I was set on making a whole Rails plugin just to handle this, so other people could have less pain. Programming a cart is not really fun, and I’d rather be focusing my efforts on my application, not how I get the few bucks I gain from it.
So when RightCart requested feedback, I probably annoyed them with two incredibly-long emails. After all, subscriptions are just products I can set up in my right cart, and now they even allow recurring payments! However, there is no pingback to me when an order is made, thus I cannot update my database to allow the user a subscription. So I emailed them my suggestions, as newbie as they might seem, basically requesting that I provide a server address they can ping with an order number, such as http://application.net/orders/10200394. I then take that number, check the RightCart xml feed, and update the order as appropriate. And with the new ability to include “special information”, I can capture the “add to cart” click, record the user’s information, create a hash in the DB, and then check the order information against those hashes. Basically, everything I need with one simple mod, and plus it allows for power users to ping their own website so they can use a custom order/inventory system.
Now, I’m not saying it will always work for me. If an application grows to gargantuan sizes, I might consider writing a custom cart/checkout and get a real merchant account. But at 1% cost with RightCart, you can’t beat that. In fact I don’t know how they do it for that cheap. It’s absolutely perfect for small starter sites. How many out there have spent about half the total development time handling how to get money? How much time would RightCart save us by handling that for us? Plus, it abstracts that part from my application, and frees me from the worry I’ve implemented something that could potentially screw with my users? Or worse, with my income?
I’d like to thank Ryan Garver, CTO of RightCart for taking the time to listen and respond to my needs, and I fully support the company, and can’t wait to use them for all my applications! They have an incredibly responsive team, and I wish them the best. I hope the mods I suggested can propel them even further. After all, they are about to make my life incredibly easier, so why would I not promote them to my best? And for you developers out there, check the app out, it will save you much time and heartache. :)
Posted in Programming | Tags rails, rightcart | no comments | no trackbacks
Posted by David Harris
Mon, 05 Jun 2006 14:30:00 GMT
Today, a break from the Fictiverse series so I can blog about possibly my favorite Rails application to date. You may notice the addition on my sidebar of a little goodie called RightCart. This little gadget is a whole hosted shopping cart made in Ruby on Rails.
Let me preface this by saying eCommerce is the bane of my existence. I have attempted the creation of several sites for “individual” sellers who had little computer experience. These were not businesses who had a certain inventory and kept great control over the entire selling process, they were just people who wanted to sell something they made or bought wholesale. Trying to find a solution for them was impossible, at best. I wound up using Comersus or similar open source carts, hardly the best solution.
Then came Shopify, possibly the easiest to use commerce software of all time, ever, also built in Ruby on Rails. And it was loved by all. Finally, a storefront that was not difficult and even dummies could operate it. Yet, it was still overkill for the person wanting to sell only ten items or so, but by far the easiest to use. Judging from the technological progression of shopping carts, I figured it’d be a decade before anything truly perfect came out.
Then came RightCart. I’m not about to claim it’s perfect at all, but it’s leaps and bounds forward for the personal merchant who does not want to bother with merchant accounts or integrating Paypal or any of that nonsense, but wants to make some quick cash for some merchandise. Perfect for the people I’ve made individual stores for in the past. Perfect for even the small business! Probably not perfect for a Wal-Mart or Target. :)
The concept is simple. You create an account at RightCart using just an email. It then gives you a 3-liner code to put on your website. The next step shows you a summary page, where you can create items to sell, or find existing items to sell from their catalog of existing items. Visitors to your site use the cart as if it were integrated into your own page, though behind the scenes some very simple but powerful and secure AJAX is being used to add items to the cart. Checkout happens on the cart itself, so the user never needs to leave your site.
It’s actually brilliant. It’s a storefront hosted elsewhere, but you do not have to create dirty templates to match your site, the user doesn’t know he’s left your page, and you don’t have to add any code but the three lines! They simply take a 1% cut off any money you make, and they give you 1% of any items you sell that are not your own (i.e. from the catalog). A 1% cut is amazing for something hosted elsewhere, even better than having your own merchant account with Visa. Even better, your item can gain exposure from other places outside your site if people wish to include it.
While it’s great, it’s not perfect. It is oh so close, though. The amount of screen real estate is horrible. They include two paragraphs of text to explain the cart, which results in almost an entire google skyscraper ad being taken. In fact, it pushes my own ad bar even farther down because the cart needs to be up above where people can interact easily, which will probably cut my ad revenue quite a bit. They could have easily opted for a small ”?” link at the bottom (perhaps after the “Shopping 2.0” text) that a user could click on and it would scroll the current text down for them to see. This would result in a much improved space footprint and still allow them some advertising to get people involved in their product. Don’t get me wrong, I fully support their need to initially get the product attention, but I’m afraid the ton of text will turn a lot of designers off the product, because it really does detract from the whole site (everything you add takes something away from the site as a whole).
Speaking for the text, whatever font is being used bleeds like crazy at least on my monitor. It appears like an old JPG that has been through several enlargements of smaller text. I really wish they would use a cleaner small font for that too, if they aren’t going to hide the text.
In the empty state, the cart is much too large. It says both “this cart is empty” and has a big picture of a Zero for items. One needs to go for an empty cart. I’d also get rid of the “title bar” at the top saying “RightCart Store”. My users are not going to know what that means. In fact, the word RightCart appears no less than 7 times on a single empty cart! That’s a little over the top. I would opt for a much plainer cart (no title bar, no text at the bottom), with a simple footer bar with a “powered by (RightCart logo)”, with the little ”?” link that expands the cart to display the help text. This would create a slick cart with a much better branding scheme than the current layout.
I’ve also encountered a few Internal Server 500 errors, and a few Rails errors due to a nil object. I’d be a hypocrite if I complained about those, however, because my apps have 500s and nil errors popping up everywhere usually. :) However, the nil errors can be solved by checking for it and handling, and the 500 errors can normally be solved with a nice stable hosting solution, but both are unfortunately a downside of Rails still. Can’t fault them too much for those.
However, those are all nitpicks from a design POV. And it’s almost a shame, because the control panel design is so brilliant. Adding an item makes you think it shouldn’t be that easy. The fact it keeps your cart over multiple webpages is awesome. The fact it’s so easy that a web novice could use it is awesome. As someone who has bore the brunt of many novices trying to get an online store up and running, I do appreciate this product.
I’m not sure yet how I will use it, but if you wish to purchase my eternal love and admiration (and see how this baby works), you may click here:
... well, actually I cannot get the “item code” link to work, so I can’t offer you my eternal love and appreciation yet. Check back later. I guess there’s another bad error. :)
EDIT 06/06/06: I emailed the RightCart support team, and they are great about responding quickly too! They quickly fixed the problem with the code generation (I love the speed RoR allows), and explained I only saw the Rails error page because my IP was in the same block as one of their devs. Ha, small world. :) Anyway, for those who wish to purchase my eternal love and devotion AND test out RightCart simultaneously, 
no comments | no trackbacks
Posted by David Harris
Fri, 02 Jun 2006 14:14:00 GMT
Sorry this has taken so long, I’ve been on vacation. I’m hoping that in the future, I’ll be able to update at least every few days. Anyway, last time we setup everything to get it ready for our coding, but I made the mistake of setting up my database before writing the tutorial, and thus I received several emails claiming errors and the Rails page not showing up. Again, browse the Rails Wiki to see how to do this, or wait for the next tutorial. This tutorial is less of a teaching and more of an explanation of what Fictiverse is and what our constraints will be.
Summary
At the core, Fictiverse (abbreviated as FV from here on) is intended to be the next trend of community-based or collaborative fiction. It has elements of both Alternate Reality Gaming and Fan Fiction. The premise is simple—we want to create an entire separate internet that represents a fictional world. Picture a Venn Diagram of the internet, a large circle. Now superimpose a smaller circle that barely overlaps it; this is the Fictiverse world. The tiny overlap represents the site we are creating, the site that connects the real world to our fictional world.
The actions a user can take are limited only by imagination and the will of the community at large. Users basically create websites, either blogs or otherwise, that represent their persona in FV. If they wish to be the next media mogul, perhaps they create Fictiverse News Network, “hire” reporters, and create a CNN lookalike. If they wish to be a FV politician, perhaps they begin campaigning, and perhaps someone else becomes the head of an election committee. Perhaps someone else wishes to blog about their experiences as a space pilot in some random part of the galaxy. For those that cannot afford a domain name and hosting, perhaps someone would be so nice as to create a community blogging system for them.
Sites are either accepted or rejected by the Fictiverse community as a whole. While writing fiction is one half of a user’s responsibility, the other half is voting on which sites should be part of FV and which sites should not. This will be accomplished via a dirty imitation of Digg, which will be the majority of the project we are creating now. A user submits his URL and persona to the site we create, and users either give it a thumbs up or down. The most voted make it to a “front page” where the main FV sites will be. The least voted are moved to the back where they get lost or become such a negative score that they may be moderated off the site.
For example, a user wants to just “become” the president of FV, so he creates an official president site. He submits it to the site. Users do not like someone circumventing normal rise to power, so they vote him negative. Eventually, he reaches the bottom, nobody even sees his site, and if it gets flagged for moderation enough, it may even be removed from the database. The site can still exist on the web, but it’s no longer linked to FV through our hub and therefore not a part.
So, the rules are quite simple. Write what you may, and let the community decide what belongs or should not. The only rule set in stone is that all fiction should be able to have a PG-13 rating such that we can allow younger people to also participate. Thus, Fictiverse is fiction that evolves over time through decisions made by the community as a whole. It’s like a multi-dimensional novel, as you can read of the experiences of many people in the same fictional world.
Constraints
So, we have a good idea of what Fictiverse will look like. Now, we will discuss what it should not look like.
The main benefit of our job here is that we are creating a system in which the community can work on the tasks like community blogging, news aggregators, etc. This keeps our job very small and manageable. I’m a huge proponent of Agility in development, and keeping it small is the best way to scale later if we need to. The beauty of only handling users, their links, voting, and moderation is that the system is not complex and probably will never need to scale past one server. In fact, I’m starting it out on shared hosting, and don’t expect it to run me out for awhile.
Initially, we will only deal with those tasks: users, links, votes, and moderation. However, we will allow for two other things in a future iteration—a “friends” system, and a forum system. These forums would be used to discuss issues about FV but not inside FV, like an OOC channel. Since we want all FV member sites to be in character, we might need to provide the OOC forum to make things work behind the scenes. This is ok, and I would probably integrate Vanilla when that time comes, instead of creating a custom system. So these are our constraints as far as where we are letting the software go. No more, unless the system really requires something new to function correctly.
We do have two major things to consider in our design. The first is that FV member sites cannot bleed into the “real world” internet. We want the only entrance to the Fictiverse world to be through this site, or by explicitly typed in URLs. Now, this is very difficult. After all, we’re using domains that are in the “real world” root servers, and probably have “real world” nameservers. And I don’t plan on recreating the internet with new root servers. :) But, this is fine. What I’m mainly concerned with is making sure nobody links to it from outside, or puts their site into Google, or anything like that. We don’t want google indexing Fictiverse and some random googler thinking that someone actually cured cancer or something like that. And, email becomes difficult because that is in the real world. The second constraint is the moderation system, making it easy and rare.
The first problem cannot be cleanly solved. We will have to provide some guidelines for this. Users may not explicitly enter their site into a search engine, they may not link to it from elsewhere, they must have a disclaimer on the site linking to the FV hub and claiming it to be fiction, and they must set the robots.txt file on their server to disallow any crawler. This will not solve the entire problem, but it will alleviate it to some extent. If someone wishes to link someone to their site, they can use a hyperlink forwarder from within our site, which when clicked on would first stop the person at our site, and after explaining the concept would forward them to the person’s fiction.
Also I should note that since I’m not paying for these sites, and most people are broke, if they wish to place textual Google Ads, they may. Because it is discreet and well established, we will only allow Google ads on member sites, and they must be placed tastefully. If someone creates a site with an obvious intent to make money without providing decent content for the community, he will probably be voted to the back anyway.
As far as moderation, this becomes easy with our system. We simply allow users to “flag” a post for review, similar to Craigslist but not automatic. If enough flags are set, it will enter probation where it will be reviewed by a moderator. A site should be moderated for only a few reasons: 1. Violating the PG-13 rule, 2. An obvious intent to connect their site to the real world, or 3. Violates the common will of the community (someone claiming to be president that should not be). Obviously anything illegal in the real world applies here too. The goal is that users decide what FV will be, and moderators only apply in extreme cases.
Future Evolution
I imagine at some point, the possibility to have two or more Factions represented in FV could happen. Just as Republicans and Democrats mainly differ on about 2-3 core issues, the users of FV may also see it going in several different directions and wind up choosing a side. At some point, we may need some way to split apart like an amoeba, so we need some way to detect when this will occur and then a path for the actual mitosis process. Detection may eventually be accomplished by creating a crawler to check the sites to see who in FV is linking to whom, and create a graph of what FV looks like with hyperlinks as the edges. If it results in two large masses then it’s time to split it apart, probably through a forum system and asking the community how to handle it.
However, this is a function that does not at all need to be created at the onset, as in a utopian fictiverse, everyone can function together as a happy group of people. But we are human, so it’s good to have a plan if we start hitting a lot of sites rated at 50% (equal thumbs up and down, indicating division). In general, for a long time, things should equalize well though and this is a problem we can solve later.
Community
Since this is a community project from creation to use, I welcome the opinions of anyone reading this through the process. If you have suggestions, complaints, or want to see something else, I will consider everything. If you want to go ahead and think up a persona to participate, I hope to be finished with this in the next several months, so start thinking! I want Fictiverse to be fun and friendly, from development to production, so everyone has a say what it should look like.
Also, know that I build applications around people constraints more than a written paper on what the application should and should not look like. I imagine how people would react to things, and make decisions accordingly. For example, I chose Ruby on Rails not because it’s the latest trend but because it will let me quickly get something running and update it easily as the site develops. I will use AJAX not because it is flashy, but I will add it where appropriate to enhance a user’s experience. And I use mostly Agile methods not to be like the cool kids, but rather to let the whole process from start to finish be about the end user, because without them there would be little need for an application.
Next tutorial will cover creation of the database and model, so that should be fun. Please give me comments or suggestions soon so I can incorporate them into the schema early on.
Digg this!
Tags fictiverse, on, rails, ruby, tutorial | no comments | no trackbacks
Posted by David Harris
Wed, 24 May 2006 11:53:00 GMT
(Quick note: If you were looking for a post entitled “Solving the Password Problem”, it accidentally got deleted when I tried to use a new blog editor. Performancing is great, but be careful.)
Ok, so this will be the first part in many on the journey of a rails app called Fictiverse. For this post, I’m not going to detail what the app is going to be yet, but I will explain some initial setup things I’ve learned. These are all things that can (and should) be done before you even think about application design. I will be creating Fictiverse on a shared host using linux, so you’ll have to adapt this for your own purposes. Be forewarned, I’m going to be very detailed on each point. I believe there are a lot of resources out there, but few have managed to detail every part of things; I’m going to attempt to explain everything I can in this process. If you’re comfortable with certain parts, skip them please! I imagine most of my audience can safely skip the first section.
1. Getting a domain and setting it up
I’m going to assume that you already have a domain and web hosting. If you’re looking for an excellent host that allows Rails and Subversion (for purposes of this series), I highly recommend the host for this domain, A Small Orange for their awesome support and great price. I host about 10 domains on the $5/month package and have not even used 20% of the space or bandwidth yet. Definitely the only host I’ve had no major problems with yet. Once your domain is purchased and you have a hosting plan, be sure to add your domain to that plan (follow the instructions of your host, or ask them how). Now, you’re pretty much set for this portion.
2. Setting up your Subversion repository
For those that have never used a source or revision control system, you’re missing out! I can’t tell you how many times I’ve screwed something up and had to revert to older code to see where it went wrong. Source control basically means that after you make changes to your code, you commit the new code to a server where it keeps track of the evolution of your code over time. If something ever screws up, this is like a backup system for oh-so-important code. Luckily with Rails we’re not going to have to write a lot of code, but this will still be important. Also, this allows you to easily work on the same code from two locations, and have both be a local copy. Our “production” copy will simply be checked out from the repository from time to time.
To set up your own subversion repository, issue the following commands. In my server’s home directory (~), I have two subfolders I use for my rails work; one to hold subversion repositories and one to hold the actual rails code. The following series of commands will set up that structure and your repository (note that for the simplicity of this tutorial, I will not be using the branches/tags/trunk structure of most repositories):
[~]# mkdir rails
[~]# mkdir svnrepo
[~]# svnadmin create ~/svnrepo/fictiverse
[~]# cd rails
[~/rails]# svn co file:///HOME/svnrepo/fictiverse fictiverse
Note that
HOME should be replaced with wherever your home is (such as /home/davidh for me). Now, your repository is set up and you have a home for your rails app. Next, we will create the rails application structure and update the repository.
[~/rails]# rails fictiverse
[~/rails]# cd fictiverse
[~/rails/fictiverse]# svn add . --force
[~/rails/fictiverse]# svn ci -m "Added Rails Structure"
[~/rails/fictiverse]# svn up
Now, we will set subversion up to ignore our log files for versioning. If you wish, you can adapt this set of commands to ignore the Rails cache (tmp/*) and database.yml file (in config/) if you want to have seperate ones on each place you develop. For now, we’ll just ignore the logs. We will get around the database.yml issue by using the same login/pass/db wherever we are.
[~/rails/fictiverse]# svn remove log/*
[~/rails/fictiverse]# svn propset svn:ignore "*.*" log/
[~/rails/fictiverse]# svn ci -m "set up log file ignoring"
[~/rails/fictiverse]# svn up
Ok, so currently we have a working Rails directory, and have set it up inside version control to use from home, work, or wherever we wish to work on our application! For details on how to access this from home, this will be covered when we start coding.
3. Going public
Thus far, all our work has been behind the scenes. It’s time to take it to the world. This section really depends on how your host is set up, so I’m obviously going to assume
ASO, my host. First, you need to explore where your host redirects request for your domain. For example, I type in fictiverse.com, it takes me to a directory listing, since I have nothing in there. So where is it actually looking? Well, I check out my server’s log files and I see the request was looking for /users/davidh/www/fictiverse/. So now, I know where to look. Sure enough, fictiverse is a directory inside www (a symbolic link to the public_html directory). So how do we connect this to rails? Easy, we switch the directory for a symbolic link to our rails/fictiverse/public directory.
[~]# cd ~/www
[~/www]# rm -rf fictiverse
[~/www]# ln -s ~/rails/fictiverse/public fictiverse
And that’s all there is to it! Check it out, “http://www.fictiverse.com”http://www.fictiverse.com . The default Rails page comes up, telling us to welcome aboard. Not a whole lot of work to arrive at this point, and not a whole heck of a lot got accomplished, but we have a domain hosted somewhere, have the shell of a Rails application up and running, and it is all version controlled. Not bad for a few minutes of work, and utterly necessary for any rails app you wish to create. Thanks for reading Part 1, and Part 2 will come in the next few days, where we begin actually designing the application and defining constraints.
Edit: I’m very sorry, but I completely screwed up and forgot that I have database information previously set up. I think only a few people have started this so far, from emails, so I’m sorry you’re all getting 500 errors! Until database information is set up it will not work. So, you might have to wait until part 3 for me to explain setting that up. But if you wish to browse the Rails Wiki you can find how to set this part up on your own.
Digg this!
Tags fictiverse, rails, tutorial | no comments | no trackbacks
Posted by David Harris
Tue, 23 May 2006 16:02:12 GMT
I finally upgraded to the Typo trunk! Last time I tried was also the time Rails upgraded to 1.1 and broke Typo completely, and needless to say I encountered a lot of problems. This time was a snap. I simply svn checkout’d the latest copy into a new directory, created a new database, did a mysqldump and a restore on the current DB, updated database.yml, did a rake migrate, and then redirected the blog subdomain to point to the new directory. After some caching issues were resolved, we’re back to normal!
Only, now Lush, the beautiful theme I had up before, is broken under Trunk. I may toy around with that later to get it working again. But now is exciting because I can use code filters and everything. Which will be important for my future blog plans.
I’m currently learning Rails 1.1. Had a pretty good handle on it from the first PP book that came out, but things are busy and I couldn’t keep up with the latest developments, like RJS and migrations, much less polymorphic goodness. So, for the nest several blog posts, which may span several months due to other committments, I plan to blog my process in creating a new application using the new 2nd edition (beta) of the Agile Rails book which documents up to the current 1.1 version. I’ll introduce the actual application next post, but my plan is since it will be a non-business application for the community, then there is no fear in blogging it. I want to include as much (or little with Rails) code as possible too. I figure it will be a good series for those who can make an example cookbook, but find it difficult where to go from there. I’ll be learning along with everyone, so we all win, and hopefully I can give back a bit to the community.
no comments | no trackbacks
Posted by David Harris
Thu, 13 Apr 2006 15:29:00 GMT
So apparently Google just released Google Calendar. And, like anything else Google, they did an excellent job at usability, even though it won’t play nicely at all with Firefox (my javascript console is spitting out all kinds of sweet errors). The Tinycal project I was planning on doing may not be a reality anymore. I still don’t like that they did a week view, day view, agenda, etc. Those are pointless to me. However their month view is excellent, and I was able to easily default the view to monthly. It allows me to easily ignore entering anything but the event itself. Entering multiple-date events is easy. It parses basic entries like “2pm Dinner in the dining hall” easily.
Basically, it’s everything I wanted with my own calendar app, except not lightweight enough. While it’s light years faster than most of the other calendar apps out there, I still think they’ve included too much bulk with unneeded stuff. They’ve gone the route of every other calendar out there. I still can’t help but believe that the next generation of calendars will be very different from anything we’ve seen before. Granted, business and education users need to micromanage a day into blocks of time. But people who work a normal job, and have maybe 5-6 events per week they need to keep track of, don’t need to enter a time or location for every little thing. While I appreciate that Google Calendar doesn’t require that, I still think they would have done better by not programming that functionality in at all. Though I do at least like that they don’t force those ideals on the rest of us if we don’t want it. Now if I could tell them not to even load the code for all that to speed it up…
I like the ability to publish and subscribe to calendars, exactly what I imagined for a family or close group to use. I LOVE the ability to have a location hyperlinked to a google map! That is incredibly awesome, as it saves me the extra manual step of plugging in an address. This probably isn’t a big deal outside of larger cities, but people are always planning something at a random place I’m looking up on a map anyway. Great feature Google.
It also looks like they’re trying to take the Evite market. Evite sucks, so it’s likely they’ll succeed. Simply add an event to your calendar, and then notify the people you want to attend. Right now this looks manual, but I’m sure when it gets integrated with Gmail you’ll be able to select from your contact list.
I like that they got rid of “categories” for events. Always thought that categorizing events was stupid. Does it matter what it is, if it makes you unavailable?
Overall, I give it a 8/10. It could be faster, and it could work on Firefox. Right now it does not look like it’s integrated in Gmail. I would love to send an email out that says “Poker tournament 5pm friday my place” and have it automatically create a hyperlink from that, which adds the event to the users calendars if they click it. I think they could do a better color scheme, it’s just too blue right now. Some bolder colors would make it less boring. But they did a great job, enough to make anything I attempted to do useless.
no comments | no trackbacks
Posted by David Harris
Fri, 31 Mar 2006 14:35:00 GMT
Wow, so that was different. :)
So I make a post that has some ruby code you can do with rails, that lets you basically chain database relationships into a chain of objects through a ”:through” declaration, when I realized the current stable Typo doesn’t have syntax highlighting support. So I tried to upgrade to the SVN trunk, likely at the exact moment my host did the upgrade to Rails 1.1.
So I was stuck with my old installation with a new database, a new installation that I wanted, and neither working because 1.1 broke it.
In the end, I just wanted Typo back up. Luckily, I’d dumped the mysql database before that. Probably took that from working with SQL Server too much. :) So I cleaned out the databases, restored the old one, put my symbolic links back to the old installation, and tried it out. Didn’t work. So, in the interest of someone with the same problem coming across this, I applied this patch from Typo’s ticketing system and it fixed everything (reassociated the rails libraries to 1.0).
It’s a shame too, because from the little I’ve looked at Typo code, it looks like a lot of the stuff they hack around to get database stuff to work could be completely replaced by some of the features in rails 1.1. Though apparently they are working diligently on it, so here’s hoping for some code refactoring and 1.1 compatibility before Typo 4 is released.
3 comments | no trackbacks
