Open Side Menu Go to the Top
Register
Help a Hack Understand Front-end Development Help a Hack Understand Front-end Development

06-18-2013 , 01:14 PM
For you front-end development experts: How did you learn to do front-end development in a structured and efficient manner?

I'm currently doing full stack web development (for browser based apps only) part time and am looking to move on to full time work as a software developer. I created a thread asking for career advice about a year ago in this forum, and from that realized I needed to get more experience before moving on.

It's now been another year and I feel pretty good about my Java skills and feel pretty comfortable that I can answer the majority of technical Java questions that may be asked in an interview.

However, my front-end work feels hackish to me. I'm not sure if it's just me or if front-end development feels like that for everybody. By hackish I mean that there doesn't seem to be as many coding conventions, tools, IDE's, best practices, and documentation available as there is for a language like Java. I also struggle when reviewing sample JavaScript interview questions that I find posted online. (Going to dedicate my near-term goals to gaining a much better understanding of JS.)

Right now I do my front-end development with the Eclipse IDE (Spring Tool Suite plugin) primarily using Dojo, JavaScript, HTML, CSS, AJAX, JSP and JSON. I mostly leverage the AJAX capabilities built into Dojo, but did write a simple "homegrown" AJAX page just to learn how it works behind the curtains.

For testing and debugging I use the developer tools in Chrome which I'm pretty sure is a version of Firebug. We don't do unit testing or any other systematic testing.

So what is it like to work in a shop that does professional front-end development for web/mobile applications? What kind of tools are you using on the job? Do front-end developers have their own IDE's or do you use tools like Eclipse or Visual Studio? How do you go about making sure your code is maintainable and reuseable?
Help a Hack Understand Front-end Development Quote
06-18-2013 , 02:20 PM
The problem is you're treating FED as structured "programming" when its anything but (other than the core of how JS works).

In your shoes I'd just get started on learning jQuery. Just learn how to do functional stuff with it and more or less forget the DOM unless you're not going to be writing for IE8 and lower. One of the all time best ways to learn jQuery imo is jeffrey way's free video series on tutsplus.
Help a Hack Understand Front-end Development Quote
06-18-2013 , 03:20 PM
+1 to giving up the idea of structure. If you have to get your stuff to work on 4 different browsers (7 if you count 3 versions of IE), and tablets and mobile devices - that's about as messy an output environment as you can imagine.

The best way to mitigate that is look for packages that at least handle some of the low-level browser specific stuff you need to do. Anything where browsers act differently is where I always look for some kind of package in which someone else has always done the heavy lifting.

Same goes for mobile and tablet-specific stuff. Although those packages and frameworks are a lot less mature and still evolving like crazy.

You can use Eclipse with some JS plugins. But most purely front-end devs I know use Sublime Text or another Text Editor.

As far as maintainable and reusable it's the same as any other programming language - use inheritance where it makes sense, refactor early and often, DRY, loose-coupling, etc. There's no magic bullet. In a lot of ways you have to think on your feet more with JS since you *can* do stuff just about any way, but that doesn't mean you *should* do it that way. If you understand a lot of the patterns that Java and an MVC like Spring enforces, you can carry these in to JS.

I'd be happy to answer more specific questions or look at code examples/problems.
Help a Hack Understand Front-end Development Quote
06-18-2013 , 03:35 PM
Thanks guys.

It sounds like the unstructured environment (i.e. - what I was calling hackish) is just something I'll have to get used to.

I think Dojo does handle a lot of the browser specific stuff pretty well. However, once-in-a-while there will be an inconsistency or difference between browsers and then I feel a little lost trying to figure out how to troubleshoot it.

I also worry a bit that if I rely too heavily on just getting stuff done with a JS library that I might have trouble in an interview setting if they start poking away at my JS knowledge. I can figure out relatively quickly how to do almost anything but I sometimes cannot articulate it very well.

I think I will post some code soon. I don't have anybody at work reviewing my code, and as long as it works I don't have a clue how optimal it is. Thanks!
Help a Hack Understand Front-end Development Quote
06-18-2013 , 03:39 PM
It's definitely good to know the vanilla JS that the framework is doing under the covers. I would look in the source code for any of the Dojo functions you use and try to follow what it's actually doing.
Help a Hack Understand Front-end Development Quote
06-18-2013 , 04:49 PM
The reason people put out such crappy JavaScript is because they don't treat it like a real language. Write unit tests, abstract things into reusable components -- just like you would any other language.
Help a Hack Understand Front-end Development Quote
06-18-2013 , 07:43 PM
Ok here is a function I wrote as part of an application that helps the sample management group plan plate compressions in order to free up storage space in their freezers.

