Jackson's Blog

It has become increasingly popular for artists to be ranked by their YouTube view counts. This article is written to help my readers best utilize their loyal fan-base.

Understanding the System

YouTube is no new kid on the block when it comes to “spammers”. They’ve had to combat a lot of “artificial views” brought on by a lot of over-enthusiastic viewers. So they’ve developed techniques to combat view count spamming (YouTube View Count Announcement). For the most part, they want to ensure that whoever views their videos is a real-world individual and not some script or robot, which is understandable.

Definition of a View

If an individual hits the video, and watches the video for more than 50% of its duration, it’s considered a view. If the individual hits the webpage repeatedly, any view beyond his first is not counted.

Web identification of an Individual

For the most part, an individual is identified by their IP address on the web. At the time of writing, no matter how you slice it, you’re going to have a hard time discerning multiple entities are the same individual if he has multiple IP addresses.

How to Increase YouTube View Counts

Tiny Urls

Your viewers might have multiple means of accessing your web content, friend’s computer, school computer, home computer, work computer, library’s computer, cellphone, and etc. You might as well make it easier for them to have a short URL to type into their device than the long one that YouTube gives you. This is where Tiny URL comes in (Tiny URL).

Tiny URL is a web service that takes a full URL, shortens it, and provides you with the shortened version. Which you can then use on the web to refer to your content.

In-network marketing

You want to invite all your friends to help you, and you want them to invite all their friends and so on. Facebook, Twitter, and MySpace are all popular mediums to accomplish this goal. What you want to do is go online and find some bookmarklet to allow you to easily invite all your friends and allow your friends to easily invite their friends to your activity. I won’t go into great detail but one example is Facebook.

On Facebook, you can create events, which you can invite all your friends to. Then have your friends invite their friends and so on. Facebook has made it insanely painful to invite your friends, I guess to thwart spammers, unfortunately, you have gotten caught in the cross-fire. Fortunately, bookmarkelets, easily reusuable and bookmarkable Javascript code, has come to the rescue. For example the following webpage links to a site that provides a clever little bookmarklet that can invite all your friends.
(Invite All Facebook Friends Bookmarklet)

Informed Fans

An artist is only as strong as his fans. The more able his or her fans are, the more able he or she is. For the most part, make sure your fans are aware of all the ways they can increase your view count (See Tiny URL section). The fans might have the enthusiasm, but not the means, this way, they can have both.

If you follow the steps listed above, then you have effectively utilized your fan-base, and the rest are in the hands of the greater powers.

The Dark Side: Hacking YouTube to artificially boast your view count

If you’re a decent computer nerd, and you’ve read this article, you know what you need to do…

A lot of people don’t understand why object-oriented programming (OOP) practices are getting so much hype. While I can’t explain all the benefits of using OOP in this article, I will cover one of the compelling cases of using OOP, you save time.

Imagine a scenario where a new recruit has just joined your ranks. He was hired into your team to speed up your project. If your code wasn’t designed in an OOP manner, then he’ll most likely have to review a good chunk of the code in order to figure out what’s going on and how the various pieces interconnect. Some code at line 23 might be affecting line 83. Some function might take 2 integers and behave one way, and then take in 3 arrays and behave another. The code might also require certain global parameters to be set in a certain sequence before things can function.

In OOP programming, things you don’t need to know, you don’t need to know. For example, if you were coding a shopping cart, the “scanning system” only cares to know about the price of the item. The “product” object only needs to know it’s “price”. The “shopper” only cares about the price and the total. Each of these objects can have various complex behaviors, but they’re all encapsulated within the object. For example if the “product” was perishable, and price was a function of it’s expiration, the “scanning system” and “shopper” doesn’t need to know about this. If you were to adjust how various item’s price fluctuates, you only need to focus on “product” classes.

Whereas, in a non-OOP class, you might a very long file, class, or function, and it might be filled with all these complex checks to figure out how much the price is, but in an OOP system, the “scanning system” simply asks the “product” for it’s price. OOP code is also more intuitive, since OOP mimics real world objects and relationships.

