Over the last few months the Dallas Node.js meetup has been pretty spotty attendance-wise. Actually, it just hasn&#8217t been happening. It is time for that to change.

Several of us local Dallas peeps who are interested in reviving the group have been meeting the last few weeks. Tomorrow we are going to converge at the &#8220official&#8221 meetup time and place to discuss. Do you want a Dallas Node.js user group? Would you go but only if we changed locations? Would you go if there were pizza? What would you want out of the group? What would you expect? All these things are up for discussion tomorrow.

We want this group to happen and want feedback from anyone who might be interested. So show up and tell us what you think! And if you are going, go rsvp. What say you?

Let&#8217s talk about mobile web development some more! The principle of progressive enhancement is a general principle of front-end web development with wide applicability. Because you have a wide range of capabilities in mobile browsers, the principle is very important in this space as well.

So what is &#8220Progressive Enhancement&#8221? It is the practice of building a web page (and can apply to Css, Html and JavaScript) that works broadly, but with enhancements for more advanced browsers. Perhaps an example is in order. Note the following:

In fact, that rectangle might be so cool that it isn&#8217t a rectangle at all. On most newer browsers, you should see something like this:

On not as awesome browsers (in this case IE 9), you may see something like this (or worse, because this is actually pretty close).

Here is the css:

<style type="text/css">
    #_rockinsamplesquare
    {
        background-color: rgba(240, 140, 240, .2);
        border: solid 1px #555;
        border-radius: 20px;
        box-shadow: 5px 5px 5px #AAA;
        font-family: helvetica, verdana, sans-serif;
        font-size: 1.3em;
        font-weight: bold;
        padding: 20px;
        text-align: center;
        text-shadow: 0 0 20px #000;
        max-width: 450px;
    }
</style>
  

The basic idea behind progressive enhancement is that some things are not crucial for an app/site and if they are not, progressively enhance the thing so that better browsers can have a better experience. But the key here is that older browser users don&#8217t suffer. They still get to read the content or use the app, whatever the context. They just may not get the same experience as someone else.

I remember employing this on a feature we launched when I was on the international team at work. We had a fancy new advanced search page that we wanted to try out. One (very small) part of the design included a portion of the page that had rounded corners. The old school pre-Css 3 way of doing this was to use images to round those corners off, but a) that seemed boring and b) I figured it was too insignificant of a &#8220feature&#8221 (if you could even call it that) to spend time on, so I rounded the corners with Css. Did it look better with rounded corners? Maybe a bit. Did it really matter if someone viewed the site in IE 6 and didn&#8217t see the rounded corners? Not at all. I saved time, had a less annoying task and still created a good enough experience for everyone, though it differed between browsers. This is progressive enhancement.

The principle could also be applied to features. For example, you could use the newer application cache features of Html 5 to enable offline access to some content on your site for those who have it. Browsers that lacked support would simply not be able to browse the site while offline, which is normal behavior anyway. Assuming this was not a key feature of your website, this is another good example of progressive enhancement.

Next

What is next? We are going to talk about the problem of splitting your markup to support desktop and mobile.

A couple days ago I blogged about the viewport meta tag. It is a handy little meta tag for your mobile sites, for sure. For installment 3 of 7,867,543 on mobile web development, the next natural step is to talk about media queries.

Of course, if you are not familiar with them you are probably asking yourself, &#8220what are media queries&#8221? Fine question. First of all, &#8220media&#8221 here refers to the thing you are viewing the content with. Once example is &#8220screen&#8221, which is what you would use to target a phone (and the only media I have used these with media queries). Okay, so you get to target your phone. Big deal. Well, fortunately, you also get to target particular properties of your phone, like its height, width, orientation, resolution et al. I end up just using width pretty much all the time, but your needs may vary. What media queries allow you to do is target a chunk of css for a device as long as it meets particular media requirements.

So maybe we should say this another way. Media queries allow you to customize the css of a website for a device easily. We have been able to do this for quite some time; it has just been annoying. An example is in order at this point. Here is one I wrote just a couple hours ago:

@media screen and (max-width: 320px)
{
  #content
  {
	padding: 20px;
  }
  p
  {
    font-size: 1.4em;
    line-height: 1.2em;
  }
}

Line 1 says &#8220as long as this is a screen viewing the page and as long as its width is less than 320px, apply this css.&#8221 In this case I was decreasing the padding for all the content, lowering the font size and shrinking the line spacing. You could also specify a range like so:

@media screen and (min-width: 321px) and (max-width: 480px)
{
	/* normal css goes here */
}

That media query will apply all the contained to any screen between 321 and 480 pixels wide, so it could be used for styling many phones in landscape mode.

External Style Sheets

These media queries can also be used to selectively apply whole stylesheets. Behold:

<link rel="stylesheet" type="text/css"
  media="screen and (max-width: 320px)"
  href="awesome.css" />

If you were to try this in chrome, you would find that though the stylesheet is loaded regardless of screen width, the css in it will only be applied if the media query resolves to true. Sweeeeeet.

Support

Support for media queries these days is actually quite good in recent browsers. It has been supported in at least four versions of Firefox and Chrome, at least since iOS 3.2, at least since Android 2.1 and IE 9. As you would probably expect, IE is the problem here.

Fortunately for you, there is a polyfill to shim this functionality into older versions of IE called Respond. It works for IE 6-8 (and perhaps other older browsers as well). I haven&#8217t tried it but I do not imagine they are lying, especially since I&#8217ve heard of a number of people using it.

In the mobile world, support for this is really good, as long as we are talking about modern phones like iPhone, Android and WP7 (well...as far as I know not the first version of WP7). For many older phones you are likely going to be entirely out of luck unless the mobile phone uses Opera mobile, which has had support for quite some time. In those older phones you will have to go a different route entirely, but that is a discussion for another day.

By the way, css media queries work well for tablets too. Your iPad, Kindle Fire or Android tablet all respond to media queries, so use them if it makes sense.

What Would You Use This For?

So what would you use this for? It can be applied to anything really but there are some very common use cases. Perhaps your text is too big or small when your site is viewed on a mobile browsers. Use a media query to change that for a certain range of devices. Perhaps the header graphic is too wide to fit on a mobile device. Fine. Remove it, or replace it with another. Or perhaps that three-column layout won&#8217t work on your phone (it won&#8217t). Nuke the floats (hopefully you were not using tables for layout) and move to a taller, one-column layout for mobile.