The basic gist is a plate can hold 96 samples but they have lots of plates with far less than 96 samples in them. These are source plates. They use a robot to move samples from source plates that are not full to new destination plates.

I wrote a little web application where they can load up the plates in a freezer from the database, and then drag and drop them onto a representation of the robot deck. Each time a plate is dragged or dropped it fires this function in order to update the dashboard. This visually helps them plan efficient compression's.

Also, the deck of the robot they usually use to perform the compression can normally hold a total of 20 plates. This is a combo of source and destination plates. It's most efficient if they can load a large number of source plates into a small number of destination plates with the total plates equaling as close to 20 as possible.

I'm not sure if this is a great example of my work but it was one of the easier pieces of code to pull out by itself where it would still make sense to someone looking at the code.

Code:
// This is the function to calculate the plates on deck as well as the number of 
// samples to fill the current destination plate
var updateDashboard = function(store) {
	var numSourcePlates;
	var numDestPlates;
	var totalPlates;
	var samCnt = 0;
	var toFill;

	store.fetch({onComplete: function(items, request){
		numSourcePlates = items.length;
		console.log("source plates on deck " + numSourcePlates);
		dojo.forEach(items,function(item,index){
		samCnt = samCnt + store.getValue(item, 'sampleCount');}			
		);
		console.log("samples on deck " + samCnt);
		if(samCnt == 0){
			numDestPlates = 0;
		}
		else if(samCnt < 96) {
			numDestPlates = 1;
			numDestPlates = numDestPlates + Math.floor(samCnt/96);					
		}
		else if(samCnt >= 96) {
			if(samCnt % 96 == 0) {
				numDestPlates = 0;
				numDestPlates = numDestPlates + Math.floor(samCnt/96);
		}
		else {
			numDestPlates = 1;
			numDestPlates = numDestPlates + Math.floor(samCnt/96);
		}
	}			
	console.log("destination plates on deck " + numDestPlates);
	totalPlates = numSourcePlates + numDestPlates;
	console.log("total plates on deck " + totalPlates);
		if(samCnt <= 96){
			toFill = 96 - samCnt;
		}
		else if(samCnt <= 192){
			toFill = 192 % samCnt;
		}
		else if(samCnt <= 288) {
			toFill = 288 % samCnt;
		}
		else if(samCnt <= 384) {
			toFill = 384 % samCnt;
		}
		else if(samCnt <= 480) {
			toFill = 480 % samCnt;
		}
		else if(samCnt <= 576) {
			toFill = 576 % samCnt;
		}
		else {
			toFill = "error";
		}
		console.log("sample remaining to fill current destination plate " + toFill);			
		dojo.html.set(dojo.byId("platesOnDeck"), "" + totalPlates + " (destination plates: " + numDestPlates + ", source plates: " + "" + numSourcePlates + ")");
		dojo.html.set(dojo.byId("samplesToFill"), "" + toFill);
		getPlateBarcodes(store);
	}}	);
};
Help a Hack Understand Front-end Development Quote
06-18-2013 , 07:53 PM
Here's a handful of tools/libs I use on a regular basis:

If you Google for any of these terms you will find their official site / github repos.

AngularJS
A client side framework based on the philosophy of having 2 way bindings with the least amount of code possible. Has the concept of web components which lets you write re-usable "directives".

Grunt
For automating tasks, similar to a Makefile but you write Javascript and there's thousands of plugins to do various tasks that are annoying.

Mocha
Testing framework. I like using "expect" with it.

Karma (Testacular)
A test runner so you can run your tests in multiple browsers in an automated way. Also lets you use Phantom JS for running headless tests.

Component
https://github.com/component/component
For packaging reusable components that adhere to a philosophy that a component should be as pure as possible and not depend on huge dependencies.

I feel pretty productive. I can scaffold out a new seed project with the latest dependencies with 1 command from my terminal and then from there I just install whatever components I need and build the app out as needed. I also never deal with manually refreshing a page (live reload), and develop in a split pane env. with code on the left, tests on the right and a terminal with karma's output showing.

There's also a number of useful Chrome apps to assist in general front end dev work.

Google for:

chrome eyedropper (pick colors out from anywhere on a page)
chrome ruul. Screen ruler (to get a ruler without using the inspector)
chrome window resizer (snap to popular resolutions so you can get an idea what it looks like on certain devices)
chrome batarang (if you decide to use Angular)
chrome jsonview (to view json in a more friendly way)
chrome postman (a rest client to test apis)

