Search This Blog

Showing posts with label web-development. Show all posts
Showing posts with label web-development. Show all posts

Monday, 24 June 2013

7 Crazy Tips That Will Help You Become a Better Coder

7 Crazy Tips That Will Help You Become a Better Coder
There are a whole slew of developers writing amazing and practical code and there are thousands of public code repositories on sites like GitHub. Meanwhile, the rest of us are content with just cutting and pasting the code of these industry geniuses.
For the majority, it seems that true coding has become a lost art. Almost every project, it seems, now uses some sort of library/framework or contains a heap of plugins.
It’s rare to see any front-end coding project truly start from scratch anymore.
In this article, I thought I would give some somewhat off-the-wall tips on improving your skill as a front-end coder.
These tips will likely not be used when coding paid client projects where time and budget are factors. These are tips that we can put into practice in our own personal projects or in our spare time to try to improve our coding abilities and problem-solving skills.
While I do think the tips below can contribute to a developer becoming a stronger coder, they may not always be practical.

1. Write Your Own Framework

As mentioned, there’s almost no such thing as a from-scratch project anymore. Everything starts with some kind of code base or boilerplate. Even industry leaders with cream-of-the-crop engineers like Google have leveraged open source JavaScript frameworks such as jQuery.
On the back-end, you’ll probably be using something like WordPress or another CMS. On the front-end, you’ll likely be including your favorite JavaScript web development library/framework and a CSS reset.
Forget those bloated things. Write your own code base instead and adapt them to your own needs. Yes, something like this will probably take you many hours, and potentially weeks or months.
You’ll likely end up scrapping the whole thing and never using it on a real project. But you’ll have no choice but to learn how to do it, even if that means doing it badly.
It’s a daunting task, but something that will reap great benefits. You’ll understand the language’s syntax better, the concepts will become clearer, and your problem-solving skills will improve.
Even if it’s something small like your own tiny JavaScript library (e.g. a JavaScript animation framework) that has a half-dozen modules, it will be well worth the effort.
It might even be a good idea to keep this type of thing as an indefinite project that’s continually on going. You can keep going back to it, improving it, learning new lessons and adding new features. It probably still won’t be as good as the popular, open source ones out there, but you’ll probably learn more than you ever would otherwise.

2. Don’t Use Developer Tools

If you’re like me and you run into a scripting problem or a selector specificity issue in CSS, the first thing you might turn to is some developer-related tool like Firebug, Web Developer extension, Google Chrome’s Developer Tools and the like. For instance, Firebug provides invaluable features for tracking down and fixing almost any front-end coding issue.
However, remember that tools like Firebug are fairly young. Developers in the late 90sand early 2000s didn’t use these types of robust tools.
Although those rudimentary development techniques might be considered "slow" by today’s standards, the developers that used such archaic debugging methods understood their craft as well as anyone.
If you can debug a CSS or JavaScript problem without using any special tools, then that shows you have a solid understanding of CSS and some of the deeper parts of JavaScript.
This topic, specifically in relation to debugging tools, was covered by Jens O. Meiertand I wholeheartedly agree with his theory.
Sure, you won’t solve any problem as quickly as you would with Firebug or your favorite developer tools, but there’s a good chance you’ll learn more and avoid making the same mistake again in the future.

3. Don’t Use a Browser

Creating websites without testing them in their environment? Did I mention that these were crazy coding tips?
Well, customarily, if you’re developing a CSS layout or some kind of JavaScript functionality, it’s pretty common to switch back and forth between editor and browser, checking your stuff as you go.
Instead, try this exercise some time: Code an entire web page layout or JavaScript widget without checking it in the browser until you’ve completed the whole thing. This will cause you to stay focused the entire time, ensuring that every line is coded properly. And you’ll be forced to visualize the outcome of your code.
From my experience, being able to visualize the results of the code you write is an important part of understanding it. Ignoring, to some degree, the actual output forces you to think through your code line by line, and this will help you understand every bit of it more fully.

4. Don’t Use a Code Generator

