Friday, May 28, 2010

iCame iSaw iPad

iPads appeared in Canada today. Last month, I was at Drupalcon in San Francisco and all the cool kids had iPads. They were enviable for more than the cool factor: they have VERY long battery lives (upwards of 10 hrs.). The display is crisp. Landscape or portrait is up to you depending on which way you hold it. With laptops, you have to be nomadic: travel and squat. With the iPad, you can cradle it like a steno pad. If they had a camera so that you could see where you were going, you could nestle the iPad between you and reality as you walked down the street.
I was next door to a Future Shop today. I decided to pop in and see if any were being demonstrated. They had models ranging from the 16GB for $549 to the 64GB for close to $800. The basic model had solely wifi, the top end could run with 3G or wifi. The downside of the 3G option is that it needs to be coupled with a data plan from a cellphone company. Given that Canada's data plans are notoriously lousy, I think the upper end iPads are a gateway drug.
I tried out a few sites. The iPad did very well with Youtube and Vimeo videos. Because of the Apple fear of the right-click, I couldn't find a way to right click those pages and see if they were running under HTML5 (I presume. Am I right?) or that there was a truce between Apple and Adobe.
With such a rush on the iPads, Future Shop was out of stock on almost all of the units except for some of the high end ones. I have some ideas where you can get yours. Even though Amazon is keen to push their Kindles, they do have at least one Apple iPad available. As soon as I find more ways to get your iPad despite the short supply, I will post that information here.

Thursday, May 20, 2010

Troll Bane 2.0

Are you bothered by a chimp who's occupation is "Destroying Blogs"? Here's some troll bane aka chimp bane. We may be up against the same griefer. Regardless, here's some ways you can address trolls who are provocative, but are solely abusive.