Last edited by Shoe Lace; 06-18-2013 at 08:01 PM.
Help a Hack Understand Front-end Development Quote
06-18-2013 , 08:12 PM
Your code sample looks pretty hacky to me but it's not so much a javascript issue.

You have a single function that's doing:

- Calls to a datastore
- Business logic (the calculations)
- Updating the DOM

Trying to test something like that would be a nightmare. I threw up a little in my mouth just looking at the source heh.

I would re-factor out your calculations into its own function(s). The calculations shouldn't even know the DOM exists or where the data is coming from. It should expect inputs and produce outputs. Then testing it will be super easy automatically.

Then I would use an event emitter or some other other observer-like functionality to update the DOM when the data changes. You want your data to be the single point of truth so you only have to update it in one place and everything that cares will adjust.
Help a Hack Understand Front-end Development Quote
06-18-2013 , 08:31 PM
8 space indent makes me stabby.

Also I think you have a bug, no closing bracket for: if(samCnt % 96 == 0) {

I fixed the indenting as best I could, guessing at some stuff, fixing some stuff and made a bunch of comments:

Code:
/* suzzer: no need to start with 'This is the function to', just say what it does */

// This is the function to calculate the plates on deck as well as the number of 
// samples to fill the current destination plate
var updateDashboard = function(store) {
  
  /* suzzer: you probably want to declare these vars inside your fetch function - unless there is some weird scoping or performance issue that isn't obvious from this code */
  var numSourcePlates;  
  var numDestPlates;
  var totalPlates;
  var samCnt = 0;
  var toFill;

  store.fetch({
    /* suzzer: is this something that happens after the store is fetched? If so all your logic should be inside this callback method */
    onComplete: function(items, request) {
      
      numSourcePlates = items.length;
      console.log("source plates on deck " + numSourcePlates);
      
      dojo.forEach(items, function(item, index) {
        samCnt = samCnt + store.getValue(item, 'sampleCount');}     
      );
      console.log("samples on deck " + samCnt);
      
      /*suzzer: I'd call this variable sampleCnt or sampleCount - you used big var names for the others, no reason not to use one here - for instant clarity's sake */
      if (samCnt == 0) {
        numDestPlates = 0;
      }
      else if (samCnt < 96) {
        /*suzzer: this whole block can be rewritten as numDestPlates = 1 + Math.floor(samCnt/96);  */
        numDestPlates = 1; /*suzzer: don't re-use existing variables for different purposes, very confusing - call this destPlateRemainder or something */
        numDestPlates = numDestPlates + Math.floor(samCnt/96);          
      }
      else if (samCnt >= 96) { /* suzzer - use else here, not else if - less code and makes it clearer that all bases are covered */
        /* suzzer: not sure what's going on here due to the missing }, either way this can be done much simpler */
        if (samCnt % 96 == 0) {
          numDestPlates = 0;
          numDestPlates = numDestPlates + Math.floor(samCnt/96);
        }
        else {
        /*suzzer: this whole block can be rewritten as numDestPlates = 1 + Math.floor(samCnt/96);  */
          numDestPlates = 1;
          numDestPlates = numDestPlates + Math.floor(samCnt/96);
        }
      }
      console.log("destination plates on deck " + numDestPlates);

      /*suzzer: I think you could write the whole if/else if/else block above as: */
      var destPlateRemainder = (samCnt % 96 == 0) ? 0 : 1;
      numDestPlates = destPlateRemainder + Math.floor(samCnt/96);          
      /* suzzer: you could do even do it all in one line, but I like naming the remainder variable to make reading the code clearer - there is always a balance between code clarity and code brevity */


      totalPlates = numSourcePlates + numDestPlates;
      console.log("total plates on deck " + totalPlates);
      
      /* suzzer: if I have one-liner if/elses I ususally don't add {} 
      also I would make a brief comment as to what this does  */
      if (samCnt <= 96)
        toFill = 96 - samCnt;
      else if (samCnt <= 192)
        toFill = 192 % samCnt;
      else if (samCnt <= 288) 
        toFill = 288 % samCnt;
      else if (samCnt <= 384) 
        toFill = 384 % samCnt;
      else if (samCnt <= 480) 
        toFill = 480 % samCnt;
      else if (samCnt <= 576) 
        toFill = 576 % samCnt;
      else 
        toFill = "error";
      
      /* suzzer: you could write the whole block above more succinctly as: */
      var toFill = "error";
      for (var i=1; i<=6; i++) {
        if (samCnt <= i*96)
          toFill = i*96 % samCnt;
      }

      console.log("sample remaining to fill current destination plate " + toFill);      

      dojo.html.set(dojo.byId("platesOnDeck"), "" + totalPlates + " (destination plates: " + numDestPlates + ", source plates: " + "" + numSourcePlates + ")");
      dojo.html.set(dojo.byId("samplesToFill"), "" + toFill);
      getPlateBarcodes(store);
    }     
  });
};
I try to write code so that if someone new has to maintain it (or me in a year when I've forgotten everything) they can do so with minimal head-scratching.

Edit: also what Shoe Lace said. But first lets tighten up the core logic, then look into separating out the different concerns.
Help a Hack Understand Front-end Development Quote
06-18-2013 , 08:59 PM
Quote:
Originally Posted by suzzer99
8 space indent makes me stabby.
Lolz. I actually cleaned it up with less indenting before posting it. Is there a standard formatting I should be using? I suppose this means I shouldn't be using tab but just spaces instead?


Quote:
Also I think you have a bug, no closing bracket for: if(samCnt % 96 == 0) {
When I was trying to remove some of the indenting so it would fit into the code box better I messed it up. The bracket is actually there but I confused what was going on by messing up when trying to fix the indentation.

What I have going on is another if and else inside the else if. Hopefully this makes it more clear.

Code:
else if(samCnt >= 96) {
  if(samCnt % 96 == 0) {
    numDestPlates = 0;
    numDestPlates = numDestPlates + Math.floor(samCnt/96); 
  }
  else {
    numDestPlates = 1;
    numDestPlates = numDestPlates + Math.floor(samCnt/96);
  }
}
I'm going to go through your other comments now. Thank you!
Help a Hack Understand Front-end Development Quote
06-18-2013 , 09:22 PM
Yeah that's what I guessed. Like I said though I thnk you can do that whole if/else block in a couple lines, one if you want to get fancy pants:

numDestPlates = ((samCnt % 96 == 0) ? 0 : 1) + Math.floor(samCnt/96);

I've always used 2 space indents, so I'm kind of partial. But if you look at the node/express source code they seem to be the same. So I'm hoping that's the industry standard now.

You can use tabs, but it's hard to keep spaces completely out. Different people have different tab stops - so the file might look lined up to you, but all FUBAR to someone else.
Help a Hack Understand Front-end Development Quote
06-18-2013 , 10:15 PM
Quote:
Originally Posted by suzzer99
Edit: also what Shoe Lace said. But first lets tighten up the core logic, then look into separating out the different concerns.
I like what Shoe Lace said too -- but agree I'll go through your comments first.


Quote:
/* suzzer: is this something that happens after the store is fetched? If so all your logic should be inside this callback method */
Yes, it's a callback because some of the data store implementations need to make a run to the server. So basically you call fetch() and when the fetch is complete it fires your callback function.

I'm confused by your comment though because I think all my logic is inside the callback function.

Code:
onComplete: function(items, request) {
// all the logic is between these curly braces
}

Quote:
/*suzzer: I'd call this variable sampleCnt or sampleCount - you used big var names for the others, no reason not to use one here - for instant clarity's sake */

/*suzzer: this whole block can be rewritten as numDestPlates = 1 + Math.floor(samCnt/96); */
These make sense, thanks.

I'm going to end this reply here and pick up in a new reply.
Help a Hack Understand Front-end Development Quote
06-18-2013 , 11:39 PM
Quote:
/*suzzer: don't re-use existing variables for different purposes, very confusing - call this destPlateRemainder or something */

/* suzzer: you could do even do it all in one line, but I like naming the remainder variable to make reading the code clearer - there is always a balance between code clarity and code brevity */
There is no remainder variable. I'm going through the if else conditionals in order to set the initial value of numDestPlates, but NumDestPlates is not actually a calculated remainder--it's just a starting value of zero or one depending on if there is a remainder (and/or if there are no samples at all.)

I'll explain below, but first I've made some changes based on your suggestions which will hopefully make the code more clear.

Code:
// there are no samples therefore there are no destination plates
if (sampleCount == 0) {
    numDestPlates = 0;
  }
/* there are some samples but less than the amount a full plate holds
therefore there is one destination plate */
else if (sampleCount < 96) {
    numDestPlates = 1;          
}
/* there are more samples than a full plate holds, we need
more information to determine the number of destination plates */ 
else (sampleCount >= 96) {
    /* If sampleCount divided by 96 has no remainder then
    numDestPlates is zero, otherwise it's one */
    numDestPlates = (sampleCount % 96 == 0) ? 0 : 1;
    /* Now we divide sampleCount by 96 and round downward
    then add that to the existing value of numDestPlates */
    numDestPlates += Math.floor(sampleCount/96);
}

So what they're trying to accomplish is to take source plates that are not full and put them into destination plates and fill the destination plates as much as possible.

The source plates and the destination plates both get loaded on the robotic deck. This entire "if else" block is calculating the number of destination plates currently on the deck based on the total samples in the source plates selected.

A destination plate holds a max of 96 samples, which is why you see the division by 96 as part of the calculation to determine how many destination plates will be on the robotic deck.

The first condition tests if total samples (these are coming from sample plates) equals zero. If that's the case, there are no destination plates on the deck.

The second condition tests if total samples is between 0 and 96 not inclusive. In this case there will be one destination plate since a destination plate can contain up to 96 samples.

The third condition tests if there are more than 96 samples. If there are, and we divide by 96 and get no remainder, then the result tells us exactly how many destination plates we have. For instance, if we have 288 samples we have exactly three destination plates. That is why when there is no remainder from the division by 96 we start numDestPlate at zero. Just doing the division by 96 tells us the answer.

If we had 300 samples we would have three full destination plates and a fourth destination plate containing 12 samples. That is why when we do the division by 96 and have a remainder we start numDestPlates at 1, then divide the total samples by 96 and round down, then add that to our numDestPlates value.

I did it this way so that I didn't need a "if else" condition for every multiple of 96 samples. Once the total samples goes over 96 the final else condition can calculate how many destination plates there are.

I hope that makes sense.

BTW - for the second condition (sampleCount < 96) for some stupid reason I was also doing the division by 96 and adding it to numDestPlates, which probably confused you. When the sample count is between 0 and 96 (not inclusive) there will always be one destination plate. (Rounding the division by 96 down always results in zero, so the logic still worked it was just extra code and confusing. Not sure how I never noticed it before!)

Edit: need to hit the sack. I have one more bit of confusion to ask about with your comments which I will get to tomorrow. Then I will also dig into Shoe Lace's suggestions.

Last edited by Jbrochu; 06-18-2013 at 11:51 PM.
Help a Hack Understand Front-end Development Quote
06-19-2013 , 02:37 PM
I'm on my purchasing duties today but I spent some time at lunch going over the rest of your comments.

Code:
/* suzzer: you could write the whole block above more succinctly as: */
var toFill = "error";
for (var i=1; i<=6; i++) {
  if (samCnt <= i*96)
    toFill = i*96 % samCnt;
}
Sweet, thanks. Awesome idea. I just added a break statement and fixed a little typo and it works great. The break statement is required because otherwise it will run through the if loop for every i starting from the first time through the if loop that the condition "samCnt <= i*96" is true.

Here it is tweaked a little.

Code:
/* Calculate samples required to fill
  current destination plate */ 
var toFill = "error";
for(var i=1; i<=6; i++) {
  if(sampleCount <= i*96) {
    toFill = i*96 - sampleCount;
    break;
  }
}
Help a Hack Understand Front-end Development Quote
06-19-2013 , 03:02 PM
Here is the completely refactored code. Definitely far fewer lines and hopefully more clear. I believe I covered all of your suggestions.

I'm going to review Shoe Lace's posts now.


Code:
/* Calculate the plates on deck as well as the number of 
samples to fill the current destination plate */
var updateDashboard = function(store) {

  store.fetch({onComplete: function(items, request){
		
    var numSourcePlates = items.length;
    var numDestPlates;
    var totalPlates;
    var sampleCount = 0;
    var toFill;
    
    // Calculate total number of samples
    dojo.forEach(items,function(item,index){
      sampleCount += store.getValue(item, 'sampleCount');}    
    );

    // Calculate the number of destination plates
    if(sampleCount == 0)
      numDestPlates = 0;
    else if(sampleCount < 96)
      numDestPlates = 1;					
    else if(sampleCount >= 96)
      numDestPlates = ((sampleCount % 96 == 0) ? 0 : 1) + Math.floor(sampleCount/96);      

    // Calculate total plates
    totalPlates = numSourcePlates + numDestPlates;

    /* Calculate samples required to fill
    current destination plate */ 
    var toFill = "error";
    for(var i=1; i<=6; i++) {
      if(sampleCount <= i*96) {
        toFill = i*96 - sampleCount;
    	break;
      }
    }
	
    // Update the DOM
    dojo.html.set(dojo.byId("platesOnDeck"), "" + totalPlates +
    	" (destination plates: " + numDestPlates + ", source plates: " + 
    	"" + numSourcePlates + ")");
    dojo.html.set(dojo.byId("samplesToFill"), "" + toFill);
    
    getPlateBarcodes(store);
    }});
};
Help a Hack Understand Front-end Development Quote
06-19-2013 , 03:23 PM
In general never use == in javascript use === instead. Also you can use switch statements in place of else if chains.
Help a Hack Understand Front-end Development Quote
06-19-2013 , 04:36 PM
Quote:
Originally Posted by Grue
In general never use == in javascript use === instead.
Thanks - just Googled it.

Quote:
Also you can use switch statements in place of else if chains.
I knew about switch statements but didn't think you could use them for conditionals. Again, thanks - it is possible.

Here is the code example I found if anyone is interested:

http://stackoverflow.com/a/4082548

Code:
var raw_value = 11.0;
switch(true)
{
    case (raw_value > 10.0):
      height = 48;
      width = 36;
      break;
    case (raw_value > 5.0):
      height = 40;
      width = 30;
      break;
    default:
      height = 16;
      width = 12;
      break;
}
Help a Hack Understand Front-end Development Quote
06-19-2013 , 06:13 PM
Couple things bother me right off the bat at a quick glance:

1)

Code:
var toFill = "error";
For starters you defined toFill twice and you have it first defined at the top of the function but it's not initialized to any value. That's not too bad, seems like an innocent mistake.

The problem I have is you're defining an error with a string, that's generally a bad practice in JS. If you want an error you should throw it.

If you don't think this is worthy of being an error then you could consider setting it to null as an easy way out. Then you could do something like:

Code:
if (!toFill) { console.log('toFill must be defined'); }
The ! is just the logical opposite of the expression. Read it like "if toFill is truthy"... but since we prepended ! it's actually "if toFill is NOT truthy", and the value null is not truthy. Be careful of that though because if toFill is 0 then the above code will result in the console.log message.

2)

In JS 0 is a "falsey" value. So lines like this:

Code:
if(sampleCount == 0)
Can be simplified to:
Code:
if(!sampleCount)
That would be more idiomatic javascript. I would also condense that if statement:

old:
Code:
    if(sampleCount == 0)
      numDestPlates = 0;
    else if(sampleCount < 96)
      numDestPlates = 1;					
    else if(sampleCount >= 96)
      numDestPlates = ((sampleCount % 96 == 0) ? 0 : 1) + Math.floor(sampleCount/96);
new:
Code:
    if (sampleCount > 0 && sampleCount < 96) {
      numDestPlates = 1;
    }
    else {
      numDestPlates = ((sampleCount % 96 == 0) ? 0 : 1) + Math.floor(sampleCount/96);
    }
You already have sampleCount set to 0 so you don't have to set it again. This really isn't simplified in the sense that you're doing less conditions, but it just reads more clearly IMO.

That is just a quick change though, ideally I would refactor that entire block into a function. Your comment says it calculates the number of destination plates so you already have a good name for it.

Last edited by Shoe Lace; 06-19-2013 at 06:20 PM.
Help a Hack Understand Front-end Development Quote
06-19-2013 , 08:03 PM
Quote:
Originally Posted by Shoe Lace
Couple things bother me right off the bat at a quick glance:

1)

