Scott Radcliff

Getting Started With Web Development

If you are thinking about getting started with any type of web design or development, you have likely seen lots of stuff about code schools, Rails workshops, and bootcamps. Not so much about how to get started as a complete newbie or how the very basics of web design and development work.

I'd like to take a few moments and explain to you how the core of anything on the web works. The reality is that without HTML, we can't display anything on the web. Without HTML, none of the previously mentioned ways about learning matters. HTML is the foundation of the web.

HTML isn't that hard or scary, and once you understand it, things really start to make sense.

How HTML Works

HTML is an acronym for HyperText Markup Language and it's core job is to display what you tell it. HTML will not decide how to display anything. It will know what to display what you tell it to.

The first thing to understand is that HTML is just a text document. It's just like any other document. The only difference is how it's formatted and it's file extension (the .html part).

Warning: Microsoft Word, Apple Pages, or any other Word Processor does not create text documents. I am referring to plain text documents. You will need a text editor. Check out Atom or SublimeText.

To create an HTML file, you can simple open a text editor, create a new file with any name, and save it with an html extension. A sample html file might be called intro.html

It could look like this:

<html>
  <head>
    <meta charset="utf-8">
    <meta name="description" content="my first webpage">
  </head>
  <body>
    <h1>Hello World</h1>
    <p>My First Document</p>
  </body>
</html>

HTML Tags

If you have never seen HTML before, there is a lot here. I'll break it down.

The <html> element should actually be <!doctype html>, but the browser tries to display a new document. You can google HTML5 doctype to see how it should be formatted

The first thing to notice is all the greater than (>) and less than (<) signs. These are part of HTML tags. Inside this greater than and less than signs are HTML elements. This is the part that tells the web browser what to display. You can see a full list of HTML elements on Mozilla's Developer Portal.

Anything you place between the opening and closing tags are part of that element. For example, <h1>Hello World</h1> is a heading that displays the text Hello World because we have instructed the browser to display a heading by using the <h1> html tag, and to make that heading read Hello World because we placed that inside the opening and closing tags.

Some tags don't have the closing part. These are self-closing tags. More on those another time.

Head Section

Once you get past the doctype, you see two sections. Head and body. These are the main sections of the document. First the head section. This is all meta data. It's just giving the document information. If you look at the meta tags, you will notice that the description meta tag has a name and content. This tells the browser and search engines (we will save search engines for another time) what this web page or web site is about. It does absolutely nothing for what is displayed on the page.

Later on in your learning, when you get into CSS and JavaScript, this is where you will tell the document how to get to those files.

Body Section

Think of the body section as your canvas. Not to be confused with the JavaScript canvas. I'm simply using the word canvas here to illustrate that this is the part of the document that you actually see.

Anything you place between the opening and closing body tag will be displayed on the page.

In this example, the html page is displaying Hello World as a heading, and My First Document as a paragraph.

You will notice that a lot of HTML elements are simply abbreviations of larger words. Things like img for image, p for paragraph, and a for anchor.

The body section of HTML documents can get pretty complex with things like forms, large images, and complicated layouts. Understanding what is in the body section is critical. It can get overwhelming very quickly. Spend some time playing around and continually build upon your knowledge.

Go Forth and Play!

Well, that's the basics of an HTML page. If you follow that structure, you will just need to know that elements to use to display what you want. That just comes with experience and playing around. Spend some time on Mozilla Developer Portal and start experimenting.

If this helped you at all, I'd love to hear from you. Reach out to me on Twitter @scottradcliff or send me an email at scott@scottradcliff.com.

Start Writing To Think

The next time you are stuck on a programming problem that you are trying to solve. Things just aren’t clicking. You can’t seem to wrap your head around what a solution might look like. Just start writing.

Open a text file and start writing what the problem is and what a solution might look like. Really go into detail. Explain the edge cases, any parameters that will effect behavior, and any errors that would be returned.

Think of this as explaining to someone how to use your software.

