Monday, April 7, 2014

Bad Project Managers

Project Managers- The good ones are amazing, things just work and it seems like they aren’t doing anything at all. Good PMs will make life as a developer much easier, while the bad ones will suck the life right out of you and leave you a husk. Less if they can get away with it. So far in my career, I've come across many horrible PM's, and a few good ones. The good ones all seem to do almost nothing, but are always busy in the back ground. Organizing, directing/getting direction, and more or less getting a feel for the situation so they can facilitate getting the job done as efficiently as possible. With good PM's, things really do just work out. Not really being a PM, or wanting to be a PM- I have absolutely no idea why, or how they do their job.

This isn't about good PMs. This is about bad ones, horrible ones, the kind of PM that makes you want to rage and Sparta kick them right out of your cubicle, office, and life. They seem to fall into a number of categories but really it seems to be just a mixed set of base characteristics that combine to make these types of managers. I would draw a graph, but I don't really know how to draw in more than maybe three dimensions. Instead I decided to list the ones that really stood out.

"I'm right because I can fire you."

This phase has been uttered before. The PM in question was the owner of the company, and also a developer that put a little too much faith in degrees, and almost no faith in clean code. He cared about results, resulting in decisions like "Let's have the customer write their own SQL Queries!", "We don't need to encrypt passwords!", and "Security? Our customers barely know how to use computers. We don't need to worry about protecting their SSN's.” The main goal was simply to spew out features as quickly as possible, having users connect directly to the DB (instead of a web service), and ignoring any semblance of clean, logical code. He cared far too much about "Results" and couldn't have cared less about his client’s security, or the consequences of his actions where future development was concerned. There was only "Now". On Quitting, his response was "I think you will find that this place really isn't as bad as you think it is."
Yes. Yes it really was as bad as I thought it was. Worse even, I'm sure. Accessing a variable than is 6-7 layers deep is at most a rarity, not a rule to live by. Panel1.PanelA.SubPanel.RightPanel.Component.ComponentsVarible isn't just a code smell; it's the gift your sick dog left you.

The only solution I can find to deal a PM like this (Who happens to be the owner and the lead developer) is to find work somewhere else.

Seagull Manager

I've come across these types twice. Chances are, you will notice them in little spurts. "They show up, wave their arms screaming that they are a PM, then runs away." is one of the best descriptions I have come up of these types. If you find a manager like this- bring an umbrella. They will eventually follow up the screaming with shitting everywhere. They don't care about what is actually happening on the project. There is no such thing as working to find a solution. Suddenly meetings stop being times to bring people up to date and find solutions to problems, but instead times to hold people "accountable".

I find that they only care about "Estimates". Can't make an accurate estimate? Too bad. They still need the estimate, and if it isn't accurate- then you obviously aren't a professional developer. "Just throw a number out there; it doesn't have to be accurate." - This statement is a trap, save yourself and don’t fall for it.

Don't fall for this, if pressed- give them a distant date. think 6 months to a year. Over estimate, and reply in email. Problems? Email. Email them everything; they will throw you under the bus as quickly as possible. Email should help alleviate this problem. In fact, while you are emailing, do your best to find someone else to work with. In my experience, they will not trust you. They know exactly how everything should work, if you don't fit into their world view, you aren't a professional developer, and should be working overtime to make it so. Don't do this. 40 hours a week should be a rule, only to maybe be broken occasionally if absolutely necessary. Rule of thumb- if you have to work more than 40 hours, chances are PM's failed somewhere. Bad PM's will take that to mean that the developer failed somewhere and must atone for their sins.

Director of F5

This PM was special. They weren't a horrible person- quite pleasant outside of work actually. The just didn't care, or understand what they were doing. They care about sticking to the process, in this case- the process was to stick to submitting bugs, and that all bugs should have exactly one developer allocated. They would sit at their PC and repeatedly hit "F5", waiting for a new bug to come in. Process was king, so you shouldn't be doing anything outside of the process. In this case, that meant doing absolutely nothing. Things were compounded by the fact that the majority of bugs were pushed off to one developer while others were simply left to do nothing.

I have no good solution to this other than to work around them. Bugs should be tracked, and developers should be allocated correctly. Common sense should be applied instead of blindly following process. Sometimes bugs take more than one developer to fix. Whatever the reason, the only working solution I have come up with is to simply work around the director, make your own teams and break things out in a reasonable manner.


Know it all