Code:
var toFill = "error";
For starters you defined toFill twice and you have it first defined at the top of the function but it's not initialized to any value. That's not too bad, seems like an innocent mistake.
Yup, that was a mistake. My original code I only defined it once but then when I refactored I never noticed I was now defining it twice. Nice catch.

Quote:
The problem I have is you're defining an error with a string, that's generally a bad practice in JS. If you want an error you should throw it.
I agree.

When I wrote this code over a year ago I was just looking to end the if else statements somehow. In practice, it would be hugely unlikely based on the current procedure that they ever exceed 4 destination plates, so I went to 6 and called it good.

With the new block of code I could easily handle up to 20 destination plates by increasing the index in the controlling loop (i <=20) which would be physically impossible to exceed (deck only holds 20 plates total combined source and destination) and would absolutely never happen anyway because a destination plate is useless without source plates.

Quote:
The ! is just the logical opposite of the expression.
Ok - same as Java.

Quote:
2)

In JS 0 is a "falsey" value. So lines like this:

Code:
if(sampleCount == 0)
Can be simplified to:
Code:
if(!sampleCount)
That would be more idiomatic javascript. I would also condense that if statement:

old:
Code:
    if(sampleCount == 0)
      numDestPlates = 0;
    else if(sampleCount < 96)
      numDestPlates = 1;					
    else if(sampleCount >= 96)
      numDestPlates = ((sampleCount % 96 == 0) ? 0 : 1) + Math.floor(sampleCount/96);
