Recently, I noticed that the LoneGM had put together a pretty good review of ObsidianPortal. He focuses on it from a play-by-post perspective, which is not exactly what it’s for, but still gives us a good rating.
Like me, it seems that most of the people using OP can see what it should be, even if it’s not there yet. We’ve all been searching for a good campaign management tool for a long time, and building it up to match that perfect ideal will be a long road.
Update: 2008-02-21 We’re looking into using ActiveMessaging and Amazon SQS to help with the workflow for background processing. Stay tuned for an updated post.
With before_save and after_save filters being so easy to use, it’s tempting to add more and more pre and post-processing to saving an ActiveRecord model. For Obsidian Portal, we update permissions, set timestamps of associated objects, and do all sorts of stuff. Unfortunately, all this extra work takes time, and can significantly slow down your application. The more work you do on the main execution thread, the more time Mongrel is tied up doing stuff unrelated to servicing requests. If something goes wrong in any of the filters, Rails will rollback the database transaction, and *poof* it’s all gone!
A while back, we started seeing ‘rbuf_fill’ timeout errors in the server logs. From what we could see, calls to acts_as_solr indexing were timing out, interrupting the save. For us, this was really bad. People would spend lots of time painstakingly crafting their perfect blog posting or wiki page, only to have it evaporate into nothing. All they saw was our default “Internal Server Error” page. Sure, it looks nice, but no one wants to see that 
Tracing the timeout back to Solr was not hard, and the solution was clear: take the indexing out of the main execution thread and move it to a background process. Luckily, acts_as_solr made this a fairly easy refactoring process. Here’s what we did:
acts_as_solr supports an :if clause that will be used to determine whether or not the record will be indexed when save is called. We want this to always evaluate to false, except when we explicitly set it to true during off-line processing. Below is an example from one of our models:
Now that indexing does not happen on save, we need to make sure it happens at some point. Our solution was to move it to a rake task that gets executed by a periodic cron job. Rake + cron has worked well for us in the past, so we’ll stick with it.
The task itself is very simple. Find all the objects that have been updated since the last indexing, and push them to Solr.
Below is the rake task that I wrote. If I were more clever, I would probably come up with a neat trick for automatically finding all the models that support Solr indexing. Now that I’m an official committer on acts_as_solr, maybe I’ll try to figure something out and get it into the trunk. Still…I’m lazy 
Set up a cron job to run this every thirty minutes or so. For most sites, a half hour will be a good balance between keeping the load down and making sure the searching is fairly up to date.
By moving the indexing off the main thread, we’ve noticed a significant reduction in the number of Solr related exceptions. That means our users have seen a significant reduction in the number of “Sorry, we lost all your data” errors, and that is exactly what we were hoping for.
I saw an article in the New York Times the other day about working 10 hours a week and making $10 million a year. The article profiles Markus Frind, who started an online dating website, Plenty of Fish. The main thrust of the article is that Markus barely works at all and just sits back raking in cash. Are there any other web entrepreneurs out there who are sick and tired of hearing this story over and over? This is all I ever hear, and I secretly dream about it while working on my projects, but it doesn’t match up well with the real world of late nights and no money.
Hmm, let’s look through the NY Times article and see what the keys are to creating a cash-cow website:
Ok, I’ll admit, this is the life I want to live. This is the dream of all us web guys. However, I’m starting to suspect that the vast majority of “successful” web entrepreneurs invest a lot more effort and reap much smaller rewards. How many of us out there are pulling in $50, $100, or dare I say it, $500 a month from our projects? If I could get Obsidian Portal to generate $100 a month, I would be ecstatic. After paying off the hosting fees and whatnot, my take-home would probably be less then $1/hr. Still, it’s a goal to shoot for.
We can’t all be Digg, YouTube, or Facebook, but that’s OK. Success has different levels, and if we can just generate enough income to justify the amount of time we spend working on the sites we love, then that’s success. I just wish the media would profile a few more of us who live on the wrong side of profitability, work until 3:00 in the morning, and jump for joy with every subscription or CafePress T-shirt we sell.
Are you like me, barely scraping by (or not, as it were)? Drop a comment when you take a break from furiously writing code or begging someone not to cancel their account…
Moving to Rails 2.0 or above will break Comatose 0.8.1 (the latest as of this writing), but luckily it’s very easy to fix. In order to get running again, all you need to do is install two plugins that used to be part of Rails core:
script/plugin install http://svn.rubyonrails.org/rails/plugins/acts_as_list/ script/plugin install http://svn.rubyonrails.org/rails/plugins/acts_as_tree/
Once again, a great big thanks to Matt McCray for putting out such a useful plugin.
Yax over at Dungeon Mastering recently put together his list of the top 50 (now 52) RPG websites out there. Coming out of nowhere, Obsidian Portal shows up at #13. Of course, he readily admits that his rankings are totally biased, but that makes it worth even more to me. Rather than trying to quantify why Obsidian Portal is any good, users just like it.
Anyways, thanks Yax for the link and knowing that we exist!
The built in Rails tools for selecting dates are adequate, but just barely. Most people are used to ticking dates off on calendars rather than choosing from a bunch of pulldown menus for year, month, day, and so on. Still, I’m lazy so that’s still what I’m using in most places.
Luckily, today I found a decent list of several date pickers. I haven’t tried any of them out yet, but any one of them would surely give Obsidian Portal a bit of a usability boost.
My podcasts / vidcasts at SD Ruby have been posted to the podcast section.
How to use Simple Sidebar plugin to DRY up sidebar content in applications.
Related Blog Posts:
http://blog.aisleten.com/2007/06/03/simplesidebar-if-you-have-sidebars-you-need-this-plugin/
How to build an Ajax-powered, CSS star rater using the ActsAsRateable plugin and Komodo Media’s CSS Star Rating Redux technique.
Related Blog Posts:
http://blog.aisleten.com/2007/05/03/ajax-css-star-rating-with-acts_as_rateable/
http://blog.aisleten.com/2007/05/17/find-the-top-5-highest-rated-objects-with-acts_as_rateable/
At this month’s meeting we’re going to be having our first Rails Roundtable so come and check it out.
SD.rb December Meeting Schedule
Either I will get flamed for this, or the lack of comments will show how unknown I am, but I’m going to go ahead and make a heretical statement: I did not like Atlanta Startup Weekend (ASW). I felt that it was an interesting experiment, but like most experiments, it was a failure.
In the spirit of total honesty, I’m writing this at home while others are still toiling away on Skribit. I came for Friday night and half of Saturday, but finally had to cut my losses and head home. I was not contributing, not learning, and had my own startup to work on. So, rather than be part of the problem (see Too Many People below), I decided to be part of the solution and cut out. I don’t consider myself a quitter. Time to work on my projects is my most precious resource, and I just couldn’t spend any more of it at ASW doing nothing.
Having been part of many failed experiments, I feel that it’s my duty to look back and try to pinpoint what went wrong and how it could have been done better. A failure is nothing to be ashamed of, but it’s only useful if you honestly criticize yourself and try to correct in the future.
Update 2007-11-11:2300 It looks like I was too hasty in my proclamations of doom. The team seems to have really pulled together and is going to put out a beta release. Still, I think the following criticisms are valid, so read on and enjoy.
Update 2007-11-12:1200 Talking to Jason today, it seems that they were able to wring out a lot of work in very little time. Getting a manager from each different group, having regular releases to the staging server, and assigning individual use cases sounds like it worked quite well. Not to mention everyone pulling together and working hard. So, it seems that I was pretty off-base in my criticism. From what I understand, the following rants only apply until shortly after I left, when everyone started to get organized. I tip my hat to everyone who was able to stick it out to the end.
By far the greatest issue is the number of people. Successful startups are comprised of 2-3 people who decide to get together and solve a particular problem or fill a niche, often one they have been talking and arguing about for a while. With ASW, you have 50-70 people who don’t know each other and have no particular focus.
Most of my following criticisms are simply extensions of what happens when you have too many people. Fixing this one issue would go a very long way to improving the experience. On the flip side, ASW wouldn’t be that exciting if only 5 people were invited…
It was exhausting just trying to understand what it was we were going to do. I’ve been on teams of 5-10 where no one knew what the goal was. Growing that to 50 people was simply that much worse. What made it so frustrating was how simple the Skribit idea actually is.
There seemed to be a significant disconnect between what I thought, what the other developers thought, and what the business people thought. In the spirit of “we have to launch in 2 days,” I wanted bare minimum. Add suggestion, vote on other suggestions, end of story. No moderation, no similar suggestion match, none of that. My version was probably too basic to be useful, but it could be done, and possibly enhanced in the future. This was the product I envisioned. Unfortunately, I don’t think anyone else shared this vision.
Now, that’s OK if I was the only outlier. Hey, maybe I’m just stupid, right? However, I think everyone had it different. It never seemed to me that anyone was on the same page about what exactly we were building.
I’ll go ahead and name Erik as the lead developer. He took the initiative to set up the SVN repository, bootstrap the Rails project, and start hacking away. I imagine that he, like the rest of us, was tired of aimless talking, writing, diagramming, and all the other seemingly endless pre-coding activities. So, like any restless developer, he jumped in and started working. A few other developers followed, and we were off to the races.
Between Erik, Calvin, and Nate, (last names elude me…) it seemed that a lot of work was getting done. However, without an organizational structure, three developers is probably the maximum concurrency you’ll be able to get, especially this early in a project when there’s so much foundation to build. Even with only three, it seemed there were quality control issues with people breaking each others’ stuff fairly regularly.
Jason and I noticed this immediately, so we tried to put on the management hat and create individual user stories for the preliminary features of the system. Following along with the UI mockups, we wrote up about three use cases. We tried to be careful to keep the scope small enough that someone could accomplish the use case in a short period. We also tried to make them independent so there would be a minimal amount of stepping on each other.
As I should have expected, none of the developers were all that interested. Why should they listen to us? Sticking our use cases in their faces was just interrupting their actual work of developing. I completely understand this point of view, being a coder myself. Realizing that pressing would be futile, I resigned to simply stay out of the way.
To be clear, I don’t want to be too critical of the core developers. They were doing real work, while the rest of us just stood around. However, the approach made it fairly difficult for any of the rest of us to help. Then again, does a project of this size really require 15 developers? Maybe it just needs three.
Without use cases, requirements, or any sort of work breakdown, asking for release cycles is pretty ridiculous. Still, I strongly believe that it’s worth it to periodically freeze the features and push out a release, even if it’s internal.
For ASW, this could have taken the following form: Set a deadline (time, not features) that everyone shoots for. When that deadline comes, we do a quick feature freeze. Make sure the code in SVN passes the tests and has no glaring errors. Until then, no one starts a new feature. It’s OK for the developers to idle for 5, 10, or even 30 minutes. If it’s taking that long, it means that the code in SVN is poor quality and that’s something that needs to be addressed.
Once the tests are passing, and there are no glaring errors on the interface side, push it to the staging server. Then, crank the developers back up to work on their next use cases. While they’re working, bring in some biz-dev guys to test the prototype. They can make sure we’re all still on the same page! Document any bugs found, figure out if we’re implementing the right stuff, and keep going.
Rinse and repeat every 2-3 hours.
Jason and I did set up a staging server on the Mac Mini that was provided, but learning from my failure with the user stories, I didn’t press the issue about the release cycles. When I left, Jason was periodically updating the staging server. I probably should have pressed harder to get some biz-dev or others to look at what was present on the staging server. I was afraid to press too hard on anyone, since I didn’t feel like part of the productive core group. Who wants to take advice or orders from some guy who’s just standing around?
For the developers that showed up with no Rails experience, it must have been a very demoralizing experience. Jason and I tried to help them a little, showing them the Blog in 15 Minutes presentation. Still, assigning them a homework video is a long way from actual mentoring and tutoring. The development, especially the core creation of the models and associations, happened in such a whirlwind that the non-Rails guys didn’t have a chance. There was no way for them to contribute as developers, and that must have felt pretty awful. It sucks to feel useless.
SW was not a waste of time. Far from that, it was very interesting, and I did learn a few things. Plus, there definitely has to be some kudos handed out to a few people:
The naming team came up with several names, and they were all quite good. I’ve always found this process arduous and usually go with something like www.aprogramtovoteonblogtopics.com or www.rubyonrailsprojectmadeforbloggers.com where I focus too much on the features or the technology.
Luckily for us, we had someone else to handle this important task!
I didn’t see much, but the UI mockups looked very good. I’ve always been envious of the design people and their ability to pull out pencil and paper and create great stuff. I draw stick figures and they make Picassos.
Lance Weatherby and the other organizers did a great job with all the logistics. The food was good and there were plenty of powerstrips. There was always a room you could go to if you needed a place to discuss something without the constant hum of work. The WiFi was so-so, but I don’t think BarCamp was any better. A hearty thanks to all the people that worked to bring this to Atlanta.
This is the obvious solution to pretty much all the problems I listed. An ASW-scale project should be doable by a team of 3-5 people. Two coders, one biz-dev, and one or two graphic designers. With a team that size, you can quickly cut through all the communication problems and get to work. Shared vision is easier to sustain, and project progress is much easier to measure.
To integrate this with SW, I suggest that the entire group be broken into 5-person teams. Rather than forming one company, form ten! Choose ten different ideas and push them all the way through to completion.
As long as it’s possible to move from one team to another (perhaps by buying a position in the comany?), there should be enough flexibility for people to organize as necessary. At the end of the weekend, take an hour or two to show off all the projects and discuss what went well and what didn’t. For added fun, hold an IPO where people can buy into the companies they like.
Crazy? Impossible? That’s what most would say about Startup Weekend in general…
Am I way out of line? Did we start tagging releases and pushing them to staging? Did all the problems I listed disappear when I left? (Doesn’t look like it) I’d definitely like to hear from others, especially those that stuck it out for the entire weekend. It’s a crazy idea, which usually I like, but I just don’t think it works.
Update: 2007-11-28 Lance Weatherby, the Atlanta organizer of Startup Weekend, has put together a pretty good write-up on the experience. He specifically mentions the need for milestones and leadership, and I would definitely agree. Overall, it seems that most of the people who stuck it out the entire weekend came away with a positive view of it. There’s something to be said for that, I guess.
There are a handful of websites that have sprung up to help gamers find each other. It’s a great idea, and was one of our original motivations for creating Obsidian Portal. At the time, I didn’t know about the other player matching sites, and I was too scared to ask, thinking someone would steal my awesome idea.
Unfortunately, most of these sites just don’t have the critical mass necessary to make them useful. I have signed up on a few, and I have never received any sort of response. Seeing as how I live in Atlanta, that’s a bad sign. If I can’t get matched up with players in a big city, there’s no way people in rural areas are getting any use out of it.
What if there were a way to combine and aggregate all the data from all the sites into a single index of gamers? In this day and age of web services and mashups, there is no reason that this should be impossible. So, for your consideration, I am proposing a communications protocol that will allow all the player matching sites to interoperate for the purpose of providing more results to their users. I am calling this the Lonely Gamer Protocol, or LGP.
Update 2007-11-06 I’m looking at using Google’s OpenSocial as a possible alternative to Atom. OpenSocial’s people element has almost all the necessary fields, and the gd:ExtendedProperty might be sufficient for the rest.
Of course, the main motivation is to provide a better experience to our users. By sharing our data with each other, we will beef up the number of results returned to our users, thereby greatly increasing their chances of getting a hit.
However, at least in my case, there is a secondary, more commercial motivation. With Gleemax breaking onto the scene, Wizards of the Coast has become the 800 pound gorilla in the room that none of us small timers can compete with in terms of marketing or exposure. Unfortunately for the users, Gleemax just isn’t that great, at least not right now. They have a lot of promises, but very little in the way of actual features.
If we all try to compete directly with Gleemax, we will probably fail. They have an established userbase and a war chest they can dip into for advertising and paying their employees. However, if we band together and attempt to make interoperable services, we’ve got a shot. Pretty much any of the current gamer-finder sites is already 1000x better than Gleemax, and working together will only strengthen that lead.
Of course, Gleemax is free to support LGP as well, and this would be a great boon to the entire community. However, given its current state and their speed of resolving issues and feature requests, I don’t see this happening for a looong time.
Please comment below if there are goals I should add or remove. Please note, however, that projects that are able to condense their goals down to a short list do better than ones that throw in everything and the kitchen sink.
LGP consists of a communication protocol along with a simple REST API for retrieving the data from participating providers.
The actual data involved in such an exchange should be very simple. Shooting from the hip, here are the fields I could come up with:
XML is the obvious choice for the data exchange. That’s a no-brainer. Further, in order to further lower the barrier of entry, I suggest that we use a preexisting XML protocol as a base layer. Most of the fields I’ve suggested could be easily stuffed into an RSS or Atom feed.
| LGP Field | Atom Field | Comments |
|---|---|---|
| Name | title | This would be the username, nickname, or campaign name |
| Geographic Location | georss:where | We can use the GeoRSS standard for Atom feeds to encode the user’s location. It would be encoded as a gml:Point element. |
| Preferred Games | category | Cram all the games you want to play in as category elements. For bonus points, we can define a closed vocabulary for the more popular games. Of course, this would be in addition to an open, free-tagging scheme. |
| Looking for game | ?? | A flag to indicate that a player is looking for a game to join. |
| Looking for players | ?? | A flag to indicate that an existing group or campaign is looking for more players. |
| Link to profile | link | This would be a link to a profile page for the user. Following this link would be the primary way of finding contact info for the player. Note: This link would probably also be used for the id field required by an Atom feed. |
| Last update / login | updated | This field indicates the last time the user updated their profile or logged in or something similar. The main goal is to let the stale entries settle to the bottom while the active, searching players can be easily found. |
Looking back on that list, there are a few fields that need to be fleshed out and some formats need to be agreed upon, but the core functionality easily fits. Using Atom as the base for this protocol provides a lot of great benefits. As I mentioned before, most languages will have an Atom parser, making feed consumption that much easier. In addition, many will have tools to help construct feeds. Finally, it will be possible for the data to be made available to individual users, if they wish, just by subscribing with an Atom feed syndication tool. It might strip out some of the additional fields that we add, but if you provide filtering at the upstream level (ie. “Subscribe to a feed of all the gamers within 50 miles”) then it shouldn’t matter.
I’ll be the first to admit that I’m not really sure what’s required here. There needs to be a way to harvest the data from the individual sources. Further, there will need to be a way to filter the results, both in order to save on bandwidth, but also to make the results useful.
The following parameters allow for filtering based on set size, preffered games, and the last time a player’s profile was updated.
| Parameter | Required | Comments |
|---|---|---|
| limit | N | The maximum number of entries to return. Defaults to something reasonable, like 100. |
| start | N | The index of the first record to receive. Manipulating start and limit allows a client to iterate through a result set. Defaults to 0. |
| categories | N | A comma separated list of categories. This allows for filtering based on which games a client is interested in. |
| last_update | N | A date field (what format does Atom use?) indicating that you only want results that have been updated after the specified date. |
Filtering on geographic location would probably also be incredibly useful, but it’s not nearly as trivial as the previous parameters listed. Some tools make geocoding and “within X miles of Y” type searching very easy. Still, this would raise the barrier of entry. Perhaps it could be an optional filtering scheme that individual sites could implement, but was not required in order to be compliant with the protocol.
Probably the largest hurdle to LGP would be getting the individual sites to share their data. For the larger sites, their userbase is their most valuable asset. Making it freely available might not seem in their best interests. However, it’s obvious that from the users’ perspective, LGP makes a lot of sense. Once the user data becomes a commodity, the sites will be forced to differentiate themselves based on their other features. For Obsidian Portal, that should be easy.
Still, joining up and sharing your data should generate a lot of traffic back to your site, and therefore signups or purchases or whatever else you count as a conversion. This is because the primary way of contacting a user will be through their profile page, which most likely exists on the site that provided the data. You could even require that someone sign up for your site before they can contact anyone, although that might be sort of a jerky thing to do.
Everyone implementing LGP as a provider would need to make this very clear to their userbase and give them the ability to opt-out. In fact, perhaps opt-in would be a better policy, forcing users to specifically elect to be include. Still, why would they sign up on a player matching site in the first place unless they wanted to be found? I imagine most users would jump at the chance to be included.
The main issue with privacy that I can see is related to the geographic data that is passed with the feed. Giving out your address on the Internet is generally considered a Bad Thing, and this is no different. To that end, here are a few approaches.
First, you could restrict the lat/lng to a city area only. Therefore, you pass nothing more specific than a user’s city. The obvious downside is that for a city like New York there would be thousands of identically located entries. If you tried to map them, it would end up a mess, with all stacked one on top of the other.
Second, it might be possible to include an intentional error into the geographical data. Instead of feeding out the user’s exact coordinates, the system could give a random point within X miles of the user’s actual location. This would effectively mask their exact location, but would probably be very complicated to implement. Further, users would jump around on a map every time it was refreshed. Not a great solution.
Finally, the solution I propose is to pass the onus of anonymity on to the users. When asking them for address info, make it clear that they are not to enter their exact, home address. Instead, ask for nearby landmarks or street intersections. The Google Maps geocoding API is good enough to translate such strings into lat/lng coordinates. This would allow the users to accurately place their location, while at the same time assuring their anonymity.
I am already signed up on multiple sites, and I imagine there are others as well. So, if all the data were aggregated, I would appear multiple times.
For now, we’ll punt on this issue from the LGP perspective. Individual consumers are free to try whatever de-duping mechanism they think will work best, or just forget about it. I imagine that even very dumb de-duping (ie. throw away all hits with the same name within 1 mile of each other) would be pretty good. Plus, unless people routinely sign up on 50 different sites, it won’t be a huge problem.
Ultimately, it would be nice to have a central registry that assigns unique identifiers, but trying to establish such a registry would probably be more work than it’s worth at this point.
I’d love to hear feedback from anyone interested. Protocols like this only succeed if they achieve wide adoption and serve everyone’s needs. So, if I’m unfairly excluding someone, or I’ve missed something from the main list of goals, let me know in the comments. I will update this post over time as we come up with new ideas.
By no means is this document meant to be an academic discussion or pointless pontification. This is a very rough draft of what I hope will be an actual service that users can interact with very soon. So, I will go ahead and make a challenge to my fellow site owners: Let’s finalize a spec for LGP by December 2007, and have it implemented on our sites by Christmas (Dec 25th). If we could help our users find someone to game with over the break, it would be quite a present.
For my end, I solemnly swear to have Obsidian Portal implement at least the provider side within 2 weeks of the spec being finalized. I feel comfortable making this promise because I know just how easy it will be to do. Heck, it will probably take less than 3-4 hours to do the actual programming.
To any actual gamers reading this, you have a job too. Go back to the sites that you’ve registered on, post some links to this article, and demand that they support LGP. Tell them that by supporting and participating in the network, they will greatly enhance the user experience on their site. Believe me, once the users start demanding things, it gets very hard to ignore.
The Atlanta Ruby Users Group (ATLRUG) recently moved their meetings to a much friendlier location for me. Rather than heading up into the forbidden north of Atlanta, it is now being held in the convenient location of Tech Square in Midtown. Of course this probably means nothing to anyone reading this from outside Atlanta.
In any case, it was a really great group, and they were very welcoming to new people, of which there were very many. Following the free pizza and pre-meeting chit-chat, we saw two presentations.
First up was Stephen Touset with a talk on metaprogramming. This is what is going on behind the scenes with all the method_missing stuff. Probably the most well known example would be the dynamic finders (ie. “find_by_email_and_username”). Stephen delved deep into metaclasses, and it was fairly confusing. I’ve dealt with class_eval and such before, but mainly from a “copy someone else’s stuff and modify to suit” sort of way. As I said during the meetup, “It’s possible to do metaprogramming without knowing what you’re doing.”
Mark Percival followed Stephen with a presentation on Nginx, a fast little web server. I’ve always been a fan of Apache, but mainly because I felt safe with it. Even though it was a pain to configure, I knew that if I ever had to ask “How do I do X on the web?” then the answer would be in Apache language.
However, it never occurred to me that it might be overkill. As Mark explained, if all your Apache server is doing is proxying to mongrel, then it’s a big hammer for a tiny problem. The memory footprint is fairly high, and the configuration is a pain. Face it, Apache is not very friendly.
Mark claimed that Nginx was friendlier. To be fair, the config file was shorter. However, it still looked fairly arcane to me. I guess easy is in the eyes of the beholder.
Still, the memory issues are something I can’t ignore. Obsidian Portal runs on a VPS from Rimuhosting, so memory is a scarce resource. If I can reclaim enough memory to run another mongrel instance, that would be quite a coup. However, the real offender on my VPS is Tomcat. What!?! Tomcat!?! Well, I needed something to run Solr, and Tomcat is the only servlet container I’m familiar with. So, even though it’s a memory hog, it’ll have to stay for now.
All in all, the meetup was great. As I said, everyone was very nice, and all seemed fairly down to earth. There were no pissing contests over who was the better hacker, and newbie questions were answered honestly and humbly. I can’t wait until next month’s meeting. Maybe I’ll even try to scrape something together to present.
Recent Comments