I realize this may sound a little goofy. Consider it the solo version of explaining a problem to someone. You are, in fact, explaining the problem to someone. That someone just happens to be you. And you are explaining it to understand it. You get an added bonus of being able visualize a good design from a bad design before you program it.

The Perils of TDD and the Lack of Thinking

I’ve sounded off before about losing the planning stage with TDD. When you start out doing TDD, people rarely talk about thinking through what you are building or thinking about what you need to test. That is, aside from Rich Hickey, but he’s not really putting it in a TDD context.

Most of the TDD examples just jump right into code and driving your design through tests, and that’s great, but when you don’t know where you are headed, you’re really just wasting time.

Writing about the problem and your solution will give you a solid end goal. And with that end goal, you’ll be able to start thinking about all the pieces that will need tests.

It’s at this point that you can jump into a TDD workflow. You have a solution in mind and a good idea of the steps needed to get there. Those are your test cases.

Example Time

So what does something like this look like?

Here is a super hypothetical example of a feature that allows someone to share something on a fake site called SuperDuper and then sends the result back to an API.

When a user shares the link on SuperDuper, we get an id back of the post. That id gets saved to a cookie and a POST request is sent to api/superduper/:id, then a new Order record gets created and a success message is returned.

If the user tries to share but it fails, the application will take into account that the user tried, but the failure was not due to user error, but rather a system error.

So, what did learn by taking the time to write this out?

  • We learned what the url structure of the API might look like.
  • We learned that we need to store some data in a cookie or other storage mechanism.
  • We discovered that we have some specific errors that could require special consideration. Maybe we have two types of errors?

This type of communicating to yourself almost always exposes something you might have missed. The one that sticks out to me are the two types of errors. User and system. This would certainly lead to a better design and a better experience for the user after taking these errors into consideration.

One System to Rule Them All

Building software really is a personal thing. Even on a team, developers have personal preference and often have to make trade-offs in favor of the way the team likes to build software.

There is no right way.

This is just one of many ways to build software. I often drop back to this when I am stuck.

I Want To Start Teaching Again

Teaching is fun and I miss it. When I taught, I had this great sense of helping people that is really hard to describe until you teach someone. There is this real sense of pride in knowing that you helped someone acquire some skill that they didn’t have before they met you.

Most of this happened in a classroom for me. I learned a ton about how to approach teaching, but honestly, our secondary education system is awful. It’s all driven by money. They teach what the dollars tell them to. That is why I left. I could see the program that I was part of head in a direction that I didn’t agree with.

I’d like to teach again.

How do I want to approach this

I have a few ideas of how to approach this. After all, I’ve been thinking about this for years. But I think for now I would just like to use the Internet as my platform to produce teaching material. Tutorials, both written and video, and both here and elsewhere. Maybe a downloadable PDF or two. I might even have an ebook of some sort in me.

The Internet is the perfect platform for teaching. We have barely scratched the surface of what we can use the Internet for as far as learning/teaching is concerned. I would like to experiment with this. There are plenty of bootcamps, code schools, and similar options. But where are some of the experimental things that venture into new ways of learning? It’s worth noting that Code School is the best of any code school that I’ve seen. The way their system integrates learning and repetition into their screencast system is awesome.

The best thing about teaching is the learning. I wonder if I could pick things to learn by teaching and just start writing tutorials based on that? The problem with this is that I am teaching something I don’t know much about. This might work if it’s in small portions. Maybe something like the old Railscasts site. That might be fun.

Another option is to start a new site of just tutorials/learning materials. The downside to that is that I would have another site to maintain.

And yet another option would be to use something like YouTube to host some videos of learning materials.

Maybe it’s just as simple as a new section on this site.

The common core of all of these is that it’s some sort of publishing platform. If that’s the case, I’d like to own it. Putting my work on someone else’s platform is scary. Considering I have the skills to build my own system, I’d be stupid not to own the entire system.

At any rate, I have no idea will this end up. I do know that I would like to start small, and start branching out into technologies that are currently not being used.