new:
Code:
    if (sampleCount > 0 && sampleCount < 96) {
      numDestPlates = 1;
    }
    else {
      numDestPlates = ((sampleCount % 96 == 0) ? 0 : 1) + Math.floor(sampleCount/96);
    }
You already have sampleCount set to 0 so you don't have to set it again. This really isn't simplified in the sense that you're doing less conditions, but it just reads more clearly IMO.
Exellent - thanks!

Quote:
That is just a quick change though, ideally I would refactor that entire block into a function. Your comment says it calculates the number of destination plates so you already have a good name for it.
I'm plan on breaking some chunks of code out -- probably over the weekend. I'm on to other applications at work and never have time to refactor on the job.

Incidentally, the code where I send the strings to update the DOM was supposed to be temporary. My original design was to build a graphical representation of the robot deck and of the samples in the actual plates, and redraw it every time a plate is dragged or dropped. This would make the UI really intuitive for the users.

I used text just for testing, and since the application works and does what they need my boss had me move on to other pressing needs.

Thanks. I'll make some more changes and post again. I have some "bigger picture" kind of questions too, but I need to think about them a bit more and also review the links of tools you provided before I attempt to ask the questions.
Help a Hack Understand Front-end Development Quote
06-20-2013 , 09:53 PM
Quote:
Originally Posted by Shoe Lace
Here's a handful of tools/libs I use on a regular basis:

If you Google for any of these terms you will find their official site / github repos.

AngularJS
A client side framework based on the philosophy of having 2 way bindings with the least amount of code possible. Has the concept of web components which lets you write re-usable "directives".

Grunt
For automating tasks, similar to a Makefile but you write Javascript and there's thousands of plugins to do various tasks that are annoying.

Mocha
Testing framework. I like using "expect" with it.

Karma (Testacular)
A test runner so you can run your tests in multiple browsers in an automated way. Also lets you use Phantom JS for running headless tests.

Component
https://github.com/component/component
For packaging reusable components that adhere to a philosophy that a component should be as pure as possible and not depend on huge dependencies.

I feel pretty productive. I can scaffold out a new seed project with the latest dependencies with 1 command from my terminal and then from there I just install whatever components I need and build the app out as needed. I also never deal with manually refreshing a page (live reload), and develop in a split pane env. with code on the left, tests on the right and a terminal with karma's output showing.

There's also a number of useful Chrome apps to assist in general front end dev work.

Google for:

chrome eyedropper (pick colors out from anywhere on a page)
chrome ruul. Screen ruler (to get a ruler without using the inspector)
chrome window resizer (snap to popular resolutions so you can get an idea what it looks like on certain devices)
chrome batarang (if you decide to use Angular)
chrome jsonview (to view json in a more friendly way)
chrome postman (a rest client to test apis)