How about you see for yourself? Go to the Media Queries website (http://mediaqueri.es/) and try out the examples it has. Visit the example site, resize your browser and see the magic happen. This site as well as my home page also use media queries.

Next

If you are up on your web design trends, you will already have noticed that we have been covering some of the basic ideas in &#8220Responsive Web Design.&#8221 In the next post, we will dig into this more.

Yesterday I posted what is basically my intro to this series on mobile web development. For a bit we are going to talk about some things that affect mobile web development whether you are focusing on just making some content work on mobile or if you are building a mobile web app. The first thing to talk about is the viewport meta tag. To show what this does, we&#8217re going to iterate through making a page mobile-friendly. First, the page without modifications:

<!DOCTYPE html>
<html>
<head>
  <title>Viewport Test Page</title>
  <style type="text/css">
    body
    {
      background-color: #CCC;
      margin: 0;
      padding: 0;
    }
    #content
    {
      background-color: #FFF;
      padding: 10px;
      width: 940px;
    }
  </style>
</head>
<body>
  <div id="content">
    <h1>Page Header</h1>
		
    <p>Lorizzle ipsum dolor i'm in the shizzle amizzle...</p>

    <p>Sizzle vitae bizzle in arcu go to hizzle consequat...</p>
  </div>
</body>
</html>

As far as Html goes, simple stuff. You have a header and two paragraphs (clipped here because actually showing all the gangster lorum ipsum does you no good) wrapped in a div. The width of the content is constrained to 960px (940px width plus 20px padding), but that&#8217s it. Here is how it looks on my iPhone.

Okay, so that&#8217s mostly unreadable. Prepare for much pinching and zooming! Most links I click on in Twitter end up on pages that look like this, which is not awesome. The problem is that the content of the page has been scaled to fit within the viewport of the device.

Wut you ask? Well, the viewport on a device like the iPhone is the part you can view. If viewing the device in a vertical orientation, you have 320px of width and 480px of height (double that for retina screens though all that I am about to show you works equally well on both resolutions). Most pages I visit via the Twitters look like this because I have a viewport of 320px but the size of the site is set to something much larger, like 960px. Fortunately, using the viewport meta tag can help things. Observe the following tag:

<meta name="viewport" content="width=device-width">

If I add that to the head tag of my page, upload it and view it on my iPhone, I get this:

It is better, but not quite ready yet. It is at this point more readable but you still have to some scrolling back and forth. Not cool. So let&#8217s change one thing in our Css. Fixed-width dimensions on web pages make things much more difficult for making something work well for mobile, so let&#8217s change the width to max-width. We get the following:

Well golly, that&#8217s much more readable. Surely in more primitive cultures I would be called a magician for such wonderous feats.

There is more you can do with this meta tag. Let&#8217s try setting the initial scale of the page. If we were to set this to 1, we would see what we saw before. Boring! Let&#8217s take this up to 11!

<meta name="viewport" content="width=device-width, initial-scale=11">

Bam! In yo face! I have no idea why you would want to do that but at least you now know that you can. You can also specify a value for maximum-scale. Another option is to remove scaling by putting user-scalable=no. And as you might guess, this is often a bad idea because you run the risk of hurting usability.

So there is the viewport meta tag. But there is still a problem. What if things don&#8217t look quite right at this smaller size? It would be nice if there was an easy way of styling the page differently depending on the page width. Fortunately there is a way to do this using Css media queries, which we will discuss next time.

The mobile web is on my brain constantly these days. This is partly because I work as a development lead for Match.com in their mobile group, and I happen to be working on a big mobile web project for them (yet-to-be-launched). This is partly because I have...um...other projects around mobile web going on. This is also because Match gave me an iPhone. My first smartphone was a Windows Phone 7 device. Given that I have in the past much indulged myself in the Microsoft Kool-Aid, I bought that thing the day it came out. In general the phone was very good but the browsing experience was very bad (it got better with &#8220Mango&#8221, but it remains less than thrilling). So owning that deviced did not at all excite me about mobile web development. But then I switched to the mobile group at Match and they gave me an iPhone. Suddenly, I had a device that had a great browser. Perhaps you are surprised, but that makes a huge difference. And I&#8217m a web developer by trade anyway, so the world of mobile web development offers an interesting new avenue.

So for all those reasons, I am quite excited about mobile web development. The last few months have involved a lot of reading and writing code, and I have some things to share that I think many developers will find helpful.

Tech

Good mobile web development takes a mixture of engineering and design thinking. The stronger you are in both realms, the better off you will be. If you are not strong in both, either learn what you don&#8217t know or find a partner. I am not a designer. I don&#8217t pretend to be one. If you read this blog, chances are you probably aren&#8217t one either. But I do read a lot in web design and can bridge the two worlds of engineering and design on the web enough to point you in the right direction. Reading on web design does not make you a designer (and a good designer is worth their weight in gold), but reading their stuff will at least allow you to understand them a bit more. And who knows, perhaps you will pick up some knowledge of design along the way.

If you are a designer, this series can be useful for you as well. I probably won&#8217t have much to say to you in terms of Css or design, but you are going to see a lot about JavaScript, and should get some exposure to some server-side stuff.

Alrighty...so what do you need to learn to do this whole mobile web thing effectively.

You should know some server-side platform. Technically this isn&#8217t necessary, but unless your site just serves static Html, you will need to have something here. What platform you choose does not really matter for mobile web development. Php, Ruby on Rails, ASP.NET, Node.js, Django...does not matter. The concerns of mobile web development are mostly something that happens client-side. Now, that being said, there are sometimes things you can do on the server-side to help you deal with your assets and whatnot, and we will discuss this. And I&#8217ll try not to just use ASP.NET.

You need to know Css. Css is about presentation, making your site/app look the way it should. Many developers think that Css is something that designers deal with, and to a certain extent they are right. Using Css effectively to create a fantastic user experience is something designers are uniquely skilled in. But knowing what to do and how to do it are completely different though complementary skill sets. Many web developers leave both up to the web designer, which is a shame. The question of what is a question of design, and I may not be able to help you there. But the question of how is as much an engineering task as any. So learn Css if you do not know it. Fortunately the core concepts of Css are mostly quite simple.

You need to know JavaScript. The type of mobile web project you work on will determine how much JavaScript you need to know. If you are just making a mobile version of your blog, you may be able to get away with none at all. But if you are going to build a mobile app, you may need to know a lot. It depends on what you are doing. We will talk about this more later.

You need to know Html. Html is what you send over the wire. It is the document that all your JavaScript and Css are built on.

Big Questions

When considering the prospect of building a mobile website, there are a few questions of particular importance because they greatly impact how you build what you build.

• Is this mobile website primarily about reading (e.g., are you making a mobile version of your blog) or is about doing something (e.g., it is primarily for performing a particular function, and you could imagine it being seen as an app)?
• Are you making a mobile version of an existing site, or are you starting from the ground up?
• Do you intend for your mobile site and &#8220regular&#8221 site to be the same site, or do you need to separate them?
• What range of devices are you planning on supporting? Are you just supporting recent versions of iOS and Android? Or do you have to support old school feature phones? Perhaps somewhere in between.

Books

Here are some books to start with, and I would work from top to bottom.

• Designing with Web Standards (3rd Edition), Jeffrey Zeldman.
• Responsive Web Design, Ethan Marcotte.
• Mobile First, Luke Wroblewski.
• Bulletproof Web Design (3rd Edition), Dan Cederholm.
• JavaScript: The Good Parts, Douglas Crockford.
• JavaScript Web Applications, Alex MacCaw.

There are a lot more useful books out there, and we will probably mention a number of them. But start here. And then go spend a lot of time on A List Apart, and follow links from there.

So there is your ever-so-brief introduction. Next we will cover a small item that pays large dividends, the viewport meta tag.

Last month I read a great book. It is one of those &#8220must reads&#8221 about JavaScript as far as I&#8217m concerned. I&#8217m talking about Alex MacCaw&#8217s book &#8220Javascript Web Applications.&#8221

As the book progresses he walks you through various concepts around building better JavaScript web applications. He starts fairly simple, focusing on JavaScript inheritance and then events. Next he starts moving into subjects like building models and &#8220ORM&#8221s as he calls them (I think a poor term for what he is talking about, loading data), controllers, dealing with state and templating views. If you have spent much time with client-side MV* frameworks, you will notice that he has basically talked about the core bits of most MV* framworks.

Then there are a few miscellaneous chapters, on subjects like dependency management (an excellent chapter) and a few other useful, though perhaps not exciting chapters. He ends the book with a chapter on using Spine.js (his MV* library), a chapter on Backbone.js and finally a chapter on JavaScript MVC.

What I like so much about the book is that he leads you through the thought processes behind the core ideas of many client-side MV* libraries then shows you how to use them. It&#8217 a great way to get into these types of libraries. I&#8217ve been interested in JavaScript MV* scene for a while and I&#8217ve used Spine.js the most. Having Alex walk through his thinking on how the bits should fit together is very helpful.

So what if you aren&#8217t planning on using Spine.js? Well, the books about the ideas behind these frameworks. It&#8217s about modular code, JavaScript techniques and inheritance. That means it has quite a bit to say about JavaScript for the large number of us developers these days who seem to be writing more and more of it. If you are not interested in the various MV* frameworks, you can still get a lot out of this book.

But a little of a warning before you start working through the book. If your JavaScript skills are a bit rusty, I would recommend getting re-acquainted with JavaScript before you read this book. Perhaps get Crockford&#8217s &#8220Javascript: The Good Parts.&#8221 MacCaw's book good read but not an easy read. But it was certainly worth it.

You can get your copy here at Amazon. If you live in the Dallas area, you can also pick up a copy at nerdbooks.

This month I have two technical talks, and in this case they are back-to-back tomorrow and Thursday. I didn't need to relax anyway...

The first talk, Wednesday night, will be for the North Dallas .NET User Group. The title of the talk is "What You Can Do Today with Html 5 and Css 3 on Mobile Devices" and is a code-focused talk with lots of demos. Unless you have been paying pretty close attention to the mobile web world, you will probably be surprised about what you can do out there and get away with. We're also giving away a brand new Kinect, so somebody is going to get really lucky. If you are coming and you own a tablet or smartphone with a decent browser, bring it.

On Thursday I'll be meeting with the Dallas C-Sharp SIG. I'll be giving a talk entitled "What Client-Side MV* Frameworks Can Do For You." This will be a very Javascript-heavy talk and should be particularly useful for those who finding themselves writing more and more Javascript (isn't that all of us?).

Both talks are for .NET user groups but the material in both are quite applicable generally. So if you're not all that interested in the .NET world but are in web development, you'll may find both interesting anyway. One of them will even involve some Node.js, but I won't spoil it and tell you which one :)

Hope to see a lot of you peeps there!

This last Saturday the North Dallas .NET User Group sponsored “Full Stack Day”, and all-day, hands-on event to learn a full stack for web development, DB (Sql Server), web framework (ASP.NET MVC, C#), Css and Javascript. Many who do web work only know part of the stack, and my contention is that it is very useful to get some level of proficiency in the whole. So all day Saturday I taught and live-coded a to-do list app with about 35 people as an exploration of the full stack, along with some time for hands-on labs.

As I went I checked in the source code to Github so they could browse it on their own during the labs. They were all supposed to bring their laptops with software installed (Sql Server, VS 2010, MVC 3) for them to hack around on things during those hands-on labs during the day.

In some ways it was an experiment. I’ve never experienced an event like this (though I’ve heard of events somewhat similar) and wanted to find out if it was both possible and useful to do. So in some ways these three dozen people were my guinea pigs. So lets see how this turned out.

Who Went?

Only 61% had attended a NDDNUG meeting before, so a large chunk came through other avenues than our group. I think Shawn Weisfeld recruited a number of people that he knew, so thanks.

How familiar were they with the technologies?

As for how their occupation jived with what we were doing that weekend, 65% said they were developers, 5% database engineers, 5% designers, 15% hobbyists and 25% those who were just trying to get started.

What We Did

Getting Ready

I showed up at around 8. The event was supposed to start around 8:30.

Sql Server Time

Originally I planned to start with ASP.NET MVC but changed my mind about a week before and decided to work from the bottom up. In terms of instruction, I felt this section went well. In terms of installation, this section was just problematic. I went the route of having them install Sql Express and Sql Management Studio so they had something to use to connect to it and run queries. Wow that was problematic, and I don’t blame the attendees. I figured the best way to get it installed was to use the web platform installer. So I told them to install that, find sql management studio, and then install that. So here is what the opening screen looks like for the WPI:

Several people were confused (I also think this is confusing navigation) and didn’t know there was anything other than what they saw on the left nav, which didn’t show them management studio. Consequently several installed the Sql Server data tools, which they didn’t need. Frankly, the whole process of getting sql server installed and running is a mess in my opinion unless you do it all through VS, which I’m not used to doing.

Looking back, this is definitely the most important process to streamline. Either MS needs to come up with a better installation plan for Sql Server and its tools or I need to do something different next time. They were supposed to come with it installed (and most did) though some had issues and it made sense for us to help get them started.

In terms of content, I showed them how to create tables in the designer, how to generate scripts from that so they can create their database schema via script if they wanted to, basic crud querying and left and inner joins.

Massive

So I needed them to be able to hook up the code to the database, which I had just shown them how to use. ADO.NET would have taken way too long. Entity Framework would have been easier. NHibernate would have also been easier, but both have a significantly higher concept count and startup tax than Massive, so I showed them how to use it to query the database. From my perspective this worked very well and I got a number of positive comments on it from the students. Big thanks to Rob Connery for creating this. Simplicity is much harder than complexity when it comes to code, and Massive does a fantastic job of being simple.

The whole database portion took about 30 minutes longer than I planned but I’m glad I didn’t go any faster. It might have been good to go a little slower.

ASP.NET MVC

Though WebMatrix would have probably been a good choice to use, I decided to teach them ASP.NET MVC. It’s pretty easy, after all. The app involved three screens, one to list the tasks, one to add, and one for a deletion confirmation page. In that process I showed them the basics of Html as well, and showed them how to create the controllers and views, and how to use their Massive knowledge to get the data from the database and interact with it on the site.

Css

Next was an introduction to Css. I started by showing them the basics of text formatting and moved on to floats and layout. We then moved on to turn our header into a post-it note (which they got a kick out of) using some Css 3 goodness. We also discussed the concept of progressive enhancement and how they could use Css 3 selectively today to upgrade newer browsers but still give older browsers something decent to look at. After all, do websites really need to look the same in every browser? I think not.

After the Css section I asked if they wanted to do hands on labs and they just wanted to move on to the Javascript portion. Hmmm…more on this in a bit.

Javascript

The final piece of the full stack was Javascript, which we saved till last. I gave them a very short introduction to the language, including variables, how to create functions, how functions can be passed around and prototypical inheritance. This whole passing functions around thing was very important to show, because I then showed them something that uses this extensively…

jQuery

So then I showed them jQuery, which they liked. To show them the power of Javascript and jQuery, we then took our three-page app and turned it into a single-page app, making the add and delete functions a part of the main page. We had jolly good fun showing and hiding divs, nuking list items and making some ajax calls. My most embarrassing live-coding mistake here was to slip up and try to use the “dynamic” function of jQuery when I really meant to use the “delegate” function. And then you google "jQuery dynamic" and find nothing useful...ah, the joys of live-coding in presentations.

Chat Time

Because we skipped a hands-on lab time, we finished early, around 3:00. I figured I might get a mass exodus at that point. I told them that we could sit and hack through more stuff on the website or just talk about things and they chose to mostly talk. And I didn’t get a mass exodus. We spent a good bit of time on mobile web development especially and I did a little example of using media queries to dynamically style your page. Most ended up leaving between 4:00 and 4:30, though a few of us hung out a bit longer and looked at some code and chatted. And thus the event ended.

Concluding Thoughts

Would I do this again? Certainly. I think this kind of event can definitely work and those who filled out the survey at the end certainly agreed. Doing more things like this could definitely help the developer community. Even though we have a decent number of weekend events in the area like Dallas Tech Fest, Dallas Day of .NET, etc., these tend to be very different in flavor because they are multi-topical/non-serial, i.e., bunches of random topics that people can pick and choose from. I like these kinds of events quite a bit but they hit a different audience and solve a different problem. Events with a smattering of topics are of more benefit for those more advanced technically because it gives them a chance to skip things they already know. I think serial events can be more suited for beginners since they can see a concept like web development worked out over a lot of technologies and with the same sample code. Of course some will be beginners in some areas, so something like this event can benefit those who have been in the field for years (and there were a number of those this weekend who fit that category). Of course you could do the same type of serial event as a deep-dive, which many this weekend wanted on various technologies.

So DFW technical leaders/influencers/speakers/whatevers, I think we should do more of these.

Even though it worked out pretty well this weekend, there are some things I would change.

First, something different needs to be done with the whole Sql Server thing. I think we ended up with most people setup but it was a mess and slowed us down.

Second, I’m questioning the value of the hands-on labs. I first started rethinking it when they wanted to skip them to see the content more quickly. In the follow-up survey, no one mentioned that they found them valuable (though everything else got mentioned). What might work better would be sessions till mid-afternoon followed by a few hours of installation help and hands-on lab time.

Other Feedback

Here’s some other feedback I got from the attendees that people might find of interest.

1. Needed more breaks (I didn’t have enough…oops)
2. They liked having the code put on github
3. It would have been helpful to have a more completed version of the app for them to download and mess around with
4. Needed to go slower (I can see that)
5. Less time on installation and setup (no surprise there)
6. More depth (that would have been easier if we wouldn’t have had the lab time)

Sponsors

Improving Enterprises also sponsored this event for us. These people are fantastic. They bought the pizza for us, which allowed us to keep the price incredibly low ($15). Thanks to Brian and Kyle for coming and babysitting us on a weekend. Improving also sponsors us for the North Dallas .NET User Group meetings. You guys are great!

Also a big thanks to Shawn Weisfeld for bringing out some drinks left over from a previous event and for recording us.

Also thanks to Darren, one of my fellow NDDNUG officers, for coming and hanging out all day with me and helping those who were stumped.

Though mine is still in process of being shipped, Match received their Kindle Fire devices today. I got to play with it a little and test some pages with it. I also needed its user agent string, which I couldn't find on the web. So here it is:

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_6_3; en-us; Silk/1.1.0-80) AppleWebKit/533.16 (KHTML, like Gecko) Version/5.0 Safari/533.16 Silk-Accelerated=true

User agent strings tend to be full of lies anyway, but I expected a very Android-like user agent string. I was surprised to see the Macintosh-ness of it. Anyway, there is the first gen user agent string of the Kindle Fire if you are looking for it.

As for the device itself, I like it so far. I was surprised at the heaviness and the usability definitely needs some work in various areas. It was also frequently choppy so could use some more power. But still, it appears to be a nice device on first usage.

I have always been a "full stack" kind of guy. When I started teaching myself to program back in 2003, I had an app in mind that required a some knowledge of css, databases, and everything in between. At the time I didn't even really know what those were but eventually I figured it out. I'm doing Full Stack Day to help others get started with all the technologies you need to build websites.

If you think about it, there are just way too many technologies you need to know about to build a decent data-driven website.

• Database - you need to store that data somewhere. Sometimes just putting it on the file system works but using databases really can make things a lot easier.
• Server-side web framework - Something needs to talk to the database and generate that Html. I've used ASP.NET (webforms and MVC), Ruby on Rails and Node.js. They each have their strengths and weaknesses.
• Html - There is, of course, the Html itself for your web pages. This is the easiest part.
• Javascript - Depending on what you are doing on the web, strong knowledge of Javascript may not be required. But these days it is a lot more common to use it than before, so you should really understand it. There are things you just can't do without it.
• Css - Want to make your web pages look nice? Css is the technology to do that. Knowing Css doesn't make you a designer but you need it to effectively create a design on the web.

That is a lot. Though I had some experience with Html by 2003, I didn't really have much with the others so I jumped in and learned them. It was a bit painful at first. Trying to learn all of them at the same time was daunting but I worked through it.

Full Stack Day is something I am putting on with the North Dallas .NET User Group to help people get started in this group of technologies. It is meant for those who know some but not all, though someone generally unfamiliar with web stuff can still benefit. We're selling the tickets for pretty cheap ($15) and the funds will go to the North Dallas .NET User Group. It's an all day event on Dec 3 and is about half instructional time and half hands-on lab.

So if this is something that would benefit you, sign up. There are only 35 tickets left so sign up soon. If you have an questions, put a comment in below or contact me otherwise.

Update:

If you are coming, make sure you have Visual Studio 2010 installed, MVC 3 (both of which you can get by installing what is shown on http://www.asp.net/mvc - hit the "Install Visual Web Developer Express" button) and sql server 2008 express. You should also get the 2008 management studio express software installed. You can also get all these things (I believe) using the web platform installer.