It’s easier to ask forgiveness than it is to get permission.
– Grace Hopper
It’s easier to ask forgiveness than it is to get permission.
– Grace Hopper
Good design is as little design as possible.
– Dieter Rams
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):
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.
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.
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] - indexes[conflict]) == 1 and indexes.get(conflict, 9) > indexes[conflict]: 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:
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:
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.