This tip is especially important for learning the ins and outs of CSS3. There are dozens of CSS3 gradient generators, button makers, and other tools that can help you write CSS faster. Those are useful, especially when you’re facing a deadline.
A CSS3 gradient generator can be useful, but can also hamper learning of underlying style sheet concepts.
But if you take the time to type every line of CSS3 manually, you’ll be forced to learn all the different parts of the various syntaxes.
Take for example the simple box-shadow property (example below):
.shadow {
box-shadow: 4px 4px 8px rgba(0, 0, 0, .2);
}
If you’re using a code generator to spit out that code, then you’ll take much longer to get used to what each of those values represent.
On the other hand, typing it manually likely means you’ll have to check a reference or even the CSS3 W3C specification draft. All of this will lead to a better understanding of how the code works.

5. Type Book Code Examples By Hand

Pretty much every computer programming book written nowadays will include a code archive that’s available for download or on an accompanying CD. This is great. But how much can you learn from copying and pasting so much code?
So forget about the code archive. If you have the time to do an in-depth study of the material in a book, complement such study by typing all the examples by hand, then test them to ensure they’re working properly.
This will have a number of positive effects on your coding abilities. It’s inevitable (especially if the concepts are new to you) that you’ll type a lot of things incorrectly, leading to error messages. This will force you to have to pore over the code examples in the book while comparing them to your own until you find any problems.
You’ll be debugging code almost immediately after learning it, and I’m sure we can all agree that many of the most important coding lessons are learned when debugging. You might also find errors in the code printed in the book, so this presents further opportunities for getting a stronger understanding of the concepts involved.
Even more crazy: You might want to do the same thing with code examples you find online in tutorials and articles. Don’t copy and paste them, but instead, type them manually. Again, you’ll see many of the same benefits mentioned above.

6. Use a Vanilla Text Editor

What I mean by "vanilla" is a text editor that has no helpers or auto-complete functionality. Or else you could just turn off any auto-complete functionality your editor has, and pretend you’re using something like the Windows-based classic Notepad.
I used to code classic ASP-based websites in the early 2000s, and for a number of years I wrote all my code (front-end and back-end) in Windows Notepad. Although there were times when this seriously slowed me down, I learned to write a lot of it from memory, and I was able to debug pretty much anything without any special tools.
If you get zero help from your editor when writing code, you’ll be forced to memorize much more than you would otherwise.

7. Re-Invent the Wheel

Whatever project you’ll be working on next will likely require something that’s been written a million times before. It could be a lightbox, a content or image slider, a photo gallery script or a tab switcher.
Almost every developer will tell you you’d be crazy to write one of these yourself. But think about it: Do you know how to write (for example) a lightbox function in JavaScript? If you don’t, then how would you ever learn?
The concepts you’ll pick up from these activities will have tremendous long-term value.
It’s ridiculous to never re-invent the wheel. If you spend your entire developer career cutting and pasting other people’s code, then you’ll only make minimal progress at best.
Of course, if you do write your own lightbox script, it will probably be one of the worst lightbox scripts ever. But who cares? You’ll learn a ton of stuff along the way, and you could always go back to it later and see if you can’t make any improvements and optimizations that you might have picked up elsewhere.

Conclusion

As I mentioned early on in the article, these aren’t going to be the kinds of tips you’ll want to use regularly or on important projects. But if you have some time to spare, use some of this advice — even if you’re just applying it in a small way.
In my opinion, these crazy suggestions will help you develop your own coding style and you’ll have a better understanding of the underlying concepts of the code you’re working with.

Tips for Building Your First Web App

Tips for Building Your First Web App
As someone who creates web apps (both for myself and for clients), I’ve learned a few things throughout my journey that have helped me get the best results for the time and resources I have.
These tips are from a person who started out as someone who wasn’t familiar with Web programming. When I first started developing my first web app, I wasn’t a web developer. I was a business guy.
(If you want to read my story on how I built my first web app in only a few months using Ruby on Rails, check out my article: Why Making Web Apps with Rails Is Awesome.)
An assumption I’m going to make about you, the person reading this article, is that you’re already a web developer, or that you’ll be hiring one for your first web app. I’ll be discussing practical, general tips that are applicable to all web apps regardless of what Web technologies you’re using. So please don’t expect some deep-level web programming techniques in this article, because you’ll find none.
Another assumption I’m making is that you’re going to build your first web app without investing hundreds of thousands of dollars into version 1.0. I’ll assume that yourbudget is in the $5,000 range largely because that’s where my experience lies.
With my preface all said and done, let me share my seven tips based off my own web app development experience.

