After trying multiple editors (ViM, Dreamweaver, Coda, Sublime Text, etc.), I have found PhpStorm to be the easiest IDE for web development hands down. I am so much more efficient with it and headaches and confusion are down to a minimum. However, I stumbled across a very interesting bug in a web application that I was building.

Before I get into this nasty bug, allow me to provide some background. Feel free to skip this paragraph. I was working on a Laravel web application in PhpStorm (no plugins installed). I have installed Barry vd. Heuvel’s Laravel IDE Helper Generator plugin and Venture Craft’s Revisionable plugin. There is nothing out of the ordinary here.

I wrote a saving event that validates the attributes of the model before the resource is saved. If validation fails, I raise an exception indicating what exactly failed. Ideally, this exception would be caught and then be presented in a user-friendly manner, but since I am still deep in development, I hadn’t gotten to that point yet. Since the saving event is fired for both the insert operation and the update operation, I added a check on whether or not the model already existed in the database so that I can mark whether or not the primary key is required. The autocomplete suggests exists and exists(). I was confused as to what the difference was. I shrug it off and choose the method in the name of encapsulation.

I start running tests for my controller’s create action to be greeted by an error stating that the id field was required but not provided. “What?” I’m explicitly checking for it. Why is it still requiring it? One can easily deduce that exists() is returning true before the model is inserted. Why?

I first check out \Illuminate\Database\Eloquent\Model. Clearly something is wrong with the exists() method… except a quick search for such a function turns up empty. “Oh, well maybe it’s inheriting the method,” I though. Nope. That’s odd. So why is my autocomplete suggesting an exists() method and moreover why does the method work? Where is it coming from?

Of course, my next inclination is to check \Illuminate\Database\Eloquent\Model::__call($method, $parameters), which is implemented as follows:

public function __call($method, $parameters)
{
	if (in_array($method, array('increment', 'decrement')))
	{
		return call_user_func_array(array($this, $method), $parameters);
	}

	$query = $this->newQuery();

	return call_user_func_array(array($query, $method), $parameters);
}

Obviously, the if statement’s body won’t execute. So that leaves us with one question: what is the class of the value returned by $this->newQuery? It returns an instance of \Illuminate\Database\Eloquent\Builder. Ugh. This isn’t exactly my favorite class to work with in Laravel; it’s not as easily extendable. Same deal. exists() surprisingly does not exist.

Rinse and repeat. I check \Illuminate\Database\Eloquent\Builder::__call($method, $parameters) for the solution. The method is as follows:

public function __call($method, $parameters)
{
	if (method_exists($this->model, $scope = 'scope'.ucfirst($method)))
	{
		return $this->callScope($scope, $parameters);
	}
	else
	{
		$result = call_user_func_array(array($this->query, $method), $parameters);
	}

	return in_array($method, $this->passthru) ? $result : $this;
}

The if statement looks like an edge case, so I’ll give it a pass for now. So what is this elsestatement about? Of what type is $this->query? Perhaps the answer will be there. It turns out to be an instance of \Illuminate\Database\Query\Builder. Note that this uses a different namespace. Don’t let the similar name fool you.

I do a quick search for an exists() method again and I strike gold. It is as follows:

/**
 * Determine if any rows exist for the current query.
 *
 * @return bool
 */
public function exists()
{
	return $this->count() > 0;
}

This is quite interesting. In my case, this tells me whether or not any rows are in the table. That’s certainly not the behavior I was looking for. Be careful when using the exists() method, as it can cause quite the headache.

As a web developer, I have spent plenty of time designing many web pages. Many designers encourage the use of “CSS resets”. CSS resets are essentially a method to set most CSS values that differ between user agents to a consistent value so that the user will always see the same thing regardless of the device or user agent he or she is using. According to cssreset.com, as of the time of this writing, the top five CSS resets are as follows (from most popular to least popular):

  1. Eric Meyer’s “Reset CSS” 2.0
  2. HTML5 Doctor CSS Reset
  3. Yahoo! (YUI 3) Reset CSS
  4. Universal Selector ‘*’ Reset
  5. Normalize.css 1.0