Thanks for this. I've poked around on some of the websites and they look pretty sweet, although some of it is fairly intimidating to me.

I decided to try and start with just a testing framework for now, and to start with something that integrates with my current development environment which is the Spring Tool Suite (Eclipse IDE).

For this reason I've picked JsTestDriver which has an Eclipse and Maven plug-in available. I've got it installed and running but for some strange reason I cannot find the hello-world test application referenced in the "getting started" document. I've sent an email to the author. Hopefully I'll get this figured out soon.

It's supposed to be here but I'll be damned if I can find it:

http://code.google.com/p/js-test-dri...es/hello-world

I'm also going to install a bunch of the Chrome apps you mentioned. Some of those look really cool.

I think for now just getting started with unit testing and refactoring / writing better JS code (and breaking the functions out into smaller testable units) per the earlier discussion itt will be a good start.

In addition I'm trying to spend an hour or so every day reviewing Java libraries and doing Java exercises in preparation for job interviews. I think my best bet to break into software development full time is with a Java position, and hopefully will find something at a place where I can grow into doing more front-end / mobile development as I get better at it.
Help a Hack Understand Front-end Development Quote
06-20-2013 , 11:00 PM
#1 the backend developer is always right
#2 if rule #1 does not apply rule #1 automatically applies

LOL just joking. But there might be some truth behind it. The backend developers usually are paid more and think they have a better qualification, that's why they are doing the backend development. In reality this is BS. But some social skills might be beneficial when dealing with them. Frequently if something is not working they will claim that they have tested it and you must be doing something wrong. Then it's up to you to show them that they are wrong in a diplomatic way without pissing them off too much. Usually my projects are a mix of frontend and backend development.