OOP practices are good to adopt, although there is some overhead, there will definitely be long-term savings in more ways than one.

I believe that code-base no matter how well written are doomed to the fate of eventual obsolescence. No matter how well the code is constructed, there are bound to be unforeseen edge cases that can have a minor or major impact on your code. If your business  decides to take the code to a whole different level, you might need additional functionality that the code-base didn’t account for. “The best laid plans of mice and men oft go astray”. Businesses need to plan for this case, and allocate the resources accordingly.

It’s possible for your code to absolutely perfect and NEVER EVER require change. You might even conclude it might be a Microsoft only thing, but think about it this way. How often has Microsoft, Apple, Linux, Facebook, Myspace, and Google changed their code? Quite often, it’s almost like every few years, some major change occurs. Windows XP was recoded into Vista, and Windows 7 was Windows completely recoded from the grown up. Changin not only the look, but the security and functionality.

Code changes because they business requirement changes. Business requirements change because the customer’s demands change. Time changes a lot of things. So you have to ponder, if your code-base is an exception to the rule. Chances are, it’s not. If you don’t plan for the team to completely recode the code-base every few years, then you’re going to force yourself into an immobile position where your customer’s demands have changed, but your business  can’t respond to accommodate it.

With each new core product system, you should keep track of how long it took to develop it, make sure it’s well documented, and budget some time in the future to reallocate this amount of time to reinventing it. Yes, reinventing. Is this a direct violation of the DRY principle (Do not Repeat Yourself)? No. If it was exactly the same product, sure, it’s a violation, but since you’ve introduced new parameters, the no. Do you use the same method to do single-digit against single-digit multiplication as you do double-digit vs. double-digit, triple-digit and so on? No. Code should be no exception, plan accordingly, or face some interesting crossroads in the lifetime of your business.

Your testing sandbox can be flexible or immutable. I have a preference for designing testing systems that are flexible. Data that is generated via the testing process, can be modified through the testing process. Everything flows the same as a live system from beginning to end. There are developers who would disagree with this approach, such as we’re giving the testers too much control that can allow testers to generate cases we didn’t expect, which can cause some amount of embarrassment. Another argument is that with fixed data, we don’t have to worry about as much, since we pretty much control the entire flow. While the counter-arguments have a legitimate point, I would argue that their limitations defeat the purpose of a testing system.

A testing system should be a sand-box, as in implied in the term “sand-box”, testers can play around with it as much as they want. If we made the data immutable, it’s not really a sand-box, but more like buttons. If a person relying on your system have a lot of unique demands on your system, your system will not be able to handle it without changing code or system structure. In fact, you’ll need to implement a whole layer just to handle the immutable data and how to handle the response. If you were to allow the system to be flexible, and the objects mutable, or changeable, there will still be layer, but that layer will be deeply tied to existing components, which will still allow existing components to be tested. While the first case, although you can still have existing components tested, such testing is pointless, since you’re forcing a set response to a set data set each time.

Flexible testing systems allow you to fulfill the demands of any tester easily, since they’re pretty much testing how their system interacts with your system, and it closely mimic normal behavior. Not only that, but it also allows testers to test your system for flaws, helping point out flaws in your system before the flaw does any major damage. In an immutable system, we don’t have to worry about edge cases we didn’t account for. Which can be great, but unfortunately, a flexible system can handle the tester’s system that was design to deal with immutable or mutable data. In an immutable system, if the tester wants mutable data, we will pretty much junk the existing system and create another one. Turning a flexible system immutable is easy, turning an immutable system into a flexible system is hard. Much like procedural code versus object-oriented code, procedural code is pretty rigid, but object-oriented code is pretty flexible. “Be water, my friends.”

As of writing this article, the site for filing businesses taxes online at https://latax.lacity.org/laweb is broken. I’ve tested the site across 3 browsers, chrome, firefox, and IE, and none of them will pass the professional activity code validation check. I’m amazed that such a bug could’ve even passed a decent QA process. In fact, when the user e-filing throughput has dropped significantly after the code release, that should’ve been an instant red flag. I was able to e-file anyways, but I definitely had to bypass the 6-digit activity code violation, even though I did enter a 6 digit business code.

