Tempoc's Dev Blog

Days of a Month

2012-11-14T09:32:00.000-08:00

Here's a little something that's useful. Just give me some credit for putting it together. Syntax is in Java, but it should be translatable to your favorite language.

Given the month number, m [1, 12], and the 4-digit year, this calculates the days of the month.

return m != 2 ? (((m < 8 && m % 2 != 0) || (m > 7 && m % 2 == 0)) ? 31 : 30) : (!(year % 400 == 0 || year % 100 != 0 && year % 4 == 0) ? 28 : 29);

Google IO 2012

2012-06-25T15:29:00.000-07:00

I'll be following some of the live sessions of Google IO 2012 and being a loud-mouth if I feel like it. You can watch it here and follow any Google announcements, and get the commentary.

Android: Cutting edge tech 2 years behind

2012-04-03T14:54:00.002-07:00

iOS and Android have never been at a loss for die-hard fans, but ever since Android was introduced they have both been competing for the virgin customer. In my opinion what dispenses points of market share one way or the other boils down to 2 things: Who strikes first, and the impact caused during that first strike. When it comes to technology they constantly outdo each other. But what, from the jockeys' seat, might look like a daily photo-finish actually looks like Android never left the gate, to most bettors.

Some History

When Apple came out with the iPhone in January, 2007, it certainly was a game-changer, but being the first of its kind also meant that some lessons would only be learned with time. Some things were foreseeable. Clearly Apple was planning to roll out more apps as time went by. Some other things escaped Apple's foresight. During the first 2 years Apple modified the OS to devote more resources to call handling, changed the keyboard to allow multi-touch key presses, and introduced much desired features like a dedicated Gmail account type button in Settings.

Android's roll-out was in many ways analogous to that of iPhone OS. The first Android phone didn't reach the market until September, 2008, and although then the difference in capabilities between the two platforms was vast they've matured technologically to the point where they are more or less evenly capable. For the record, this article's focus is not the difference in original roll-out dates of the platforms.

Android's Permanent 2-year Lag

The case of the virgin customer is unique. Whatever the phone selected the customer is likely to be pleasantly surprised to find what a phone has become. And if the customer is like most mobile phone owners he'll be tied to that piece of hardware for 2 years or pay a premium to change it. So why does this only affect Android negatively? Strategy, or lack, thereof.

When a customer purchases an iPhone he can't make a wrong choice. There's only one choice (in 2 colors, 2 memory capacities). There won't be any guilt associated with having selected the wrong device. Even better: he can rely on Apple's track record to hope that, although the hardware will look two generations less tasty in 2 years, the manufacturer won't consider his phone obsolete during that time and he'll be entitled to prompt bug fixes and releases of the best features his hardware can handle. Warm and fuzzy at no extra cost. Your phone may come to be 2 years old, but it will never feel quite that old.

If the customer purchases an Android device the experience is the opposite. Many flavors to choose from, from a choice of manufacturers, most with a good portion of bloatware, some with spyware right out of the box. Of course no one will tell this to the customer before the purchase, so some guilt is included for free with every purchase. But wait, there's more! Even after Google tried to get manufacturers to make a commitment to keep the phones regularly up to date with reasonably recent features and bug fixes the task is easier said than done and probably not policed. Your phone may come to be 2 years old, and it will most definitely feel 2 years old.

But but but... Ice Cream Sandwich (Android 4.0) is awesome! Yes. But it was ready last year. When you finally find a phone with it on your carrier it will already be last year's OS. It will have bloatware. It's software, so it will have bugs. But fear not: since you will never see an update from the manufacturer they will never be fixed on your phone.

Wake up, Google!

Google's web browser, Google Chrome, has been gaining market share with very little resistance. This would not have been possible using the Android strategy. Can you imagine what would have happened if every computer manufacturer had had a say in when and how we get Chrome releases instead of the regular 6-week-ish cycles?

I've been an iPhone user. I've been an Android user. They're both excellent. But Android is always 2 years behind when it gets to my pocket.

The 10 JavaScript Mistakes you’re Making

2011-06-06T08:44:00.000-07:00

The 10 JavaScript Mistakes you’re Making: "

Advertise here

JavaScript is relatively easy to learn. However, gotchas abound in this tricky language. Are you sure that you’re not following any bad practices? Today, I’ll point out ten big mistakes you could be making.

Mistake 1 - You’re Using Global Variables