I have made some bad expiriences with that in a project some time ago when I did a C# front end. I had so many senseless discussions with a backend developer and he was ALWAYS wrong (like 5 of 5 times). I was really happy when that project was over. Another colleague of mine at that time, who was also front end dev, was really happy seeing that other front end devs have the same problem with that guy. He was frequently telling him about bugs for example, that he did not admit, so he had to build workarounds/hacks. Then at a later time the backend dev realized he was wrong and fixed the bug causing problems for the front end devs hacks that he built in the meantime. And what is really funny, they sat beside each other all the time, sharing the same desk!

The next project was a Adobe Flex frontend with a PHP/MySQL backend with a really nice backend developer/architect and two other developers. Initially I did just the frontend part replacing the original frontend developer who has left the company. Then I became lead dev moving over to work on the backend together until the architect/backend developer left the company as well.

So this really depends on the people and their social skills.

Happy hacking! :-]

PS: +1 to separating business logic from data layer and the visual layer is a good idea and +1 for unit testing. Most larger projects will have that separation already. if not it is something that will add value to the project depending on if they want that.

Last edited by AnotherMakiavelli; 06-20-2013 at 11:11 PM.
Help a Hack Understand Front-end Development Quote
06-21-2013 , 08:43 PM
Quote:
Originally Posted by AnotherMakiaveli
#1 the backend developer is always right
#2 if rule #1 does not apply rule #1 automatically applies
In my limited experience it does kind of seem like front-end developers are not as respected for some reason just based on remarks you hear. Sort of strange to me as I feel like a lot of backend stuff is fairly straightforward -- unless the developer also has to be a domain expert like a biologist or chemist or mathematician. (I've probably also been given more standard assignments so it doesn't feel very complicated.)

It seems like the front-end guys have to deal with all those issues with browsers not implementing standards properly, especially if you have to support older browsers. Plus all the rapid changes to keep up with, i.e. mobile, different libraries, etc.


Quote:
PS: +1 to separating business logic from data layer and the visual layer is a good idea and +1 for unit testing. Most larger projects will have that separation already. if not it is something that will add value to the project depending on if they want that.
I understand how to separate my web apps into layers (use MVC) when it comes to the Java code, but I'll have some questions sometime in the next few days about how to separate JS properly if you don't mind checking back itt.
Help a Hack Understand Front-end Development Quote
06-21-2013 , 08:54 PM
I've got the JsTestDriver plug-in for Eclipse up and running and I created a Spring MVC application and now have it working within that web application structure with a few simple tests.

Need to read some more about the list of assertions that come built in, but they seem fairly easy to understand and use.

Tomorrow I'm going to separate out the business logic from my earlier function into their own functions and see if I can figure out how to write test cases for them.

I'll probably post my test cases to see if I'm on the right track.
Help a Hack Understand Front-end Development Quote
06-21-2013 , 09:34 PM
Quote:
Originally Posted by Jbrochu
In my limited experience it does kind of seem like front-end developers are not as respected for some reason just based on remarks you hear. Sort of strange to me as I feel like a lot of backend stuff is fairly straightforward -- unless the developer also has to be a domain expert like a biologist or chemist or mathematician. (I've probably also been given more standard assignments so it doesn't feel very complicated.)

It seems like the front-end guys have to deal with all those issues with browsers not implementing standards properly, especially if you have to support older browsers. Plus all the rapid changes to keep up with, i.e. mobile, different libraries, etc.




I understand how to separate my web apps into layers (use MVC) when it comes to the Java code, but I'll have some questions sometime in the next few days about how to separate JS properly if you don't mind checking back itt.
Handling a complex backend is complicated but a frontend app can be equally complicated as well. You are right, there is some backends who do nothing but running a database query and then delivering the result....pretty much straight forward suff...always the same. Unfortunately there is some who do not realize that but anyways. There is many potential employers! At the end of the day the result counts (a working app).

Just had a rough 13h day doing front end stuff debugging some self made custom controls. A scrollable menu in multiple colors and another custom control displaying a list of rows with variable row height allowing to soft scroll them which is not implemented in standard Adobe Flex (it usually scrolls element wise which does not look too cool). All flicker free of cause. No backend dev could ever do that...hahaha

I'll check back the next days.....just opened a can of worms.....no beer i mean, and playing some poker

Last edited by AnotherMakiavelli; 06-21-2013 at 09:40 PM.
Help a Hack Understand Front-end Development Quote

      
m