I don't run into this often. When I do, it becomes slowly infuriating. At first, it is nice because you have someone offering suggestions. After a while, you realize that those suggestions aren't really suggestions. They are commands. These commands are not to be questioned, as they have been doing this since before you were born, and to question the command is to insult them at the deepest level. They can be nice people outside of work, and generally easy to get along with- but it is very difficult to work with them. In my experience- the issues would come with the fact that small, incorrect requirements would be given. Where business requirements would have been "Move file to this place over here" they turn into "Use this protocol to move this file to this folder." when using that protocol really does not make much sense. Since they know everything about everything, they will know exactly how a developers machine should be. "A developers machine should be exactly the same as the target system. Why would they need more ram? That is just excessive". Other problems I have seen would be that all required documentation must be understandable by them. If a Tech Design Document is required, they must understand it. Fun fact- if the PM says "I can't do anything with this" in response to a tech design- the response of "You aren't supposed to do anything with this, it's for other developers" is not reply that generates good will with this sort of PM.

I am still trying to figure out an accurate solution that avoids office drama. It has been suggested to simply withhold information. Don't mention how you do anything, just what you are doing. This should prevent them from trying to dictate how you develop. Leave those details to lead developers, architects, and developer team members. In a perfect world, you shouldn't ever have to withhold any information. Unfortunately, this world is not perfect. Don't take this too far though! Other team members should absolutely know the technical direction taken.

Not all of these PM's are bad people. Some, but not all, are. It is still infuriating to work with them. They can suck out they enjoyment of development, and really drive down the quality of work done, especially when they try to micromanage and dictate how you do your job, or push you to put in more work than reasonable. Often times, they either don't care, or they care too much. Many times, they simply don't trust developers. They will hold processes such as Waterfall as the perfect process. Estimates should be perfectly accurate, and setbacks don't exist, if they do, it's because the developer is lazy, or horrible, or unprofessional.

Bad PM's suck.

Monday, March 31, 2014

On Linux

Linux- The choice OS for Real Programmers(tm) everywhere. I've seen many people comment on how Linux is a much better choice for developers than Windows, and in a few cases- even the suggestion that you aren't a real programmer if you don't know Linux. Why is this? I've seen a few different reasons why, ranging from it simply being easier, to Microsoft being a horrible evil corporation.  I decided to take on a project and give Linux a try for a week to see if I couldn't make the decision myself and find out why Linux seems to be the choice OS for developers everywhere.

In looking up Linux flavors, I found a few that looked interesting or I had previously used for a short amount of time before. Centos, Ubuntu, and Mint were the top three choices I came to, and ultimately decided on Mint after remembering an interview with a Linux admin where someone asked them about mint and their reply was something about "Oh, You mean Linux for people who don't know Linux".  It seems like as good of a starting place as any. It has a clean UI which doesn’t leave me feeling stuck in 1995, is surprisingly light weight in terms of CPU and Ram use, and has a lot of support. Mint it is!

Experiences with Mint 16


I am going to break this up into sections to try to prevent incoherent rambling. I am working with Mint 16 cinnamon.

Install:

This was really easy. I used a Live DVD to install, but you can also use a thumb drive. The only thing I would suggest is to pay attention to when it asks you how you want to partition your drive. I accepted the default partition on my 60 gig SSD, and it split it into 2 30 gig partitions. I shouldn’t have done that, and as of writing this, am trying to figure out if I need to reinstall Mint and partition it correctly, or if I should try finding a utility to merge the two partitions. This would actually be an easier mistake to correct in windows, but it isn’t like I have all my settings “just so” and couldn’t make everything work again. So, don’t be a lazy person like me and maybe pay attention a bit to the install.

UI:

UI for Mint 16 is really clean. It feels like what Windows 8 should have gone for. Easy to understand, and it uses icons that really help direct the user to know what the heck it is they are doing. It has a built in “run” bar like what windows 7 did, and overall really doesn’t feel foreign at all. This doesn’t really effect much in the way of development, but it is nice when the UI looks clean.

Media:

This is where I had issues, and I think Linux, or at least Mint, as a whole will have issues. It seems that Linux assumes nothing. I am running NVidia GTX 570 as a video card, and have a monitor with speakers connected via HDMI. I also have headphones so I don’t disturb my girlfriend when watching shows, or listening to music.  Both of which I find to be fairly important when I am developing because I need a slight distraction to either reset, block out background noise, or get me in the right frame of mind. If you have Headphones and a standard audio jack, the audio might just work right out of the box, but for me and my HDMI connection with the video card- it did not. It took a bit of googling and searching to find out which version of the driver to use. Searching on the package manager got me many different options to choose from, that may have been correct or not. It was not nearly as easy as windows to find out what I was supposed to do to make my graphics card work. I also had issues with making my monitor be the default sound output. In windows, it has some set of defaults that usually output directly to the speakers you want it to with not as much fuss. Neither of these were particularly difficult, but they were time consuming.

Linux itself really isn't the issue here. It's mostly NVidia, as they have apparently been not so great at the linux support. Linus Torvalds sums up his experience and love for NVidia here.

Development:

This. This is where Mint really went from “eh” to “Wow.” I love developing on Mint so far. I am currently working on making my own blog website (Feel free to visit the prototype here – but it still coming together and will not really have any functionality for a while yet.) and felt like this would be the perfect way to test out Mint and see what developing in a Linux environment really was like. It has been surprisingly easy. Currently, I am developing a Node.JS/Mongo/Angular.js SPA page to display my blog. For an IDE, I am using Web Storm, but I also had to pull in apache to run through some Angular.js tutorials. On Windows- this would have actually been a pain in the ass. I’ve messed around a bit with apache, installing node, grabbing random libraries. All of them can be overwhelming if you are trying to start out, and frustrating even if you know what you are doing. On Mint- it was as simple as “sudo apt-get install XXXX”. It’s like NPM, or NuGet- but for your OS. Apache, Mongo, and Node all installed very easily. I didn’t have to track down which version to use, or do something special that was hard to look up to start a service. This is where Mint really Just works. I believe most versions of linux have some form of Package Manager. Ubuntu, which Mint is based off of, uses the same “Apt-get” command to install packages, while Centos and Rehat both use YUM package manager. The only thing I had to do differently was I had to go out to download Web Storm and install by calling a shell script that IntelliJ provided with the download. In some cases, you may need to run a command to include some other libraries repository as well- but usually they will give you the command that you need to run to add that packages repo to your existing repositories so that “apt-get install” will work for them as well.

Performance:

I would not have ever thought to list “Performance” as something to talk about with an OS. I always thought of it as a cost, and either the OS works and was responsive, or didn’t work and really wasn’t worth the time. Well- here I am, commenting on Mint’s performance. It is very solid- very responsive, and most of all- Mint takes very little in the way of resources. I’m used to the OS requiring 4 gigs of ram to operate, and needing at least 16 gigs to do any decent development. Mint actually doesn’t use near as much! My home machine has 16 gigs of ram. I ran 64 bit Mint 16 and have not yet made it use more than 4 gigs of ram total. At one point in time, I counted 3 different Web Storm IDE’s open, 22 different Chromium Tabs (Some of which included flash video for Crunchy Roll or You Tube), MongoDB, Apache, a Java MongoDb UI, and Spotify. If ram is an issue, or you intend to run multiple VMs- Use mint, or even Mint XFCE.

Summary:

Over all- I highly recommend Linux, and particularly Mint. I love how easy it is to get dependencies, how clean the UI is, and how much support is out there. For all of the issues I have run into so far- the solution was a google or two away. I will be running Mint on my home machine, and will eventually convert my work machine to use it as well. The only hang up I have right now is the fact that I have a windows phone, and want to do windows phone development.  The reason that this is a hang up is because the windows phone emulator requires Hyper V. Unfortunately; this gets used from running the windows VM. To my knowledge, this pretty much requires that windows be run directly on the hardware instead of a VM. Once I get an android phone, I will almost certainly dump windows as my primary work OS and make the jump to Mint. Give Linux a try- boot up a live disk, or install it on a spare hard drive! I think it would be well worth while to learn about, and should even be fairly enjoyable for trying new languages and libraries.

I would like to thank Mathew Conley for reviewing this and making sure I didn't make a complete ass out of myself in my attempt to work with and test out Linux for development. If you haven't had a chance, check out his blog at SimonTek

Wednesday, March 19, 2014

Angular Js- Nnnnngggg!

Angular! It has almost everything you could ever need and/or want. As a developer, I actually really enjoy the framework. It's a package that gives you templating, data binding, an MVC frame work with built in Inversion of Control, Animation, and more! For this post, I will be going over my general experience with it as a frame work.

Inversion Of Control-

Angular is built around the Inversion of Control principle. You declare your dependencies, and they get handed to you through arguments. This is very useful when Unit Testing, and something I found really nice. I am still playing around with Angular, so I haven't actually gotten to Unit testing just yet- but I can see how it would be easy to write tests against anything using the framework because of the built in Inversion of control.