Most of these are pretty similar to each other. Eric Meyer’s “Reset CSS” 2.0, HTML5 Doctor CSS Reset, Yahoo! (YUI 3) Reset CSS, and Normalize.css 1.0 are fairly similar and more or less do the same thing. Normalize.css 1.0 gets very involved. There are far too many rules for me to feel compelled to throw that into a website that I am designing. The others are at least bearable. On another note, Universal Selector ‘*’ Reset takes the opposite approach for resetting the CSS. All it does is set the default margins and paddings for everything to 0. That’s it. Personally, I wouldn’t mind using it due to its brevity. I find beauty in simplicity.

But I don’t use it. I don’t use any of the CSS resets. Why? Consistency. Many designers want to make sure that their designs look identical across user agents. I disagree with this, though, also in the name of consistency. Instead of maintaining consistency of my website, I want to maintain consistency with the user agents. So what if some browser underlines abbr tags and others don’t? What about mobile user agents? Do I want those to look the same? Of course not. I want to adapt to the user agent and present the content in a manner that is consistent with the user agents.

Designers often create separate designs for mobile user agents. So why stop there with the adaptation? Most users are familiar with the default CSS rules of their user agent(s). The user is likely not going to jump from user agent to user agent to browse the same content without breaks. So why bother making it consistent? The user will likely, however, be using the user agent for other tasks before and/or after visiting my site. So I feel that I should strive for consistency with the user agent.

This doesn’t go to say that one shouldn’t style his or her web pages. That’d be silly. Add some background colors, change the font face, etc. It’s okay to change some rules. But going so far as to take a whitelist approach at ensuring consistency in appearance across user agents is futile and will never be full-proof.

To build upon my previous post in The Perfect Browser Series, I think another much-needed, yet-to-be-implemented feature is an optional strict mode. The basic idea is that the browser will parse the HTML, CSS, JavaScript, etc. and render if the everything is correct or display an error message indicating what went wrong.

It would be helpful to implement an (obviously optional) strict mode. This strict mode will disallow rendering of any web page with an error or perhaps even a warning in it. The browser will parse the page and as soon as it finds an error such as an undefined variable in JavaScript, an unclosed tag in HTML (even though that is technically sometimes allowed), or an invalid property in CSS, it will render an error page that shall provide a thorough description of what went wrong. This is highly useful for developers. As a web developer, I know that sometimes I might make a typo in a CSS property and not realize it. I’ll see that the property isn’t in effect but I might think it’s caused by something other than a typo. Having this strict mode would eliminate that problem.

screenshot of code with comments moved to the side

Everybody can agree that commenting code makes things more readable. Others will understand why one is doing certain statements that would appear unnecessary without the presence of comments. Some even say that you can never comment your code enough. As debatable as that is, it should be true.

Have you ever used Microsoft Word’s commenting feature in the reviewing tools? Although I disagree with many things Microsoft does implementation-wise. I believe that their commenting system for documents is genius. You can turn them on or off. They don’t clutter the document too much because they are off to the side. Wouldn’t it be a great IDEa (knee slapper) to do the same with IDEs?

Although comments help others understand the code, if the readers already understand it, why should the comments still be there? I’m not saying that they should be deleted. I’m just saying that people shouldn’t have to see them. For example, many IDEs have code folding functionality. If you know what a particular function does, you can hide that entire function if you want. However, it’s not so simple with comments. You can’t tuck away all the comments without hiding the code as easily. If I understand the code, I don’t want to see the comments. They get in the way and take up valuable screen real estate. Sometimes, I may be familiar enough with the comments to not need them, but I would like to still see them in case I need to make a quick change.

Take a look at the screenshots of the first few lines of the TkInter module from Python 3 in Microsoft Word.

screenshot of code with inline comments

This is how one would see the code in IDLE.

screenshot of code with comments moved to the side

