what I find most frustrating is that finance institution buy extremely overpriced and brittle software from renowned vendors not because of technical excellence but for risk management: they want a supplier to blame when something goes wrong.
the problem with this is that nowadays suppliers are stronger in defending themselves from such blames than they are in writing good software.
furthermore, the software being sold is very pricey and the cost of customising it often exceeds the cost of the software itself.
then, 9 times out of 10 the issues lie in the customisations, and that doesn’t surprise, as the institution will be using most the custom parts as those are the ones they need most. here the vendors have even more grip in demonstrating that it’s the customer requirements’ fault, and not their crappy software, that confuses the concepts of “database” and “application server”.
I try to counter this by writing solid, robust software using open source components, giving back when possible, perfectly filling the company’s requirements, well integrated and reasonably cheap to maintain. slowly, this can help in abandoning vendors and building in-house know-how.
I find this crucial because the quality of software sold by some vendors is very very low, and getting worse.
I wrote a Ruby library[1] that builds on Active Record and implements SCD-Type 2 using updatable views and INSTEAD OF triggers.
It has its pain points, mostly related to how hackish the AR insertion is, but it works quite well and the approach ensures that any INSERT/UPDATE/DELETE triggers bookkeeping of the history tables.
Oh I really admire Chronomodel! Actually I link to it in my annotated bibliography ([3] above). Thanks for all your work on that! (Also: I exchanged some emails with one of the Chronomodel devs a few months ago. Perhaps that was you?)
For valid-time DML, I think the most useful operation is an upsert/merge. Tom Johnston calls this an `INSERT WHENEVER` I think. I have a not-yet-published Rails project that also uses INSTEAD OF triggers to convert AR saves to valid-time upserts. Hopefully I can get that published soon. I would love to even contribute it to Chronomodel eventually if that makes sense, so that it can be bitemporal.
Although there is tons of research in temporal relational database design, the rest of the stack really needs attention. What does temporal mean for REST and CRUD? Or your ORM? What are good UX patterns for viewing and editing a valid-time history? Can you make save-as-you-type work or do you need a Save button? I'd love to see people start working on that! My own Rails experiment landed on one way, and for me it validated that the db-level features would actually be useful, but there are other approaches possible.
video/image hosting is not the point, it's community that counts here: youtube is just a vehicle to deliver your video to more eyeballs, because poking around youtube is easier for the joe user, rather than poking around the 'net. also, as others have pointed out, bandwidth is cheaper for google rather than for the private VPS that hosts your site.
Actually it uses the flex framework (as you can see by looking at the scrollbars and the tooltips) that then produces an edible binary .swf for the flash player :).
Back to the topic, as a music site developer myself, I can assure you that everything (except streaming[1]) you see on grooveshark can be implemented using XHTML, a JS framework (I love jQuery über alles) and an HTTP backend. Wheter or not do it depends mainly from the target of your audience and the browsers they use, because to achieve 100% browser compatibility, especially when dealing with older IE versions, imposes a bit of headbanging over their quirks and issues. Another point is performance: on older machines, animating big elements on the page (like grooveshark does) causes flicker and a clumsy experience for the user. The last point is maintainability and integration: after all, flash software is another piece of the stack you have to coordinate, implement, integrate and deploy.
So, it's a bit controversial which path to choose; on our project we're following a mix of the two, by reducing the flash implementation to the bare minimum to accomplish streaming, upload (ajax upload via iframe is a bit of a mess) and a set of JS interfaces to implement the rest of the interface via XHTML. Similar to http://playlist.com 's approach.
The last consideration that comes to my mind is purely ethical/political: I prefer to use open standards and contribute back to open projects via source code, and not be forced to use closed technologies and tools and contribute back via cash, having to read clumsy documentation, little opportunity to improve anything, and the list could go on and on.. :).
I may sound like an utopian, but I think that being satisfied in what we do and how we accomplish it is the only goal to target, to be happy and satisfied. One should always seek for happiness through efforts, no matter how hard it may seem: I believe that good ones will always give you back the same goodness you were able to spend, no matter how bad the context is.
I also know that not everyone likes to do its best, and many are simply looking for the "easiest" way, but this implies abiding to some kind of lunch bell, as you described. But you're not this kind of person: it seems that you're still able to dream and tend towards something better.
So, good luck with your future projects and give good karma, you'll receive it back! :).
I think the kind of work that satisfies the deep parts of us ends up being the kind that looks harder and takes more effort.
Being mindful of the present, as you advise, is a good practice in my opinion. They clear up enough confusion to gain insight about oneself. Sometimes, those insight tells you to move on. I don't buy that it is the only goal to target, and one should always seek for happiness through efforts, as those beliefs becomes attachments and delusions over time. They're simply there because someone hasn't gained insight to themselves yet.
Maybe because the average human is inherently lazy and doesn't want to re-learn how to use the new UI? Or maybe because the average human is pleased when something does never change? Or, maybe, because the average human loves being a whiner? :)
the problem with this is that nowadays suppliers are stronger in defending themselves from such blames than they are in writing good software.
furthermore, the software being sold is very pricey and the cost of customising it often exceeds the cost of the software itself.
then, 9 times out of 10 the issues lie in the customisations, and that doesn’t surprise, as the institution will be using most the custom parts as those are the ones they need most. here the vendors have even more grip in demonstrating that it’s the customer requirements’ fault, and not their crappy software, that confuses the concepts of “database” and “application server”.
I try to counter this by writing solid, robust software using open source components, giving back when possible, perfectly filling the company’s requirements, well integrated and reasonably cheap to maintain. slowly, this can help in abandoning vendors and building in-house know-how.
I find this crucial because the quality of software sold by some vendors is very very low, and getting worse.