1. Think in Terms of Data Relationships

Regardless of complexity, size or feature set, you can break down any web application into this simple operational mechanics:
  1. The web app takes in data from users
  2. The web app processes and decides what to do with that data
  3. The web app produces some output for the users
All web apps work like that, so at the start, it’s best to break down your web app’s core features into data relationships to see:
  • How your web app should be built
  • How your web app might deal with user data and presentation
  • What features you need to prioritize
  • What web services and web technologies you’ll need to enlist and get familiar with
And so on.
For example, let’s take the primary feature of Instagram — posting a photo up on the photo-sharing service — and break it down into the fundamental operational mechanics above:
  1. The web app takes in a photo from users
  2. The web app processes the photo to scale it up or down to the layout of Instagram and also what photo effect the user wants to apply to the photo
  3. The web app produces a modified image and displays it for the users
So if you were hiring me to create an Instagram clone for you, I would probably create a breakdown of the data relationships like this:
Users
Has 2 permission roles (User and Admin)
A User can upload Photos
A User can manipulate Photos
A User can like or dislike Photos of other Users
A User can comment on Photos
Photos
Photos are uploaded by a User
A Photo can get a Filter applied to it by the User who owns the Photo
A Photo can get liked/disliked
A Photo can get a Comment
A Photo can be deleted/edited/updated
A Photo can be private or public
Filter
A Filter can be applied to Photos
A Filter can be created by an Admin
Comment
A Comment belongs to a Photo
A Comment can be created, edited and deleted by the User who own theComment
A Comment can be deleted by the User who owns the Photo where theComment is on
I know you may not be able to think naturally like that at first whenever you look at web apps, but the more you use other web apps, and the more you think about them in all of these little pieces of data relationships, the easier it is for you to conceptualize and build your web app.

2. Keep Track of UIs and Websites That Inspire You

Do you have examples of web applications and websites that you like?
From as little as small, interactive components (like the way a button feels when it’s pressed or how a web app deals with an image uploading feature) to as big as the color scheme for the entire site and general design theme and sensibility, you should have some way of recording these inspirational examples.
Anything you have come across on the Web that you like, make a note of it.
UI inspiration board on Pinterest by Stefan Marshall
You can use a multimedia note-taking tool like Evernote or an image bookmarking service like Pinterest for this.
Having this collection of web user interfaces and website designs that inspire you will help you as you begin developing your web app’s interface — you can look to your collection for ideas.
Also, familiarize yourself with common user interface design patterns to make sure that your UI components are the best solutions for a given task.

3. Keep the First Version as Simple as Possible

Building a minimum viable product (MVP) is a popular concept for online startups. A minimum viable product is something that has the most basic core features of a web app and nothing more.
Producing an MVP has many benefits, but the primary reason is to validate your web app idea as quickly and as cheaply as possible.
If you keep the web app to a very strict and defined set of core features, you can test out whether or not those core features are what your users need.
Do you remember the first version of Google?
Google’s core feature is search. And all you need for that core feature is a text input field for the user’s search term, and a button to execute the search. It doesn’t have to be pretty. It doesn’t have to be any more complicated than that. It just has to do what it promises very well.
The MVP allowed Google to launch the product to the public so that the company can validate their idea before developing it further.
The MVP also allowed them to start gathering user search behaviors and to tease out new features and opportunities for improvements in future versions of the product.
Fast forward to today and Google is now more than just a search company. Their core feature is also a lot more sophisticated compared to the first version.
But it was that first version that led them on the path they are now.
I have never seen a web app fail because it did too little or because it didn’t have enough features.
To me, web apps fail because there is no demand for the problem they’re aiming to solve, or because the web app doesn’t execute the solution to the problem effectively.

4. Focus on Behavior and Less on Look-and-Feel