If you’re just getting started with JavaScript, you probably think it’s a great thing that all variables are global. Actually, if you’re just getting started, you might not know what that means. Global variables are variables that are accessible from anywhere in your JavaScript, even in different files loaded on the same page. Sounds great, doesn’t it? Any variable you might every want to change is always accessible.

Actually, no.

The reason this is a bad idea is because it’s easy to overwrite values unintentionally. Say you’ve got a web store, and you’re using JavaScript to display the price of all the items in the shopping cart (of course, you’ll recalculate this on the server side; this just enhances the user experience). Here’s some code you might have:

var total = 0,    // total price
  tax   = 0.05; // 5%

Now, let’s say that you’re also using some code you found online to display some tweets on the page … or to make a sharp little gallery for your products. They might have some code like this:

var total = 15; // number of tweets pulled from twitter

Or,

var tax = function () { /* ... */ }; // Trigger Animation eXperience function

Now, you’re in trouble: two important variables have been overwritten, and you might not even realize it; your code will be producing errors, and you’ll pay dearly in time and hair to get things working again.

So what’s the solution? In a word, encapsulation; but there are many ways to do this. Firstly, you could just write all your code within a self-invoking, anonymous function:

(function () {
  var total = 0, tax = 0.05;

  // other code
}());

This way, absolutely no code outside the function can get to the values you have inside the function. This works for “personal” code, but it’s not so great for functionality that you want to distribute. For example, if we wanted to create a shopping cart totaller that others could use, using the module pattern would be great:

var cartTotaler = (function () {
  var total = 0; tax = 0.05;

  // other code

  return {
    addItem : function (item) { },
    removeItem : function (item) { },
    calculateTitle : function () { }
  };
}());

One more thing about global variable: note that if you don’t use the var keyword when creating a variable, the JavaScript engine will create a global variable by default. So:

(function () {
tax = 0.05;
}());

var totalPrice = 100 + (100 * tax); // 105

The variable tax is available outside the function because it’s not declared with the var keyword. Watch out for this.

Mistake 2 - You’re Not Using Semicolons

Every statement in JavaScript must end with a semicolon. It’s that simple. The issue here is that is you don’t put it in, the compiler will: this is called semicolon insertion. So the question is, if the compiler will insert them for you, why waste your time?

Well, in some places, it’s absolutely necessary; for example, you must put semicolons between the statements in a for-loop’s condition, or you’ll get a syntax error. But what about at the end of lines?

The JavaScript community is really divided on this. I’ve read very well-respected professionals on both sides of the debate. Here’s my argument: whenever you’re relying on the JavaScript compiler to change your code (even in what seems like a small way), you’re in dangerous waters.

For example, look at this simple function:

function returnPerson (name) {
  return
  {
      name : name
  };
}

This looks like it should return a cute little object … but in reality, the JavaScript compiler assumes you meant to put a semicolon after return, and will therefore return nothing; that object will get ignored. Your solution would be to do this:

Editor’s Note- Another way to look at it: unless you’re aware of every single situation where they can successfully be omitted, don’t risk it.

return {
  name : name
};

I’m going to go with “diligently insert semicolons”; honestly, it becomes habit pretty quickly. Also, as a web developer, you’ll probably use other languages (like PHP) where semicolons are required. Why switch back and forth when you don’t have to?

Mistake 3 - You’re Using ==

If you left your computer right now and walked until you met any random JavaScript developer (that might take a while), and asked him/her to give you one common JavaScript mistake, this is probably what he/she would say: “using double-equals instead of triple-equals.” What’s this mean?

Try this:

if (1 == 1) {
  console.log("it's true!");
}

You’d expect that to work, right? Well, now try this:

if (1 == '1') {
  console.log("it's true!");
}

Yes, you got “it’s true!” output to the console … and yes, that’s a bad thing. What’s going on here is that the == equality operator is coercing the values: this means it’s actually changing them to try to make the two values more similar. In this case, it’s converting the string “1” to the number 1 … so that our if-statement condition passes.

The solution here is to use ===; this doesn’t perform any type coercion, so the values are what you expect them to be. Of course, this all goes for the != and !== operators as well.

Now, for your amusement, here’s a few of the incredible inconsistencies that you’ll get if you use double-equals:

''         == '0' // false
'0'        == ''  // true
false      == '0' // true
' \t\r\n ' == 0   // true

Mistake 4 - You’re using Type Wrapper Objects

JavaScript kindly (um?) gives us some type wrappers for easy (um?) creation of primitive types:

new Number(10);
new String("hello");
new Boolean(true);
new Object();
new Array("one", "two", "three");

First off, this is just super inconvenient. All these things can be done with many fewer keystrokes:

10;
"hello";
true;
{};
["one", "two", "three"];

But, wait, there’s more: these two things aren’t exactly equal. Here’s Douglas Crockford on the topic:

For example, new boolean(false) produces an object that has a valueOf method that returns the wrapped value.

- JavaScript: The Good Parts, page 114

This means that if you run typeof new Number(10) or typeof new String("hello"), you’ll get ‘object’—not what you want. Plus, using wrapper objects can cause behaviour that you’re not expecting if you’re used to primitive values.

So why does JavaScript provide these objects? It’s because they’re used internally. Primitive values don’t actually have methods (because they aren’t object); so, when you call a method on a primitive object (such as "hello".replace("ello", "i")), JavaScript creates a wrapper object for that string, does what you want, and then discards the object.

Leave the typed wrappers up to JavaScript and use the primitive values.

Note: this should go without saying, but I want to make this clear for the newbies: I’m not saying you shouldn’t use constructor functions and new (although some do recommend that). This advice specifically applies to primitive value types—numbers, strings, and booleans—arrays, and blank objects.

Mistake 5 - You’re not Property-Checking when Using For-In

We’re all familiar with iterating over arrays; however, you’ll probably find yourself wanting to iterate over the properties of an object. (Digression: the items in an array are actually just numbered properties in an object.) If you’ve done this before, you’ve used a for-in loop:

var prop, obj = { name: "Joe", job: "Coder", age: 25 };

for (var prop in obj) {
console.log(prop + ": " + obj[prop]);
}

If you run the above code, you should see this output:

name: Joe
job: Coder
age: 25

However, browsers will include properties and methods from further up the prototype chain. Most of the time you won’t want to see these when enumerating properties. You should be using the hasOwnProperties to filter out properties that aren’t actually on the object:

Function Dog (name) {
  this.name = name;
}
Dog.prototype.legs = 4;
Dog.prototype.speak = function () {
  return "woof!";
};

var d = new Dog("Bowser");

for (var prop in d) {
  console.log( prop + ": " + d[prop] );
}

console.log("=====");

for (var prop in d) {
if (d.hasOwnProperty(prop)) {
  console.log( prop + ": " + d[prop] );
}
}

// Output

// name: Bowser
// legs: 4
// speak: function () {
      return "woof!";
// }
// =====
// name: Bowser

Sometimes, you’ll want to let the properties through, but filter out any methods. You can do that by using typeof:

for (var prop in d) {
if (typeof d[prop] !== 'function') {
  console.log( prop + ": " + d[prop] );
}
}

Either way, always be sure to clarify your for-in statements to avoid unwanted results.

Mistake 6 - You’re Using `with` or `eval`

Thankfully, most sources for learning JavaScript today don’t teach you about with or eval. But if you’re using some older material—or using a less-than-reputable source (because sometimes good material is hard to find on the web)—you might have found with and eval and given them a try. Terrible move, web developer.

Let’s start with with. Two main reasons not to use it:

It really slows down the execution of your JavaScript.

It’s not always clear what you’re doing.

Point one stands on its own, so let’s look at the second. Quickly, here’s how with works: You pass an object to a with statement; then, inside the with statement block, you can access properties of the object as variables:

var person = { name: "Joe", age : 10 };

with (person) {
console.log(name); // Joe
console.log(age);  // 10
}

But, what if we have a variable with the same name as a property of the object we’re with-ing? Basically, if both a variable and a property with the same name exist, the variable will be used. The other gotcha is that you can’t add a property to the object inside a with statement: if no property or variable exists, it will be made a variable of the scope outside the with statement:

var person = { name: "Joe", age : 10 },
  name = "Billy";

with (person) {
console.log(name); // Billy
job = "Designer";
}

console.log(person.job); // undefined;
console.log(job); // Designer

So, how about eval? In a nutshell, you can pass a string of code to the function and it will execute the code.

eval( "Console.log('hello!');" );

Sounds harmless, even powerful, right? Actually, that’s the main problem: it’s too powerful. There’s obviously no reason to just hand it a hard string that you write directly into your code, because 1) why not just write the code? And 2) eval is slower, just like with. Therefore, the primary use of eval is to execute code that you don’t have at runtime. You could be getting this from the server, or taking code directly from the user. Do you really want to give your website users complete control of your code? I hope not. Also, it opens your site up to unnumbered hackers: using eval is basically a sign that says ”I’m away, and the key is under the mat.” If you love yourself or your users: don’t use it.

Mistake 7 - You’re Not Using a Radix When Using `parseInt`

