
I’m continuing to play with CloudDB as the data store for the computerist solutions site. Currently the sidebar links are stored in clouddb, as well as optionally storing most page content in it. Currently, only the home page has its content in clouddb. It’s built so most pages check on first load if content is available in clouddb, otherwise render the normal view.
So all this makes me think.. why not add a users table and go full on CMS with it. I think it would work. So why not also build our own blog engine too. Again, it might just work but it becomes a question of size restrictions. I just don’t know what clouddb will allow/handle. I’ll have to ask the team about it.
Speaking of features, CloudDB is working on the next version. It may get released by the time this gets published. I’m waiting to see what changes there are. There will be JSON support I’m told, which will make be wonder whether to stick with the current webservice method of calling it or move to the JSON method.
Overall, I like clouddb. It’s perfect for the csinc site. It maintains the portability directive because we can host anywhere and still fetch data from clouddb. Plus we have some nice flexibility with the content. It really is an enticing solutions. It took some thinking to centralize the data access and caching, but worked out. Now I’m just waiting to see what clouddb v3 brings.
I’ll probably post again on CloudDB when the next version comes out. I’ll do some code samples at that time. Maybe a working sample project for people to try.
Other Goings On
In other news, I recently found myself considering buying a new vacuum. It was a good vacuum when we bought it but it had lost its power over the last year. Thanks to some random review, I rechecked the filter I thought I cleaned and found that it was actually just the housing for the actual filer. After cleaning it, the power is back! How many times have you felt you code base is old and worn out? Maybe you just need clean it out a bit instead of throwing it away. Add some tests, maybe use clouddb, or refactor some common code. Having made the clouddb changes to csinc, it feels refreshed and not so stale. I still want some more clean up and better testing but I like where its going. ..just a little life lesson applied to work.
blog comments powered by
CloudDb is a web based data store, and it’s pretty cool. I got an invite a while ago from my friend Scott Cate (mykb), but didn’t really dig too much into it. Now if you follow this blog, you’d now we’ve been looking at different data storage options for various things such as content for this site. Most embedded db’s aren’t an option because it’s currently hosted in a Medium Trust environment which doesn’t allow native calls (all the embedded db’s I know require this). That pretty much killed it. We have the option of using mysql or 1 sql server database but we’d like to keep this as portable as possible. Also, there are other plans for that.
But Hey! Why not use a cloud or web based service? We want to be able to manage some content without re-deploying, and a cloud service would allow that. Yes, most of the current content are just stored in view files, but what’s the fun in that?
I’ll probably post more info when I get something together. In the meantime, click the link and watch the videos.
blog comments powered by
I’ve been working on overcoming my own ignorance in using precompiled views with Spark view engine. Making progress, but it’s not been straight forward. It’s not really a problem with Spark, which is why I’m still trying to make it work. It’s just that errors encountered during the post build step to precompile the views aren’t clear. It required using System.Diagnostics.Debugger.Launch() to figure out the problem. Which of course was something stupid I did; put a namespace in the assemblies config section for spark.
So figured that out, and it compiled. Yay! Then I ran it..
It’s probably something else I forgot to do or whatever. Maybe I need to register routes so it knows which views to render. This is why I haven’t yet posted another Spark article. It’s suppose to cover lessons learned with precompiling view. So I should have plenty to cover.
blog comments powered by
I’m specifically choosing the title for search engine results because I can never find this information when I want it. For some reason not many .Net devs seem to know about it, and I always forget the code because I don’t often need it.
1: System.Diagnostics.Debugger.Launch()
This is very useful for debugging services, installers, and other situations when you can’t just start with the debugger.
blog comments powered by
This is going to be blatant praise of Heroku, but I have good reason. I’ve been doing development for a long time now. I’ve done client-server stuff in many forms for almost all of that time, and I’m including web development in that. When it comes to hosting your app, you have some common scenarios to choose from. I’ll list them.
- self hosted server
- self managed data center
- rented rack space
- slice hosting
- shared hosting
- and the current techo-pop.. cloud hosted
I’ve done some for of all except slice hosting. Not an expert, but I’ve learned a couple things. First, there are positives and negatives for each. One thing that gets forgotten is that your hosting choice impacts your technology choices, and vice versa.
It’s less of an impact when you self host or self manage a data center, but there’s a big cost plus in money and maintenance. Obviously, the smaller the hosting package, the cheaper it is and the more limited the performance and storage space. That’s where cloud based hosting comes in. It’s an attempt to let you scale more easily, but development choices get more limited and deployment can be a pain.
That’s not true with Heroku though.
Time out. ..I’m prompted to posted this because of a specific situation. I have a shared hosting account which I want to use to test out small projects we’re working on. The problem is its run under Medium Trust (.Net term if you don’t know). It uses the Spark view engine, so that means it has to precompile the views. That hasn’t gone well. The hosting choice, while economical, has also caused significant development pain to try to get the chose platform to work. Not fun at all actually.
Time back in.. This is where Heroku excels. It’s a cloud hosting service, and deployment is dead simple. You just use git to push your rails app up. You can start with a free account and then buy the appropriate service level from there. Manage your scale, add extra services or features, integrate with Amazon services. It’s all just plain simple. Now I know from the discussion group, that its not perfect all the time. Everything I see is that its quite reliable, and the team certainly is very responsive.
If you are building a rails app.. don’t think, just deploy to Heroku. No stress; should just work. I’d recommend it to any rails shop. ..I’d recommend it to non-rails shops using rails in any way. You don’t get bound into the specific SDK requirements of Google or Microsoft Azure. Even Amazon EC2 has its technical reqs. In just my casual checks, it looks like their pricing is more than competitive too.
I honestly consider Heroku to be a visionary achievement. I don’t think there was anything quite like it when they popped up, and I’m not sure there is yet. A team of devs decided they wanted a scalable rails hosting solution with easy depployment – something that is still a challenge with rails apps in many places – so they built one. How much easier can something be than checking in your files to a repository?
Great job guys!! To all the rails hacks or pros, just go check it out.
Update: I view Heroku as one of the reasons consider using rails.
blog comments powered by
Just looked at my calendar, and realized there is more on there than I actually ever make. It’s become a wall of events I plan to regret missing.
![CropperCapture[34] CropperCapture[34]](http://computeristsolutions.com/blog/image.axd?picture=CropperCapture%5B34%5D_thumb_1.png)
blog comments powered by