So how was I able to e-file despite the bug in the code? The answer is “Firebug”. So the trick is, whenever you encounter that invalid 6 digit professional activity code error message, you pop open firebug, modify the form’s “onsubmit” attribute, and blank it out. This way, it’ll be programmed to bypass the validation, and that’s it! I’m still annoyed that I had to do that though.

City of Los Angeles, if you’re reading, you can hire me to fix the site for you, I’ll get it done in 5 minutes, and you can just not charge me tax for the next 10 years.

I think one of the hardest things about being a programmer is working with code that you’re not familiar with. You can spend hours, days, weeks, months, trying to understand the code that someone else wrote. I used to think that if a person who can’t read through my code and fully understand what my code is trying to accomplish, they have no right to call themselves a programmer. It wasn’t too long before I realized that my belief was wrong. To be a good developer not only do you need to be able to finish a project according to specifications, it must be well-written, and maintainable by others.

By maintenance, it means that a new comer can quickly figure out what’s going on without costing him a lot of time. Maintainability can be accomplished in many ways. From the way the code is structured, the way it’s documented, to training, and etc. Today, I plan on discussing code structure.

I’ve seen enough code to fear arrays that are pretty much the member variables of a object. Except all those member variables have been consolidated into a single array, and that single array is populated by a single function at run-time. This is a surprisingly common practice, I guess there are some up-sides to using this technique, the class that uses this technique will have less code involved, and code that calls this function would probably not change very much.

Now for the down-side. Someone down the line might find a need to modify the function, lets say “foobar”, so that it does more things with that data. Then somewhere down the road, someone else decides to make the array multi-dimensional, and then someone else somewhere down the line decides to make the foobar function handle the multi-dimensional array in multiple ways. You can explicitly tell programmers verbally or through documentation to use a single-dimensional array, but more times than not, things simply won’t go as planned.

With objects, you can create the function to handle a specific object type, through strict-typing. That type will have certain member variables set, which you can always rely on. It will be the same consistent structure, no matter what. This way, you’ll save yourself from dealing with function parameter input fowl ups.

What if you required the unique functionality of the multi-dimensional arrays? There are many ways to go about it. You could create a different class that extends the class that contains foobar. Although, that function would most likely need to be redefined. One example of a possible redefinition is to have the new foobar function take in the multi-dimension array you provide, but create the objects required by the parent foobar function and handle the result accordingly. The code for the class that performs foobar using objects and foobar using multi-dimensional arrays remain separate. You can alter the code to handle the various situations accordingly, if the functionality for multi-dimension foobar changes, you only have to alter the multi-dimensional array version. It might take more lines of code and more time, but when you revisit the code, even after a long period of time, you’ll find it very easy to maintain because all the logic has been keep separate. Each class, each function, all the various interacting components serve a very narrow and specific purpose.

I might add some code examples to illustrate the point at a later time.

Well written introductory documentation starts by first understanding the purpose. The purpose of the document is to get the reader to become acquainted with whatever you’re trying to introduce. Not only that, but one should keep in mind what they wish to accomplish by introducing the topic. This would help organize the overall direction of the paper.

After you have a good understanding of what you’re trying to introduce, and what you hope to accomplish by introducing it, you can then start with the major topics.  These major topics can then be broken down into smaller sub-topics, and those sub-topics into smaller sub-sub-topics.

Any and every topic should have an introduction and a conclusion. Sometimes, even be better to write out the introduction and conclusion first, and fill in the rest later. Having an introduction would save a person from re-learning information he is already aware of.

If the topics are absolutely independent, then you’ve written a referential document. Examples of referential documents are dictionaries, encyclopedias, and cook books. Each topic is independent of each other.

An introductory document progressively builds the reader’s understanding, and finally arrives at the original destination it intended.

Well written introductory documentation can aid a person who knows nothing about a topic into becoming well-informed of the topic. A referential documentation can aid a person who is well-informed of a topic in recalling things he has once learned. Understanding the difference between the two will be beneficial to any type of written communication efforts.