Quite often, frustrations that people have with a web app come from the way it behaves, not the way it looks.
I’m not saying you should ignore how your web app looks altogether, but I think that this is something you can refine, polish, and invest in more once you confirm your solution is something users actually want.
What I’m suggesting is that you direct your time and resources into your web app’svalue proposition — which for a web app is usually the fundamental problem it’s aiming to solve for its users.
To that end, I encourage you to use a reliable HTML/CSS framework or boilerplate such as Twitter Bootstrap, Skeleton and Foundation when it comes to developing the front-end interface of your MVP.
CSS/HTML frameworks and boilerplates speed up front-end design and development so that you can have more time to concentrate on how your web app behaves.
This way, you can put most of your time and resources on actually developing new and novel stuff, rather than on things that have already been solved. There is no need to reinvent the wheel.
Kippt — a web app trying to enhance the way people find, read, store, search, and share Web content — uses Twitter Bootstrap:
Kippt’s aiming to solve a complex and ambitious problem — what, with the billions of web pages out there — and they realize that how their website looks isn’t the primary reason they’re going to get more web app sign-ups.
So for the front-end design, they lean on a reliable and beautiful front-end framework to help them with things like responsive web design, content layout, CSS resets, cross-browser compatibility, and the myriad other things that are critical in any Web project, but have already been solved by others before them.
After you validate your web app, and are convinced that it’s worth pursuing, then you can invest your retirement fund designing that perfect web app favicon if you so desire.

5. Use Free or Affordable Web Services as Much as Possible

Even if you just won the lottery and have money to burn, don’t be frivolous with your funds.
There are many powerful web services built for modern web applications that have free (or very affordable) pricing plans.
From Heroku (my favorite Rails host) to Amazon S3 (for storing images and other content) to SendGrid (for handling your transactional emails) to Stripe (that handles your payments and only charges you a transaction fee) to Google Analytics (for relatively robust web analytics) — with a bit of online research and self-education, you can end up saving yourself a lot of money.
Once your app takes off like the next Facebook, you can invest in more robust web services replacements if you need to, or scale up your existing solutions. The web services I’ve mentioned above don’t need any replacements; they will scale with you as you grow.
Another point I want to make is there’s no need to think about scalability right now. If you pick the right solutions, they will scale up with you when you need them to.
So if you’re thinking about buying dedicated server racks hosted in your own datacenters even before you’ve launched an MVP, you’re putting your worries and time in the wrong places.

6. Use Third-Party APIs with Caution

An API is a way for a developer to get access to the data of an external web service. For example, Twitter’s API allows any developer to build an app that accesses public tweets and the account information of Twitter users.
Not all APIs are created equally. The best APIs are those that are RESTful (i.e. they conform to best practices and industry standards about the way data should be interacted with) and they provide wrappers for multiple popular languages (PHP, Ruby, Python, Java, etc.). They should also provide good documentation.
The reason you want to be extremely choosy with which APIs you use is that yourweb app’s performance can be affected significantly by these third-party web services.
And even if you choose a good high-performance API, you will not escape the vagaries of the API owner’s company direction. For example, Twitter’s API has been subject to criticisms because of the company’s choices to limit access to their API and enforce new terms of use, significantly crippling some web apps with those changes.
Be especially mindful of web app ideas that have core features relying heavily or solely on third-party APIs. External APIs can change at any time, and these changes can drastically affect the direction and success of your web app.

7. Focus on the Excellent Execution of Your Idea

I can’t think of one web app that was successful based solely on being "the first."
Rather than spending time and money on lawyers drafting your non-disclosure agreements (NDAs) and rather than being fearful of someone "stealing" your idea, you’re much better off thinking about how you’ll execute your idea effectively.
In the words of a very successful and well-regarded entrepreneur, Derek Sivers: Ideas "are worth nothing unless executed."
Ideas to Sivers are just multipliers of actual success. An idea alone won’t generate anything fruitful:
What makes a great product great is not about your one big idea — it’s the thousands of smaller ideas that are executed very well.
It’s the small idea of using a "pull to refresh" interface to save the user from having to reload the page. It’s conceptualizing the idea for making image uploads simpler and easier. It’s the multitude of little ideas that you effectively execute that make the difference.