Nolan's Blog
|
A List of Useful Web Development Blogs
October 22, 2009 at 11:37 am by NolanThe Internet is a noisy place, with Twitter updates constantly
streaming and blogs spewing out second-hand knowledge, making it
difficult to find sources that are both credible and consistently good.
Here are a few blogs that I follow that keep me informed on what's going on and what's next in Web technology. |
Tags:
EmailComments (1) The Most Important Person on the Team
July 31, 2009 at 1:54 PM by NolanWhile not being the most glamorous or high-profile position, the Quality Assurance (QA) role is the most important person on any web development team, and it doubly so here at Newfangled. Without them, our websites would be riddled with bugs, projects would never get finished on time, and everyone would generally be in a sour mood. Here, I hope to detail out what exactly these QA people do, and why I consider them the most important people in the room.
|
Tags: software
EmailComments (1) New Technology, and Balancing the Fun with the Practical
May 5, 2009 at 9:08 AM by NolanFollowing technology trends on the web is a dizzying pastime. New programming languages rise to popularity seemingly every month and the buzzword-laden web frameworks make their introductions and dance on stage for half a verse before bowing out to younger, fresher technologies. When deciding which pieces of new technology to build into your web presence, there are several things that a developer should consider and some simple guidelines to pull in new, fun technology. Obviously, the first attribute that a technology is measured by is its quality. Simply, is the code behind it good and sturdy? If you lean on it too hard, will it break? If you sense code smell, follow your gut and keep moving. The next attribute I look for is community. You read about a new technology and it seems to be the silver bullet for your application. (We'll disregard for the sake of the example that there is no silver bullet.) Reading further you find out that the technology is driven by one developer. The online mailing list gets a question once every two days, and the IRC channel is frequented by the lead developer and a fistful of other passersby just checking things out. That is no community; that's a household. Now, almost every software project gets started with meager few people involved, and maybe this interesting new technology is in this stage of its life, but what if it's not? Maybe the lead developer hits the lottery and moves to the sunny French Riviera, never touching his MacBook Pro again except to order fine wines for his chateau. You now have a software project that has possibly no active developers and the project fades away to the great Internet Archive in the sky. If you had adopted this technology for a website, you are now riding with an effectively dead technology. This is not a good situation to be in when you need to hire someone that knows it to maintain your site, or to fix bugs that may pop up in the software. With community, a software project has staying power. The more people involved, the higher chance it will be around longer. Signs of good community: 1) A local user group 2) Corporate backing (not essential, but definitely nice) 3) Lots of blog posts and Twitter messages indicating that people are talking about the tech. 4) Active mailing lists, both for general help list and the developer list. 5) An IRC channel where you can pop in and find numerous people to help you with an issue. All of these are not necessary to have a good community but the major software projects tend to have these in common. My personal favorite trait in assessing a new hunk of technology is documentation. Well-written and kept-up documentation is something that makes most developers happy, but unfortunately writing documentation is not enjoyable as a task. If a software project has a fantastic demo, and then I click through to the documentation wiki and find more instances of "coming soon" than code samples, I usually step away. Lack of documentation and time to implement a technology are usually inversely related. Little documentation results in lots of tinkering and cursing, fumbling in the dark and looking for that magic combination of words to get the spell working. Software is painful enough; building with it without proper guidance is torture. Some developers thrive on the poke-and-prod method of development, but when a client's money (and the developer's sanity) is on the line, a few breadcrumbs goes a long, long way. Now that some simple guidelines on vetting technology has been laid down, how do you bring the technologies that look fun and promising, but may not be quite ripe, into the workflow? Easy. Start small and leave traces. Starting small means don't build anything mission-critical on it. You definitely don't want to nab a big client and then decide to to build their website on a funky schema-less graph database you read about on Reddit. I can guarantee you they don't want to be your testing ground. Now, you may grab another client whose needs may line up for the new and edgy technology. Let them know what you are doing and be honest about your experience with the tech. No one enjoys any surprises in budget or functionality further along. Leaving traces means let your co-workers know what you did. On your dev team's wiki (if you don't have one, you should), document out why you chose the technology that you did and how you used it, with lots of links and code samples. In case you hit your numbers on the weekend PowerBall and retire early, you don't want to leave your comrades high and dry poking through your code when a bug pops up. The web is a fun place, with lots of smart people doing cool things every day. Playing with new technology is why a lot of web developers do what they do, and bringing this into enterprise doesn't have to be a pipe dream. So, feel free to experiment, but just be responsible. *All photos licensed under the Creative Commons |
Tags: technology web-developmet
EmailComments (4) What is SSL?
February 13, 2009 at 11:00 am by Nolan| SSL (or secure sockets layer) is a way for a user to verify two things about a
server they are trying to contact for requesting a web page. The first is that
they are communicating with the exact server they are expecting to be
communicating with, and secondly, that no one is listening in on this
communication. SSL is essential for logins, transporting delicate information,
as well guaranteeing the correct sender and receiver. When should a website use SSL? Basically, whenever you are transmitting something you wouldn't want a casual observer to view. If you work in an office building, a transaction may go through 2-3 hops before it leaves your building, and then it goes to out the local branch of your ISP, and further up through the various conduits (tubes, if you will) of the Internet, until your packets find the server it's aiming for. A traceroute from where I'm typing this post at work to "google.com" visits 10 different servers before getting to the Google server. If you are transmitting vital information unsecured, these are 10 different spots where someone could read your traffic. If you are using high-grade SSL, the snoop will see a stream of seemingly random bits, and even if he gets the entire conversation saved, it would take about 1000 times the age of the universe to brute-force attack the key. Obviously, there are better methods than brute forcing, but with a large enough key, you are good for several years. As of now, high-grade SSL is effectively unbreakable. Several industries are required by law to use some sort of SSL. Bank account access must be secured, as well as most health care operations. Any transportation of credit card information must be secured. Most major webmail clients allow you to access them via HTTPS. Even Wordpress will allow you to switch on HTTPS to access its admin section. My suggestion usually is if you are transporting anything of value over the Internet, mainly username and passwords for any important business, an SSL key is recommended. How do I get an SSL certificate? If you are hosting a site with us, just ask us and we'll set you up. If not, Verisign and Geo Trust are two good options. Even registrars like Go Daddy allow you to buy SSL certificates from them. With an SSL certificate, you will want to make sure it is signed by a recognized certificate authority. Since anyone can make an SSL certificate, there is no inherent trust created, since you can't tell the difference between a certificate signed by one of the trusted authorities, or some malicious entity. The trust is generated when you have one of the major authorities verify who you say you are. Browsers come pre-installed with these major authorities' root certificates so you can check the authority's signature on the SSL certificate. This is basically a "trust by association" model. You trust Company A, and Company A says Online Store B is trustworthy, therefore, you are able to trust Online Store B. A non-trusted SSL certificate will give you an error in the browser, alerting you to the possibility that the certificate has not been verified by one of the big certificate authorities. How does SSL work?
This is a fairly technical explanation, so if you don't have any interest in the ins-and-outs of SSL, you can skip this section with the take away that SSL is an extremely secure and a neat way for browsers and servers to setup secure channels. With that said, I'll commence with the explanation. When a browser makes an HTTPS request, the browser first does an DNS lookup on the hostname to get the IP address. The browser makes a connection to the server at this IP address on port 443 (by default) to start setting up the secure connection. The server replies with its public SSL certificate, which the browser will then verify, checking its signature against the pre-installed certificate authority keys. This certificate authority's signature gives you faith that the entity you are talking to is whom you expect it to be. The SSL certificate from the server contains information such as what hostname the certificate was built for and how long the certificate is good for. It may also contain other information about the business, such as contact information, but this is not required. This step is where the browser will show SSL errors to the user, such as the hostname mismatch or certificate expiration. The most common error that people see is the hostname mismatch. If you typed in "https://www.example.com" and the SSL certificate was built for just "example.com", you'll see the mismatch notice. The data is transmitted encrypted using symmetric key cryptography. Symmetric key cryptography involves the sender and receiver (in this case, the browser and the server) both having the same key which is then used to both encrypt and decrypt a message. The advantage of this type of protocol is that encryption and decryption are very fast while still being incredibly secure. The downside of this is the issue of how to get the key from the client to the browser without anyone in the middle stealing it. This is where another kind of cryptography, public key cryptography comes in. Public-key cryptography consists of the message receiver having two keys, one being public and the other being private. To send an encrypted message, the sender uses the receiver's public key to encrypt the message. To decrypt this message, the receiver uses the private key against the message. The public key is available for anyone to use, but the private key should be never be shared with anyone, because if this key gets out, then any messages encrypted with the public key can be decrypted by anyone possessing the private key. A good analogy for this type of cryptography is to think of it like a mailbox. Anyone is allowed to drop a letter in, but only the owner of the mailbox has the key to unlock it and get the letters out. So after the browser makes its request to begin the secure transaction, the server will reply with its SSL certificate, which contains its public key. After the browser checks out the authenticity of the certificate, it will generate a brand-new, temporary symmetric key. The browser will encrypt this new key with the SSL certificate's public key, and send it back. Since only the server is able to decrypt this message and get the symmetric key out, the symmetric key has been safely transported from the browser to the server, with no one being able to snoop on it while in transit. From then on, the browser and client will do all of its encryption and decryption with this symmetric key, due to its speed advantage mentioned earlier. Thus, a relatively fast and secure channel has been created between the server and browser. To sum up, here's a quick rundown of the full SSL transaction:
This protocol completes the two goals of SSL: secure communication and guaranteed authentication. The cool thing about the SSL protocol is that the secure channel is created before anything is transferred, even the URL itself. That means if you request "https://www.example.com/some_secret_resource" the browser does a DNS lookup of "www.example.com", goes through the above steps, and after the secure channel has been created, then the full URL is sent to the server. The DNS lookup, if it doesn't come out of the client's DNS cache, will be the only way to verify what server the user is trying to contact. Someone on the outside can tell the client is trying to contact a certain IP address and see the encrypted traffic, but that's basically the sum total of an observer's view of the transaction. -- In summary, if you don't want an outsider to see what you are transmitting between the browser and the server, an SSL certificate is a simple way to get a high-level of privacy and security. |
Tags:
EmailComments (0) Keeping Your Site Safe from the Bad Guys
January 27, 2009 at 2:05 pm by NolanOne thing that has evolved almost as quickly as the web itself is the rise of security problems associated with it. Web developers today have to take great care in not introducing security holes into websites. These security lapses can come from something as seemingly innocuous as a simple contact form.
Another way to defend against this is to check the Referer header of the request. It probably best to use the hidden token method and Referer check together as there is no such thing as too much safety, and the code is not significantly more complex. --- Security is one of the things that developers do that when taken care of properly, the client never notices, but if something slips up, it (or the lack of it) comes front and center. The main source of security holes on a website, with a little extra work, can be easily avoided. |
Tags:
EmailComments (2) 










Share