Hits And Misses

Last night Kobe Bryant, arguably one of the best basketball players of all time, set a new NBA record. For misses.

He has missed 13,418 times. Yet, he has 5 championships.

He has 5 championships because he doesn't know how to quit.

This was a great reminder that no matter how many times I fail or screw things up, I need to get up and try again.

Shipping Something

Ouch. Seth Godin nails it. Again.

On taking the plunge and shipping something.

It's easy to be afraid of taking a plunge, because, after all, plunging is dangerous. And the fear is a safe way to do nothing at all.

Source: Taking The Plunge

What Would You Do With The Skills You Have If Not Driven By Money

I posted this to facebook yesterday. Just something that has been floating around my head lately.

There is this question that's been floating around in my head for two days. What would you do with the skills you have if not driven by money, but driven by societal change. In other words, if you could forget about money and only concentrate on touching/changing lives everyday, what would your work look like?

It's especially interesting in my field (software), where we throw millions at useless companies that provide very little value to society. What if we threw just a fraction of that to a company that really puts a dent in something real. Off the top of my head, I can think of hunger, homelessness, retraining the unemployed, domestic violence, human trafficking, and the list goes on and on.

What if you/I only worked on projects that helped improve humanity? The first issue is money. I mean we have to eat I don't have no answer "yet", but I have the beginnings of a thought. If we can throw 55K at potato salad, surely we can crowd fund a developer to work on nothing but software that promotes social good for a year.

To be continued...

Continuous Improvement

It's funny. I think a back to where I was when I was a total newb. There was so much I wasn't good at. It was easy to spot weakness. Pick one weak point and improve. When I thought that was at a good point, pick another one. Repeat. Eventually, through the process of elimination, I got better.

It's easy to lose this skill of noticing weakness and improving. Well, losing isn't the right word. Ignore is more fitting. It's easy to ignore your weaknesses, especially when you work alone.

The minute you join a team, those weaknesses are exposed with a total disregard as to whether you want to address them right now or not. You have to. The choice has been made. Level up.

Noticing Weaknesses and Building on it

At first, it just crushes your ego. It's like being a newb all over again. It's really easy to get down on yourself when you have done what you swore you would never do. You failed to keep up. You fell behind. But not all is lost. It's actually pretty easy to get back on your feet.

Setting Some Measurable Goal Each Week

First, pick one thing your not very good at. Maybe it's code reviews. Maybe it's testing the right things. It could even be as simple as communicating better. Actually, if you suck at communicating, do that first.

Once you have this skill you want to level up, make it your goal for the next week. But it has to be measurable. You have to be able to look at this week and know that it's better than it was last week.

It's really all about shipping

For me, it's all about shipping. If I am shipping more, I am leveling up somewhere. If it's communication that I am working on, and I shipped more software this week than I did last week, I can look and see why. If communication was a big part of that, it will show.

Than I move on to the next thing. Get better every week.

Solving Problems

This is a great piece about what it means to build software. This is exactly where I am at. Programming for programming sake doesn't excite nearly as much as it used to. Solving problems is what gets me up in the morning and excited to build software.

I’m not coding. I’m not building a business. I’m not going to school.

Yep. But I'm not totally on board with not building businesses. I think that's a part of it for me, just not the main part.

I’m here to solve problems.

Solving problems is the main part. The most important.

via Throwing Fireballs

Paul Graham On How To Start A Startup

By far the best talk from How to Start a Startup so far. Entertaining, informative, interesting, and valuable.

Seven Day Startup

7 Day Startup

Dan Norris has written a free e-book on starting a business in 7 days based on his experience. How you feel about the book will probably vary based on your exposure to the startup world and/or bootstrapping businesses. There is nothing about VC or pitches. Just a game plan for worrying only about stuff that matters and how Dan approaches his business.

I had heard most of this stuff before. But I did enjoy the book and it has changed my thoughts on an upcoming project.

Hey! It's free. Go read it.