Step 1: Stop Using Blogger - It is feature poor. Do you like the irony of reading that at technicalmike.blogspot.com ?
Step 2: Identify your threat. Get their IP address and tie it their location. This one was an employee at a company spilling bile across the web. When you go to their web address, 173-15-205-181-BusName-Richmond.hfc.comcastbusiness.net, you get a Sonicwall screen. Sonicwall is a fairly pricey anti-spam device. The people at this IP address either stole it or bought it for their business (I'm going with Option B).

When you get the GeoIP for this address, you get a business on or near, Westhover Rd., Spottswood Rd. Shirley Lane, or Berkley Lane all in Richmond Virginia.
So: how many businesses are in this area? http://maps.google.ca/maps?f=q&source=s_q&hl=en&geocode=&q=37.5409011841,+-77.4801025391&sll=38.039439,-78.484955&sspn=0.488876,1.234589&ie=UTF8&ll=37.541498,-77.477303&spn=0.00769,0.01929&t=h&z=16&layer=c&cbll=37.541582,-77.477263&panoid=JUhZkSj9kliugaHHbcY3yg&cbp=12,303.17,,0,5

IP Address is 173.15.205.181
Location : Richmond, VA United States
Lat/Long : 37.5409011841, -77.4801025391
Host Info: 173-15-205-181-BusName-Richmond.hfc.comcastbusiness.net

Step 3: Complain
Send something to complain to the police in the area (eg. http://eservices.ci.richmond.va.us/applications/RichmondGovContactUs/ContactUs.aspx?ID=26 ).

I put this phrase in:
"I do not know if there are statutes in the Richmond jurisdiction relevant to his online behavior. From what we can gather, this individual celebrates that they have been carrying on this practice for over a year http://www.blogger.com/profile/05463578513662596035"

Then I lodged a complaint with Comcast, the ISP facilitating this communication.

Comcast numbers
1-800-527-2222 (Pittsburgh-- the right locale to contact to lodge your complaint against an East Coast troll)
or
703-823-3000

Tuesday, May 18, 2010

How the Orcs Learned to Trounce the Humans

I used to play alot of Space Marines-- the epic scale one where thumb-sized tanks would unleash fury vs. alien hordes. I learned then that you need to concentrate fire power. If you injure 50 infantry, you end up with 50 po'ed soldiers who are limping but still capable of shooting back. If you use the wolf pack concept-- lots of concentrated fire power on a small number of targets you can nail the target.
The same is true with marketing. I have alot of blogs and subject specialities: dieting, cooking (funny duet there), technical stuff, angry man rants, short cuts, property histories and on and on. Much of this stuff didn't fit together, so I split it out. The problem is that I was making a lot of wounded soldiers when I should have been wolfpacking down the traffic. My traffic and ad revenue used to be respectable-- much less than I wanted, but more than nothing. Nowadays, there's nothing happening: my traffic and revenue is flat.
I divided content into specialty blogs: the "Way Too Fat" blog because I was, well, way too fat and working to remedy that. I did a Viridian blog because I'm a Viridian. I had all of these specialty areas. None of them got traffic.
I tried to reproduce content to see if that could spark traffic pooling. Big Mistake. I knew it was a mistake, but I was emboldened by a thing at work, where we had pages of lists cut this way or that. Google was crawling these lists like you wouldn't believe and causing some big traffic climbing. Somehow I discovered velcro when I was researching for teflon.
So, now, I am going to do a big about face. Until future notice, www.thosedewolfes.com is down for the count, pending a redesign. I torched it before it could any more damage.
If something has a corporate leaning, it will eventually go into www.thosedewolfes.com. "Corporate" carries two meaning here. If it is for my company, "Those DeWolfes", then the content will go there. If it is something regarding my wife and I (the collective entity that is at the core of Those DeWolfes), then it will go there too.
If something is supposed to have a lot of contribution from others, then it will remain as its own animal. In one example, cooking, I'm going to have it both ways: my site will feature cooking/recipes and it will contribute to a multi-user site, www.clearyourplate.com.
So my commandments / decision tree for where something goes:
- If it's timely: a blog
- If it's mine and semi-timely: my personal site, mike.dewolfe.bc.ca.
- If it's part of the business stuff: www.thosedewolfes.com.
- If it's collective, like Jumping Moose, MediaNook or Clear Your Plate, then it will stay as is.
- If it needs coding (like some dynamic element), then it will not go on a blog.
- If it's experimental and nifty, likely it will go onto Prefab Site.

The goal of this strategic shift: concentrate traffic under a few domains; make dynamic content possible where desireable; make fewer sites more popular (aka don't date 2 fives, go for 1 ten).

Have you had a lot of blog and gone through the die off to aggregate traffic? Have you gone the other way with lots of feeder sites and success from each?

Monday, May 17, 2010

Mongo Want Candy!

I have been interested by the concept of NoSQL. Having lived and breathed relational databases for the last 12 years, an alternative could be welcome. Then Mongo rides into town. The MongoDB is a relatively new database system from the NoSQL movement. The NoSQL concept reemerged after Eric Evans and Johan Oskarsson did work on Last.fm. They wanted to organize an event to discuss open source distributed databases.

NoSQL architectures provides weak consistency guarantees such as eventual consistency. That's the "E" in the BASE concept, as opposed to the ACID concept that seemed to be the way to go.
NoSQL systems find it easier to deploy distributed architecture, with the data being held in a redundant manner on several servers. That allows the data services to be scaled up easily by adding more servers.

Here's how I got Mongo to come to town:
I went to the Mongo site.
I went to the repository and downloaded the MongoDB engine that I needed. The suggestion is that you put MongoDB into the root and make C:\data\db to hold the data.
I'm using XAMPP on my Windows machine. I got the PHP version, (5.28-- so, 5.2x what the flavour of Mongo I wanted).
I got the drivers I needed from the PHP drivers page, choosing the 5.2x thread-safe driver. I downloaded it, installed it so that the appropriate dll would be in my php/ext directory.
In Apache, I modified the php.ini. I added two lines:
extension=php_mongo.dll
extension=mongo
(both lines seem to be neccessary).
I restarted Apache.
Most important: I started Mongo. It doesn't hang in the BG, or fire up in response to the driver calls. I had to go into the MongoDB/bin/ and execute mongo.exe to get it to be resident.
Voila: I had Mongo available for tinkering. Next, I did lots of trolling through the slim documentation on Mongo Reference on PHP.net. Fairly quickly, I was able to store and find data. Some things (see below), eludded me.

Some of the upsides:
  • Schemaless. This is HUGE. When you hold two records side-by-side, one is an array with two cells, the other can be an object with 100 properties-- both in the same table. This doesn't make data management a cakewalk. If you put inconsistent data into a database, you have to find a way to fish it out later. Every so often, I've been tasked with holding complex data in a database. MS Access has sub-tables and I groan in harmony with the creaks from their engine when a sub-table is deployed.
  • Fast. Benchmarks differ, but simply put: MongoDB is fast. I think it's easy to figure out why: most of the chaff from MySQL is not a factor in Mongo.


Some of the downsides:
  • Baby's Got Back. My database has 40 records, none with more than 400 characters of information. The database's file size is 84MB. For less than 16,000 characters of data, that seems like a LOT of overhead. Were I able to find an ISP with small account sizes, it would be hard to get this much space for this little data.
  • Libraries in loose clay. I tried to make use of the PHP library of functions. The expanded functions were not recognized in PHP 5.28 even after adding the library and extension.
  • I was able to insert and find records. When I tried to use the $in function-- possible and functional for the MongoDB client (console side)-- it worked fine. When I tried the same from PHP, no dice.
  • Like is there no like? LIKE is a really sloppy call in MySQL. Every time I use it I wince a little (net effect: I wince a little alot). There is no apparent equivalent in MongoDB. Correction: There is a regular expression statement that's easy use
    db.customers.find( { name : /acme.*corp/i } );
    It works well and it's very snappy. No longer do you need to figure out how to do LIKE statments as well as regular expressions. Now, the better question I need to figure out: how to make a phrase like the above work into a PHP statement.


Some of the changes (I think neither good nor bad when you do the calculus):
  • No JOINS. MySQL performance falls apart when you do joins. Joins are the Achilles-heel of Drupal that relies on them so heavily. It's understandable why, given how much data has to be joined and compared. Yet DBAs the world over always atomized and isolate data, then combine the data for the end result. There are two ways to banish joins:
    a) use MongoDB that doesn't have the capactity to do joins.
    b) use MySQL and repeat data in different tables to commit to a practice of fewer joins. When you absolutely have to break this rule, you can do so at the cost of a performance hit.
  • No configs. I was intrigued by the concept after having wades through all of the tweaks you can visit upon MyISAM and InnoDB settings. I think MongoDB's "no config tweaking" will go by the wayside within a year, when somebody out there cranks the performance by messing with some environment variables, maybe even a variable outside of MongoDB itself (like putting the MongoDB on its own disk).
  • Easily create databases and tables (aka collections). This is one innovation that really balances out as a net zero. By calling a database or collection, you create it if it doesn't exist. That is so very easy. But, how many times do coders trip over typos? If you took out typos, you could remove maybe 20-40% of your debugging time. MongoDB doesn't bleat when you create a database or collection with the wrong name. Worse than that, it allocates megabytes of disk space. Your data could accidentally end up in a sink hole. With MySQL, the errors would bleat out and give you something to repair. This could mean that development may have choppy waters, but the application in production may have an easier go of it because of the MongoDB performance benefits.
    Here's what I think the recipe for disaster could be:
    Ingredients
    • 1 coder who names a collection in a client side variable-- or makes it dynamic: available for the user input to generate.
    • 1 hacker who finds this numpty practice
    • 1,000,000 exploits done automatically.
    Bake for a few short minutes when nobody is watching.
    Yields one web server out of disk space.


Questions:
How do I do an $in in PHP ? The suggested attempt failed.
Can I do a LIKE equivalent in MongoDB?
Dreamhost says it hosts MongoDB. Are there any other places that allow MongoDBs?



ACID - Atomicity, Consistency, Isolation, Durability. A set of properties that guarantee database transactions are processed reliably. The concept of ACID is to evaluate databases and application architecture. In the context of databases, a single logical operation on the data is called a transaction. For example, a transfer of funds from one bank account to another, even though that might involve multiple changes (such as debiting one account and crediting another), is a single transaction. Back to top

BASE - Basically Available, Soft state, Eventually consistent.
BASE, as the acronym denotes, is opposed to ACID. ACID is pessimistic and forces consistency at the end of every operation. BASE is optimistic and accepts that the database consistency will be in flux. Easy to achieve with BASE, impossible to consider with ACID.
BASE can accomplish availability despite partial failures, hence the "Basically Available." Soft state means it's in flux and is non-deterministic. Eventually consistent means that if one data source doesn't report what you'd expect, eventually the data would propagate and become consistent throughout the incarnations of data no matter where it's replicated.
Back to top

ACID vs. BASE - I think that ACID may be impractical to guarantee. And, it may be unimportant at the end of the day. Following the Buddhist concept that "all things are impermanent", you can have inconsistent data today because in 100 years, no one will care about the data; or it will all come out in the wash.
I saw this one annoying talk on the topic. The speaker said, "so your comment goes missing... [exasperated pause] Who cares? [room erupts in laughter and applause]." He didn't care because the comments would appear eventually; or who cares: it was just one comment and could have been lost through network connectivity. I thought it was really amusing that the author of some of the most inane comments I have ever read would be ambivalent about comments. When you look at the river of news, you can miss something. If it's important, it will come around again. That arrogance towards data is at the core of BASE, like a technical concept founded on sloppiness. I would prefer to cherry-pick between ACID and BASE. ACID when you're handling real data (transactions, comments, content). BASE when you're dipping into the river (news reproductions, live video, etc.). Back to top