JavaScript has a great little helper function called parseInt that allows you to convert a string that contains a number to a number:

parseInt("200"); // 200
parseInt("043"); // 35

Um, what happened there? Shouldn’t that second example be 43? Actually, parseInt will work with more than just decimal values: so, when parseInt sees a string that starts with a 0, it assumes that it’s an octal number (base 8). That’s why it’s a mistake not to pass a radix; this tells parseInt what base the number is in (it always outputs a decimal number).

parseInt("020", 10); // 20
parseInt("100", 2);  // 4

Mistake 8 - You’re Not Using Braces on `if` and `while` statements

One of the most obvious beauties of JavaScript is its flexibility. But sometimes, that can come back to fight you. That’s certainly the case with braces on if- and while-statement blocks. These braces are optional if you only have one line of code in the block:

if (true)
console.log("inside the if statement");

This is great, because you can even put them on the same line:

var arr = ["one", "two", "three", "four", "five", "six", "seven", "eight", "nine", "ten"],
  i   = arr.length - i;

while (i) console.log( arr[i--] );

But this isn’t smart for a couple of reasons: firstly, it can become unclear:

if (true)
console.log("inside the if-statement.");
console.log("outside the if-statement.");

See what I mean? That second line isn’t in the if-statement, but it sure looks like it. Braces would make that clear. Also, if you ever want to add a line to the block, you have to remember to add the braces as well. Just adding them in the first place is so much easier. Do it.

Mistake 9 - You’re Adding Elements to the DOM Individually

All right, all right: this isn’t really JavaScript itself. But, in 99 of 100 cases, JavaScript means using the DOM. While there’s a lot of mistakes you can make when working with the DOM, this is a big one.

I fondly remember the day when I inserted my first DOM element via JavaScript. It’s fun to do, and oh-so-useful, but it unfortunately is a strain on the page: inserting a DOM element forces the browser to completely repaint the page, so if you have a whole bunch of elements to add, adding them one by one is a bad idea:

var list = document.getElementById("list"),
  items = ["one", "two", "three", "four"],
  el;

for (var i = 0; items[i]; i++) {
el = document.createElement("li");
el.appendChild( document.createTextNode(items[i]) );
list.appendChild(el); // slow, bad idea
}

Here’s what you should do instead: use document fragments. Document fragments are a container to hold DOM elements; then instead of inserting each element individually, you can insert them all at once. The document fragment isn’t a node in itself and there will be nothing to show for it in the DOM: it’s just an invisible net for holding DOM elements before you put them into the DOM. So, here’s how you do it:

var list = document.getElementById("list"),
  frag = document.createDocumentFragment(),
  items = ["one", "two", "three", "four"],
  el;

for (var i = 0; items[i]; i++) {
el = document.createElement("li");
el.appendChild( document.createTextNode(items[i]) );
frag.appendChild(el); // better!
}

list.appendChild(frag);

Faster, quicker, cleaner—what’s not to love?

Mistake 10 - You’re Not Learning JavaScript

Many people don’t take the time to learn JavaScript right.

JavaScript does not equal jQuery. Did I just shock your sock off? If you found yourself guilty of committing several of the mistakes listed above, you probably need to do some serious JavaScript studying. JavaScript is a language that you can use almost without learning it, which means that so many people don’t take the time to learn it right. Don’t be one of those people: there are so many awesome JavaScript tutorials out there that you have no excuse for not learning the language. If all you know is jQuery (or Mootools, or whatever), you’re really putting yourself in a bad spot.

Mistake 11 - You’re Following all the Rules

Rules are made to be broken.

The last and final mistake you’re making is that you’re following all the rules. Yes, even some of the rules I’ve listed here. As with anything, rules are made to be broken. If you’re relatively new to JavaScript, you should probably avoid with fervour all the mistakes I’ve outlined for you today. But the truth is that if you understand why it’s recommended not to do something, that thing becomes a tool that you might use in just the right circumstance. For example, eval is preached against loudly, but it’s the only tool you can use to parse JSON from a server. Of course, there are many security checks in place when you do it (you should probably use a library). But the point is that you shouldn’t be afraid to knowledgeably use the “bad practices” I’ve listed above if the need arises. It’s the same close-mindedness that causes you to make these mistakes in the first place is the same close-mindedness that keeps you from using them when they are the right tool.

Of course, never make mistake 10 -

Conclusion

If you’re new to JavaScript, hopefully you’re a better JavaScript developer now. If you consider yourself a JavaScript pro (then how are you even still reading this?), what have I missed? Let us all know in the comments!