This is how one would see the code with Microsoft Word-like comments. Note that comments generally aren't as long as the first one.

screenshot of code with comments turned off

This is how the code would appear without any comments.

In my opinion, since I have an idea as to what all of this code is doing, turning off the comments makes the code more readable. Doing so also gives me more room to focus on other chunks of code without having to scroll up or down to see it. It also isolates the area that I need to look at.

Another benefit to this type of commenting is metadata. Sure, one could put his or her name in every single comment but that would get really old really fast. With comments aside, it would be easy to see who the author of a comment is, who last modified the comment, optionally the date and/or time, etc. The possibilities are endless. No special file format or extra metadata files would be needed. Upon saving the code, the IDE will format the comments into plain-text with special markup that it would recognize upon reopening. That way, one could use other IDEs without this feature and continue coding hassle-free.

Why stop there, though. We are familiar with outline views of code, right? Have you ever found yourself using code folding to fold each function away? Why not make it easier. With most IDEs, you have to select the entire function to fold it away. Others have a plus or minus button beside each function to show or hide it, respectively. I think that people should have the choice of tucking it away or completely hiding it. What if you have 50 getters and setters in a class? Do you really want to see the function signature of every single one just to know it exists? I think that in cases like that and in other situations, one would want to simply hide the functions. One could argue that hiding a function could cause a programmer to forget about the existence of a particular function. That’s what the outline is for. I don’t think people realize the full potential of the outline. It’s intentions would be fully unleashed with this functionality.

If you would like to see this type of functionality, voice your opinion. What do you think about “toggleable” comments?

If you were to ask any number of web developers and web designers what the number one problem is with using the most recent technologies, I would bet you that they would all say that users do not regularly update their browsers. Why would the typical internet surfer want to take time to update his/her browser when the web usually works fine for him/her?

Ironically, websites are the easiest to update, however, their presenters (the browsers) are the worst to update. When developers or designers update a website, they have to take into account that most people will not update their browser(s) as soon as possible. This means that they must “dumb down” the website so that it looks appealing and works properly. However, this process lessens any reasons to update a browser. Since websites are (almost) always downloaded on demand, it is easy to update them. All users immediately see the updates. If you change a picture, they can see it. If you add a page, they can see it. They will experience the updates immediately.

What if browsers took on this behavior? What if browsers could be updated like a website? Think about it this way. The user downloads the bare bones application (which should never need updating). This isn’t exactly how it’d work, but I will choose my words differently to help picture what the browser will do under the hood. This application merely displays one web page. Think of this web page as the entire browser window: tabs, address bar, refresh button, etc. Think of all of that as being an actual web page. Within this web page, a user can navigate to a web page in a frame of that core web page. Think of it as a box inside a box. The core web page (the application itself) will be cached on the local computer along with its checksum. Every time the browser is opened, a request containing the checksum will be sent to a server to match the user’s checksum with the latest checksum. If these do not match, the server will respond with the latest update. Once the update is downloaded, the browser will cache and present it, and the user, then, will be able to happily navigate the web with no worries.

The same goes with the under the hood part. The browser itself can be saved in a root directory or somewhere accessible by all users. However, updates are downloaded on a per-user basis. That way asking for permissions is never necessary. On a side note, an administrator could be given the option to push the update to all users instead of all them having to silently download it. It never asks you to update. It never bothers you. You would never even know. It acts just like a website. It just works.

I found the following text on the first page of Chapter 1 from Software Engineering: A Practitioner’s Approach, Seventh Edition by Dr. Roger S. Pressman.

He spoke while tapping the table for emphasis. “The old school view of software–you buy it, you own it, and it’s your job to manage it–that’s coming to an end. Today, with Web 2.0 and pervasive computing coming on strong, we’re going to be seeing a completely different generation of software. It’ll be delivered via the Internet and will look exactly like it’s residing on each user’s computing device… but it’ll reside on a far-away server.”

I had to agree. “So, your life will be much simpler. You guys won’t have to worry about five different versions of the same App in use across tens of thousands of users.”