Inversion of Control is implemented when you declare your controllers, Modules, and pretty much anything else you have to declare with the Angular framework. Using the seed app as the example (link here:AngularSeed Github, file here: App.js)
angular.module('myApp',[  'ngRoute', 
    'myApp.filters',
    'myApp.services',
    'myApp.directives',
    'myApp.controllers'])
  .config(['$routeProvider',
    function($routeProvider){  
      $routeProvider.when('/view1', {templateUrl: 'partials/partial1.html', controller: 'MyCtrl1'});
      $routeProvider.when('/view2', {templateUrl: 'partials/partial2.html', controller: 'MyCtrl2'});
      $routeProvider.otherwise({redirectTo: '/view1'});
}]);
The dependencies are declares in the array, where the functionality, if declared (Note Module doesn't seem to declare any functionality, but config where you configure the routes for your application does) is declared at the end of the array defining the dependencies as a function that takes a variable with the same name as the dependency that you declared. config declares '$routeProvider' as its dependency, then the function declares an argument called $routeProvider(This is more naming convention then anything. you could call the first argument Foo, and you would get the routeProvider variable, but that would be very confusing.)
The same is done for controllers, and filters. This is a common pattern, and is meant to lend to Unit Testability. If you run through Angular's tutorials, they include sections on how to create unit tests as they introduce the framework. (Tutorial here)

Directives and Routes-

Angular interacts with HTML through the use of Directives, and Routes. You declare your main view through the use of ngView which is then controlled through the routes declared when you declare your module (through angular.module(appName, appDependencies).confige(['$routeProvider', functionThatProvidesRoutes)). Angular will pick up the location changes through the location dependency, or just pick up the normal route on page load. example being, if you make a link to MyPage.com/#/Penguin3OfDo0m, your page would still work and not force the user to have to navigate through your SPA page to get to Penguin3OfDo0m. You have access to other directives, all of which seem to behaive similarly to any standard templating engine. I like this, because you can break out your views into many smaller views with the use of other directives like ngInclude, and provide specific models, or controllers, so you can have sub pages with common controllers. In my prototyping, I have found that you can either pair an included page with a controller ( <div ng-include="'PartialPage.html'" ng-controller="someController" />) or you could just include the controller inside the page itself. Worth noting- you have a different scope inside ng-include, or any tag that you define a controller for.

{{Data.Binding}}

I am a huge fan of angulars databinding. You can specify one way data binding, or two way data binding. One way databinding is done by simply inserting the variable wrapped by 2 curly braces directly into the html {{myVarThatIsInScope}}. Two way databinding is done by assigning the model of the html tag. Example would be <input type="text" ng-model="myVarThatIsInScope" />. When ever the input is edited, the model that is declared in ng-model will be updated as well, making it much easier to put in forms, put in text, and pretty much do just about anything. For a template- it's not bad at all.


FuckNG hell

I love what angular offers. Coming from the world of ASP.Net, MVC, and Classic ASP- most of this is pretty natural to me, and really easy to implement. Setting up Routes, Controllers, Unit Tests, and all that jazz- super easy. Nothing that can't be learned in a day or two of tinkering with the Angular tutorials and just dinking around on your own page. Unfortunately, in working in this- I did run into one problem that does not seem like a problem at all to me, but will be to others- Angular likes to get all up in your HTML. I'm in the middle of coding up a blog page, and decided I'd bring in someone to show them the ropes and help teach them how to program web pages. They are currently taking an HTML class, and understand HTML fairly well, but don't know anything of Angular, or Javascript really. I show them the page thinking "This will be super easy".. I go to show them the page, and I get "What the fuck is this??" Ah... Yes... About that. 

Angular is really nice- but in its pursuit of awesomeness and the Kitchen sink- HTML stopped being the HTML that I know and love. I'm used to programming, so really this doesn't bother me at all. Coming from the perspective of a designer with no Javascript skills, or a new developer trying to learn coding- A full featured Angular JS page will look more like a foreign script and less like HTML. Some of that is unavoidable if you want to make a SPA and not have every single page declared statically on your HTML page (So, basically- if you want to have a SPA at all.). I still love Angular! But, I will be recoding the new blog testing other frameworks like Backbone, or Ember, to see if I can't alleviate the foreign script HTML problem. 

Summary

Angular is a great framework. Fairly easy to understand if you know coding, easy to get into, and helps to really cut down on boilerplate code that everyone has to implement. In doing this, your HTML will look less HTML-ish, and more Angular-ish. This could cause issues if you ever try to migrate from Angular, or don't understand what Angular does, and where HTML stops and Angular starts. Because of this, it can be overwhelming, and may not be the best choice for your project, or it may be the best choice ever. YMMV

Wednesday, March 5, 2014

Prototypes and Clean Code

Starting on a new project can be difficult. I find that when I start on one, I wander about. If I'm uncertain about the coding style I am taking, the business rules I am implementing, or the technologies I am using, things are even more difficult. I still love creating new code and aiming for that one style that just makes the code base transform from tedious code to that almost perfect state where code appears to be an effortless story that even a third grader could read and understand.

That perfect code will never happen. Not the first time. Many times I have created code with one thing in mind only to discover later on that one thing or another will not work. Ideas change as you put them to the test, code will break in unexpected ways, and all of this will be compounded if you don't understand everything about the project before you start. Solution: Prototype the code. Write the code and make it work. Break it, make it work again. Once you have it working, throw it away. Start again, and do it all over again, but now with all those things that you swear you should have done differently. I would almost argue that you need to rewrite the code base at least once for every unknown that is an unknown on a project wide scale. Don't understand the business Logic? Prototype it and test it with what you do know. Don't understand some new coding style or pattern- Prototype it using what you know, test it out. Use some of the business logic you had from before to see how it applies, or if it applies. New language or library? Rewrite it again.

All of this seems like an absurd amount of work? It is. It really is. If you can get someone to help you who understand, do it! If you don't have someone who understand- you will most likely put the time into rewriting the codebase again at some point in the future anyways, if you don't you will still put in the effort to maintain that code, which could well be more than the time it would have taken to rewrite it in the first place.

Code is a tricky thing. You tell the computer to do something, and the computer does exactly that. If you don't entirely understand what you are telling the computer to do, then you can't be sure that the results you get are the ones that you are supposed to get. 

Sunday, March 2, 2014

Lessons, Linux, and Augmented Reality


This blog post was originally about linux, but then I got interested in augmented reality, and blogging as well.  So, instead of writing only about linux, I will write about a bit of everything that currently has my attention. I will most likely write many blog posts like this, and as time goes on- I will also hopefully learn to refine them.
Topics: Lessons from tutorial post, Linux Experience, Augmented Reality

Tutorial Lessons

I will start with the lessons from my last post. It was my first attempt at a tutorial, and after posting it, I have a few ideas on how to better format a tutorial so others can follow along.

First lesson learned: Wall of text, bad! In the future, I think I will break up tutorials into well labeled sections. This tutorial was more of a mash up where it was not clear about when to read, and when to try. I feel that the quality and legibility of the tutorial would have been greatly improved if I had broken it up into sections explaining what is happening, then a section telling the reader "Do this."

Second Lesson: Read over the tutorial many times. I had issues with consistency on different aspects, which could lead to confusion. If someone had been trying to follow along on linux, they would have run into an issue with calling node because I jumped between telling the user to call "node blahblah.js" and "Node blahblah.js". I also have an issue later on where I jump between folder names. Multiple read throughs might have helped.

Third Lesson: Trolls. Trolls exist. Posting on the internet is putting yourself out there. People will read what you write, and they will judge. "Oh, if you can't do X, you shouldn't be programming at all!", or "Lol, you suck n00b". Ignore these people. I should have put a disclaimer, and will put a disclaimer in future tutorials. People have to start somewhere. Ignore the trolls and start, fail, and try again. The wonderful thing about programming is that you can always refactor or try again. A failure is meaningless if you succeed in the end. No one cares that you forgot a semi-colon on line 32. No one cares that you couldn't start a node server, or compile Boost, or get the console to say "Hello World" when you started. They care about what you can do, and what you have succeeded at. "But, I failed!" you say. We did too. "It's not rocket science, but I still can't figure this out." you say- we don't care. Try again, use a different tutorial, ask someone else. "Shit, I can't remember how to declare a class/method/function/where loop/for loop/if statement/ variable/etc." We were there. People forget shit, then have to google for basic things. I was there, my girlfriend is there, my friends have been there. It's all part of the learning process. Easy for one person doesn't mean easy for another. It's all part of learning, do not feel bad about it, and ignore trolls.

Fourth Lesson: Put yourself out there. Seriously, ask the dumb questions. Be willing to say something that is wrong. Don't be afraid of looking like an idiot. It's scary, but fuck it. You are writing, you are documenting what you know and learning from it. If you are wrong, people will tell you. Be willing to be wrong, be willing to learn. I find that success is built off of failure.

Linux Experience

So, this week I looked into moving over to linux. I decided to make the choice between Ubuntu, and Mint. Having messed around with Ubuntu before, I decided to give Mint 16 XFCE a try on a VM. Overall- my experiences were positive. I really enjoyed the clean UI that mint offers, combined with the familiarity of Ubuntu. If I were not attempting to develop for Windows Phone, I absolutely would go with Mint as my primary os for my Development machine.

I looked into porting over to linux to buy me some portability and control over my work enviornment, and also because it seemed like a fun thing to do. Linux itself comes off as friendly to developers, and it is very light weight. Ram requirements for XFCE are down to 384 MB with a suggested amount of 1GB. Windows suggests 1GB but seems to actually require 4 to run smoothly. I am still planning to make a Linux development machine, but it will be some time before I make it my primary OS.

Augmented Reality

Now on to the reason why I created this blog in the first place. I'm moving onto attempting to develop an application that helps route data to sensors that declare an interest in that specific type of data. I've attempted to work on AR stuff before, but got too caught up in new and shiney hardware. This time, I will focus on creating the core software and try to either get or make the hardware once I have something to work with. My current plan is to break apart the ability to sense and process information into services, with the ability to tell some central system the service type you are interested in. In doing that, I can create a small network of hardware that communicates through these central systems. My current target is to make the core library of communication, and use a cell phone and laptop to communicate with each other. The main computer should have enough processing power to handle heavier applications, or storing and processing information- while the cell phone can handle display, and serving up sensor data.

That sums up my blog for the week. I guess this is closer to a journal then a blog at the moment, but I'm still working on figuring out what information to post, and how often to post this. Thank you for reading!

Sunday, February 23, 2014

Node.js! How does this thing work again? Starting with Node.js

I've heard many things about Node.js. Either about how awesome it is by people who are using it, or people cursing it as they try to get started and can't figure out how to get Node to run.  This post may ramble a bit, but it will hopefully cover the basics to getting a Node server up and running. If you are averse to the rambling style, skip to the bottom of the post. I'll post a TL:DR recap of bullet points on how to get the server up and running at the bottom. 

Seriously though, how do you get this thing to run? This will be the first post in a possible series of posts documenting how to get started with Node.Js. I will go through How to start from scratch, then cover a few different IDE's and how to use them in the never ending quest to learn, code, and play.

If you want to follow along and look at the working code for this, the git repository is here:
https://bitbucket.org/ProgrammerWithoutaName/nodehelloworld.git

Starting Materials:
- Computer (I'm using Windows 7)
- Web Connection

First things first- we need something to write the JavaScript and HTML in. You could use notepad, but why? I don't hate myself that much. For this post I will keep the outside tools to a minimum. I don't really suggest running without an IDE, as intellisense rocks and all that, but I want to focus on getting the server started up and running instead of the code itself. If you are looking for a text editor, I suggest Notepad ++, it has syntax highlighting, and allows for plugins. 

Now that we have something to write with, we should probably get the server to run the code on. We have many choices for Node. So many choices, I couldn't even begin to figure out where.. to.. start.. Oh, wait. There is only one Node. 
  • Download the latest version of Node from here: Node.js



So, now what? Oh, I see this console thingy. (Node.js Console) I can open it and write JavaScript that seems to work inside. Typing random stuff seems to return errors, blarg!  What do I do? Why don't you work!



But wait! There is a way to make it work. I've tried this a few times, and the Node console tricks me almost every time. If you are a windows user, don't use it. From what I can find, it is simply a JS console. There is another way.

Command Line!
Open up windows command line. On installing Node, your command line environment was given a few new commands.  Command line keyword of the day: Node

So, you want to do "Hello World", but from a file. Easy!! Make the JavaScript file called "HelloWorld.js", with the text console.log("Hello World");

Navigate to the folder in the command like (If you have multiple hard drives and the source is not in C, start off by typing the drive letter with the colon (Example: Swap to drive 'D'- 'D:') From there, you can change directory to where your source is. (Command 'cd', Also- Tab is your friend. give the folder a letter or two then hit tab- this will give you the folder name so you don't have to type out "SuperLongFolderNameThatMadeSenseAtTheTime"

Now that you are in the folder, simply type "node HelloWorld.js" and you should get "Hello World"

Didn't get that? 
Either there is something wrong with your code (Syntax Error)- in which case it will output where it ran into the error:


OR
You might not be in the right folder. (I did this.) It will complain that it cannot find module "HelloWorld.js" or whatever you named your helloWorld file. 


Awesome! Now we have Node running, running code, and running code from a file. Useless code that really doesn't do anything other than spout off a greeting, but hey, it's something, and a step in a generally correct direction. Chances are, we want to do more than spout off these useless greetings in the command prompt.

Next Step: Useless Greetings in the browser!

Now we want to put a useless Greeting in the browser. This is where we start seeing more of what Node can do. Usually, when developing with JavaScript in the browser, you include the script files using some sort of standard HTML Script tag. We don't have any stinking script tags here. Actually, I'm pretty sure we don't even have a browser- just the file. How do you pull in outside libraries?
Require. Pretty useful, you pull in outside Node libraries as Modules. Using require('packageNameHere') or require('javascriptFileNameHere.js') Node is pretty useful like this. As long as the JavaScript file is in the source directory (Same directory as the main entry point), or in your "Modules" folder in the source directory, "require" will pick up the file needed. 

For this post/Tutorial/badly worded instruction deal I won’t be going into how to build a module. But I am going to sum up how require works, and what you have to do with it. The function "require" returns a variable. It is NOT like the usual #include, you can't go including antigravity or importing some magic Java file builder. This is not some sort of precompile magic that gives you access to new classes. This is a standard function that is simply run. You could run this function dynamically and include based off of user input if you really wanted to. (I don't suggest this.)

Require returns a variable that you use. You use it almost as if it were a class. On the other side, the file or module will actually have code that is run that assigns functions and variable to "modules.export". modules.export is what require returns, and is what you will have access to. If you are trying to instantiate prototypes defined in by a module, you would still use require. Standard naming convention says to name the returned variable with an uppercase if it is meant to be instantiated, or a lower case if not.

Example:
Mongoose. Mongoose is a NoSQL libary-
var mongoose = require('mongoose');
mongoose.connect('mongodb://SomeMongooseServer');

Using mongoose libraries, but mongoose itself isn't meant to be instantiated. We are just gaining access to functions provided to modules.export, which is returned by require

var Beer = require('beer');
var beerImDrinking = new Beer('Arrogant Bastard');

beerImDrinking.drinkMore();

Note: Beer starts with an uppercase letter, and I instantiate it by saying new Beer(beerName). I then call drinkMore() on beerImDrinking, which is its own object that was created by calling new Beer.

Why is this relevant? Because! We need to use Node as a web server so we can announce our useless greeting to the world. To do this, we will use Express. Express gives us the ability to set up routes- and possibly much more. I'm still new to Node.js, so I'm not sure what else it does. However, I can give you the link to Express FAQ: Express FAQ

First thing's first. We need the express library exports:
var express = require('express');

Awesome! But that isn't all. We need to create the app and the app routing. 
// instantiate web app
var app = express();

// Set up routing. This will be to the basic directory
// this says that on get request to the base directory, we send the given response
app.get('/', function(request, response){
    //    When we get a get request to this address (root address) respond with this
    response.send("Greeting, I'm Alive! Ooo, shiny browser goodness.");
});

Prefect! Now when we get a request to base directory, we will respond with "Greeting, I'm Alive! Ooo, shiny browser goodness.". We still aren't done yet though. We need to tell app what port to listen to.

app.listen(process.env.PORT || 8080);

The end result will look like this:

var express = require('express');// instantiate web appvar app = express();// Set up routing. This will be to the basic directory// this says that on get request to the base directory, we send the given responseapp.get('/', function(request, response){    //    When we get a get request to this address (root address) respond with this    response.send("Greeting, I'm Alive! Ooo, shiny browser goodness.");});


app.listen(process.env.PORT || 8080);


Now we are cooking with something that cooks! So, lets go run this. Wait, what's this?
Crap. Error again, can't find this module "Express". What gives, Didn't that blogger dude say that Node handled modules and all you had to do was write "require(somethingOrTheOther)"??

This is because "Express" is not included in the modules folder. In fact, we don't even have a modules folder. Not yet, anyways. We need the "Express" module. Enter Node Package Manager! When Node in installed, Node Package Manager is as well. Now, instead of tediously going out to a million different websites (Which you can still do.), you can simply install modules using a common package manager. For .NET people, this is similar to NuGet. To my knowledge, there are two ways to install a package from Node Package Manager. Either you tell it to install a specific package, or you specify the dependency in a file in your source directory called "Package.json". I'm going to only show the "Package.json" method, as it is simply easier to do. I could give you a folder with HelloWorld.js, and Package.json- and you could simply tell NPM to install all the packages required. 
Also, I don't know how to install individual packages, but it would be a pain to hand off a list and force people to manually install. It's easier to hand the list to Node Package Manager, as it take care of the details for you.

Yo, you checking out my Package.json? Package.json is a file that contains the json that describes your package- in this case, your web application. All Node modules will have a package.json that does the same thing. There is a long list of items that it can contain. Things like repository location, version info, dependencies, licenses, authors, and more. Here, since this is a Hello World website, we will omit 
those and include the basics

Create a file called Package.json, and paste the following in:
{  "name": "UselessGreetingWebsite",  "version": "1.0.0",  "description": "Welcome to costco, I love you",  "dependencies": {    "express" : "3.4.x"  }}

Break down of the contents:
  • Name- Pretty obvious, this is the name of our website.
  • Version- versioning info. This is fairly important to include for packages, especially packages that are submitted to Node Package Manager (NPM from now on.)
  • Description- a nice little description of your website. 
  • Dependencies- the list of dependencies, and their versions that are required for the project. Here we specify "express", and "3.4.x" as the version. NPM will look here to find the list of dependencies to install. Once installed, require.js will be able to pick up express, as you will have a folder called "modules" and inside it will be all the dependencies you included.
We now have the package.json file. Now what? We install it! Back to the command line! Simply type "npm install" when you do, you will see a long list of output basically saying what npm is doing. it should look something like this



snip!


NPM Install Go! Packages are installed! Now time to make this puppy run. Now we can tell the server to run. Enter "node HelloWorld.js" and watch the magic:

Nothing Happens! That's right. It's a web server. Unless you tell Node to say something, it won’t. Your Node webserver should be running now. Go To http://localhost:8080 (Port we told it to listen to.)



Something! Simple something, but something! This is a great start. We now have a Node.JS web server running, and returning a useless greeting to a simple get request. Using Express, we can specify more and aim for a standard RESTful service, or/and have it serve up static html files. To set up Restful services, we would specify the routes in the related RESTful functions (.get, .post, .put, .delete I believe. Google is your friend.) And you have a resful service.
To serve static (Read "basic HTML") page, you tell app the route and use express to have it return the list of pages in a given directory. To do this:

app.use("/goHereStuff",express.static(__dirname + '/www'));

"/goHereStuff" will be the route.
You are passing in the directory of the web pages (__dirname is the directory name of the source being run, while '/www' is the name of the folder that the web pages are located in. You could put them in any folder, just be sure to match the folder name correctly. If they were in folder 'foo', you would have express.static(__dirname + '/foo')) 

So, you have a page called "HiThere.html", you have put it in the directory "www" in your source folder. You want to make this page, and any other static web page available in the web directory "/goHereStuff" so that when you went to http://localHost:8080/goHereStuff/HiThere.html, you would get your "HiThere.html" web page- you would simply call
                                     
app.use("/goHereStuff", express.static(__dirname+'/www'));
               

  • "/goHereStuff" is the web directory/route, so any time you go to localHost:8080/goHereStuff/ you would using what your are passing as the second argument to app.use
  • express.static is the utility method that you are using to say "Hey, look at this folder."
  • __dirname  The name of the directory that the currently executing script resides in.
  •  '/www' the folder. We are passing in the __dirname + '/folderLocation' for the place to pull up the static pages. This will allow the directory given ('/www') to hold many different static files so you don't have to specify each individual static html/js/css file, but instead group them by folders.

To test this out, create a new folder in the source directory called "www", inside that folder, create a file called "HiThere.html" and paste the following into it:

<!DOCTYPE html><html> <head>  <title> Umm, hi? </title> </head> <body>  <h1>Welcome to Costco.</h1>  I love you. </body></html>

Go to HelloWorld.js and add the line 
app.use("/goHereStuff",express.static(__dirname + '/www')); some time after you instantiate app, and before you call app.listen. It should look something like this:
var express = require('express');
// instantiate web app
var app = express();
// Set up routing. This will be to the basic directory
// this says that on get request to the base directory, we send the given response
app.get('/', function(request, response){
    //    When we get a get request to this address (root address) respond with this
    response.send("Greeting, I'm Alive! Ooo, shiny browser goodness.");
});
app.use("/goHereStuff",express.static(__dirname + '/www'));

app.listen(process.env.PORT || 8080);
save and go to command line again. If Node is still running from last time, you can hit ctrl+c to stop Node, then hit the up arrow to re run it. Otherwise navigate to the source directory and run 
node HelloWorld.js

if you go to http://localHost:8080, you will find you get the following:

But, if you go to http://localHost:8080/goHereStuff/HiThere.html, you should get this:

Wow! That was long! Congratulations! You now have a Node.JS web page and web server!

The TL;DR 
Git Repo: https://bitbucket.org/ProgrammerWithoutaName/nodehelloworld.git
  1. Get a Text Editor, like NotePad ++
  2. Get Node- Node.js
  3. Create Source Directory 
  4. Create Main JavaScript file (HelloWorld.js)
  5. Create Package.json file, include dependencies. (File format listed in post)
  6. Create Static Web Page directory
  7. Create Static Web Pages
  8. Require "Express"
  9. instantiate app with express
  10. tell app what routes to resolve using use, get, post,put,delete
  11. tell app what port to listen to
  12. Using windows command line, run "npm install" on source directory (should resolve dependencies listed in package.json)
  13. Using windows command line, run "node HelloWorld.js" (from correct directory.) this should start up web server.
  14. Go to http://localHost:8080 (assuming you told app to listen to port 8080).

Congratulations! You now have a working Node server.


Blog Start! Maybe.

This will be my second attempt at writing a blog. I am horrible at keeping up with stuff like this, so if anyone starts to read this- I apologize in advance.

My last attempt at blogging was me documenting the attempt of turning a pair of video glasses to a set of augmented reality goggles. I took that down, since I stopped in the middle of the project due to me apparently stepping on the connecter.

Lessons learned from that project-

  1. Be wary of proprietary cables and connecters (Damn you vuzix!)
  2. Maybe don't let connectors, or any particularly important part of any project sit on the ground for too long.
  3. Saftey Goggles. Seriously, These things are needed. Hot plastic making kissy kissy with your eyes isn't a great feeling. 



So, with my blog restarted, I figured I'd make a blog post to cover the scope of my second attempt at writing. I will attempt to label these posts correctly to label the difference between Coding Projects, Ranting Posts, and Home Projects that aren't really specifically to coding. If you have any requests for projects you want to see done- ask away! I love learning and attempting new things, and I will make my own attempts at documenting the process. If you see something wrong, post! Tell me that I'm wrong! Tell me -why- I'm wrong! If I'm wrong enough, I'll most likely make a post out of that as well!

Thank you for reading!