Internet Explorer 9 Looks Promising

2011-02-10T16:44:00.000-08:00

Here's something developers can get out of IE9 and the Windows 7 taskbar.

http://msdn.microsoft.com/en-us/library/gg131029(VS.85).aspx

Semantics.pdf - Powered by Google Docs

2011-02-03T09:49:00.000-08:00

Twilio Cloud Communications | Web Service API for building Voice and SMS Applications

2011-01-21T13:07:00.000-08:00

Twilio Cloud Communications | Web Service API for building Voice and SMS Applications

jQuery Microtemplating Tutorial

2011-01-20T09:21:00.000-08:00

www.myliferunsoncode.com/micro.zip

Documentation: http://api.jquery.com/category/plugins/templates/

The 30 CSS Selectors you Must Memorize

2010-11-04T17:42:00.000-07:00

The 30 CSS Selectors you Must Memorize: "

So you learned the base id, class, and descendant selectors – and then called it a day? If so, you’re missing out on an enormous level of flexibility. While many of the selectors mentioned in this article are part of the CSS3 spec, and are, consequently, only available in modern browsers, you owe it to yourself to commit these to memory.

1. *


* {
margin: 0;
padding: 0;
}

Let’s knock the obvious ones out, for the beginners, before we move onto the more advanced selectors.

The star symbol will target every single element on the page. Many developers will use this trick to zero out the margins and padding. While this is certainly fine for quick tests, I’d advise you to never use this in production code. It adds too much weight on the browser, and is unnecessary.

The * can also be used with child selectors.


#container * {
border: 1px solid black;
}

This will target every single element that is a child of the #container div. Again, try not to use this technique very much, if every.

Tempoc's Dev Blog

Days of a Month

Google IO 2012

Android: Cutting edge tech 2 years behind

Some History

Android's Permanent 2-year Lag

Wake up, Google!

The 10 JavaScript Mistakes you’re Making

Mistake 1 - You’re Using Global Variables

Mistake 2 - You’re Not Using Semicolons

Mistake 3 - You’re Using ==

Mistake 4 - You’re using Type Wrapper Objects

Mistake 5 - You’re not Property-Checking when Using For-In

Mistake 6 - You’re Using with or eval

Mistake 7 - You’re Not Using a Radix When Using parseInt

Mistake 8 - You’re Not Using Braces on if and while statements

Mistake 9 - You’re Adding Elements to the DOM Individually

Mistake 10 - You’re Not Learning JavaScript

Mistake 11 - You’re Following all the Rules

Conclusion

Internet Explorer 9 Looks Promising

Semantics.pdf - Powered by Google Docs

Twilio Cloud Communications | Web Service API for building Voice and SMS Applications

jQuery Microtemplating Tutorial

The 30 CSS Selectors you Must Memorize

1. *

2. #X

3. .X

4. X Y

5. X

6. X:visited and X:link

7. X + Y

8. X > Y

9. X ~ Y

10. X[title]

11. X[href='foo']

12. X[href*='nettuts']

13. X[href^='http']

14. X[href$='.jpg']

15. X[data-*='foo']

16. X[foo~='bar']

17. X:checked

18. X:after

19. X:hover

20. X:not(selector)

21. X::psuedoElement

Target the First Letter of a Paragraph

Target the First Line of a Paragraph

22. X:nth-child(n)

23. X:nth-last-child(n)

24. X:nth-of-type(n)

25. X:nth-last-of-type(n)

26. X:first-child

27. X:last-child

Example

Markup

CSS

28. X:only-child

29. X:only-of-type

30. X:first-of-type

A Test

Solution 1

Solution 2

Solution 3

Conclusion

Home - Gradle

Apache CXF

Send email using Gmail as a free SMTP with Java Mail

Excellent syntax highlighting for websites and blogs!

Usability Resources to Win Arguments

How Not Forcing Users to Register Increased Sales by $300million

10 Useful Usability Findings and Guidelines

Browser Resolution Stats by Google

The myth of the page fold: evidence from user testing

247 web usability guidelines

An Introduction to Using Patterns in Web Design

F-Shaped Pattern For Reading Web Content

Top Ten Mistakes in Web Design

Weblog Usability: The Top Ten Design Mistakes

Top-10 Application-Design Mistakes

Mistake 6 - You’re Using `with` or `eval`

Mistake 7 - You’re Not Using a Radix When Using `parseInt`

Mistake 8 - You’re Not Using Braces on `if` and `while` statements