He smiled. “Absolutely. Only the most current version residing on our servers. When we make a change or a correction, we supply updated functionality and content to every user. Everyone has it instantly!”
I grimaced. “But if you make a mistake, everyone has that instantly as well.”

He chuckled. “True, that’s why we’re redoubling our efforts to do even better software engineering. Problem is, we have to do it ‘fast’ because the market has accelerated in every application area.”

He’s onto something. This would be a revolution in the web industry. No longer will we have to wait for users to update their browsers. We can go to sleep knowing that our websites will work. The final leap: getting users to swap to this browser.

What are your thoughts on a web-like browser?

The other day, I was looking at the three screen locks options (patterns, PINs, and passwords) for Android phones and wondered if there is an difference among them in terms of security.

The first option, patterns, involves a three by three matrix in which one swipes his or finger across the screen to create a specific pattern. Sure, it’s easy to give a quick swipe to unlock your phone, but that convenience comes at a price; there are only 389,112 possible patterns. Below is the proof in Python.

from itertools import permutations

count = 0
for i in range(4, 10):
	for path in permutations(range(9), i):
		# don't count any permutation that has one of these conflicting subsequences
		indexes = dict(map(reversed, enumerate(path)))
		for conflict in (
				(0, 2, 1),
				(0, 6, 3),
				(0, 8, 4),
				(1, 7, 4),
				(2, 6, 4),
				(2, 8, 5),
				(3, 5, 4),
				(6, 8, 7)
		):
			try:
				if abs(indexes[conflict[0]] - indexes[conflict[1]]) == 1 and indexes.get(conflict[2], 9) > indexes[conflict[0]]:
					break
			except KeyError:
				pass
		else:
			count += 1
print(count)

Using a PIN, however, is much more secure in that it gives 11,111,111,111,110,000 possibilities. The valid characters are the set of single-digit nonnegative integers and they can also be repeated. The PIN must be between four to sixteen characters (inclusively). Therefor, one can find the find the number of pins with the following expressions in Python:

sum(10**e for e in range(4, 17))

The password route is the strongest with 5,134,683,209,465,668,805,823,644,485,848 possibilities. That’s over five nonillion! The constraints to the passwords are as follows:

  • Valid characters are 0123456789abcdefghijklmnopqrstuvwxyzABCDEFGHIJKLMNOPQRSTUVWXYZ@#$%&*-+()!"':;/?,.=_.
  • Must be four to sixteen characters (inclusive) long and must contain at least one letter.

There are eighty-three possible characters. At least one of those characters in the password must be a letter, so one of the four to sixteen characters to choose from is limited to fifty-two characters (read: thirty-one characters less than the initial eighty-three character possibility). To solve the number of possibilities, one can solve the number of possibilities without the one alphabetic character requirement and then subtract the number of possibilities that have zero alphabetic characters as follows:

sum(83**e for e in range(4, 17)) - sum(31**e for e in range(4, 17))

Using a password is theoretically the safest bet. With that said, there are a few caveats. Most people reuse passwords and/or use short and/or easily guessable passwords. By doing so, they practically eliminate the added security of using passwords over the other options. PINs fall in the same category, though. Many people will use the same PIN across several services including but not limited to bank accounts. The pattern option doesn’t have this problem. However, it does have the problem in that people will pick easy patterns (such as the letter Z or a spiral) rather than difficult to guess patterns. If you choose the password route, may I suggest the advice given by the following xkcd comic:

xkcd Comic 936: Password Strength

How to properly pick a password

There are two types of nosy eyes you have to be worried about: those that are close to you that may try to pry into your life when you are away from your phone and those that will take advantage of you if and when you lose your phone. There’s not much you can do about the former since you may not ever know about the incident. However, if you lose your phone, you know it may be maliciously accessed by the finder. For this, I recommend Prey.

In conclusion, be smart in choosing your pattern, PIN, or password by not picking something that is easy to guess. In practice, all of these options are strong enough to deter the unmotivated.