Twitter recently remade their crossdomain.xml file very restrictive, allowing only apps on their own domain to access the api content. Unfortunately, this makes Flash applications throw Sandbox violations so no more Flash/Twitter mashups. Apparently though, they aren’t above the possibility of selling access though. Discovering radiance? What the? Apparently, there’s a real security issue involved (flash 9, what’s new!?) but it’s a bummer b/c I really liked my little app that I made for my new site. Next up: Ben scrapes his twitter content, saves it locally. ;)
I’m working on a project where people have profile pages and we need to show a counter for how many views they’ve gotten. I saw two ways of doing this:
- Create an MySIAM table and everytime there is a view, insert a new row to represent the view. This could be nice because adding a timestamp would let you track views over time. Or stuff like IP address. To see the total, do COUNT(*) across a given user_id.
- Create an InnoDB table with a row for each user and a column that represents the count. On each view, do an update and increment the count. Then read that number out as the total. This seemed good because I wouldn’t have a single table with a HUGE amount of rows.
Google didn’t help me find any direction so I made a test. I created a table for each. In the case of the MySIAM I filled it with 10 million test records. Then I echoed out the total.
The result I found was that they basically take the same miniscule amount of time. Because I indexed the MySIAM on the user_id it optimizes really well and doesn’t seem to care that there are only 1000 views per user amongst the 10 million. Only how many views a user has. So a user with 10000 views takes longer to total than one with 100. I’m going to go with the MySIAM since it is storing richer data that may be useful down the road. Figuring I can switch to a InnoDB implementation later if I need to.
Check this out, I love the serious model pose combined with the silly, nerdy shirt:
After working with Mootools a bunch on a project (2K), I think I’ll be sticking with Script.aculo.us for GC. The main reason for me comes to down to documentation, but there are some peripheral reasons.
For it’s DOM stuff, Script.aculo.us uses Prototype out of the box and I think Prototype has AWESOME documentation, the pillar of what everything should aspire to documentation wise. For it’s effects, Script.aculo.us uses a wiki. Now I don’t think this is great (I don’t love the wiki look), but the way the pages are written up do make them more approachable than Mootools. With Mootools, there aren’t a whole lot of examples and I got the sense to really get good with it, you had to use undocumented properties and methods. It felt like a class I would make ;) Plus, many of the wiki pages include functioning examples inline, which Mootools relegates to another non-exhaustive section.
I’m also gonna use Script.aculo.us because I like how it’s effects have a delay property, which is super handy. And it uses the existing CSS properties as it’s starting point for animations. And it has more (and more useful) built in effects.
The main reasons I would recommend Mootools over Script.aculo.us is that their download page is the sickest thing ever and it’s domain isn’t a pain in the ass to type. I HATE the name. I hate having to use command-v over and over again to insert it into this blog. Also the Mootools site is more slick looking. But these aren’t really reasons to use it over Script.aculo.us.
I installed the IE 8 beta in my Windows XP virtual machine today and now have an environment for testing IE 8, IE 7, IE 6 and IE 5.5. If you want to download the beta, here are some things to keep in mind…
- The IE 8 install overwrites IE 7.
- IE 8 has an Emulate IE 7 button in the toolbar.
- Switching between IE 7 and IE 8 rendering modes requires a browser quit and relaunch.
- If you use Multiple IE to run multiple stand-alone versions of IE, installing the beta may cause your stand-alone versions to ignore IE conditional comments.
- Uninstalling and reinstalling Multiple IE fixes the above issue.
- If you use the full Monte
<!--[if IE]> conditional comment, IE 8 will see it and render whatever is in there.
- I haven’t notice a real difference between IE 7 and IE 8 rendering yet. I have lots of trouble getting past the hideous anti-aliasing, though.
I think I’m fully up and running with a reasonable means to test in all versions of IE. Remember, conditional comments for your various style sheets should be linked thusly (assuming you target IE 6 and 7 together in one sheet and then IE 6 by itself in another one like I do):
<!--[if lte IE 7]><link rel="stylesheet" href="/css/ie.css" type="text/css" media="all" charset="utf-8" /><![endif]-->
<!--[if IE 6]><link rel="stylesheet" href="/css/ie6.css" type="text/css" media="all" charset="utf-8" /><![endif]-->
Remember to use the lte (less than or equal to) operator when targeting multiple versions of IE that are less than or equal to a certain version number. IE 8 passes Acid 2, so you shouldn’t need to serve it any special CSS.
