Those who are relatively new to JavaScript might have the impression that JavaScript has no variable types. After all, we declare everything using var and we can treat
1 | if(1 == "1") |
The same as
1 | if(1 == 1) |
or
1 | if("1" == "1") |
But the reality is that JavaScript includes a very rich typing system with some well-known, and some little know methods of detecting types and converting from one type to another.
If you’ve been working with JavaScript at all for any length of time, you should know by now some of the basic rules of when something is true or false. And yet, I still see code that messes this up. At the most simple level I see code that often looks like this:
Every week when I write, I try to think back on the past week and think, “What have I learned that might be useful to others.” Most weeks that is a pretty easy question to answer because I get most of my pleasure from learning new stuff. But this week was different.
When I sat down to write today, I couldn’t come up with a subject that couldn’t be covered with a sentence. More of a tweet than a blog post. It was so bad that I decided to go run the errands that are on my list and come back to it once I got home.
Evidently, that was a good move because I think I have something that will be genuinely useful. Although I will admit that if you’ve been working with AngularJS for very long at all, you may have already learned what I’m about to explain.
When I first wrote down the idea for this post, I was originally thinking about how we might use agile development practices in a work place that practices Water Fall or worse. But since then, I’ve expanded my thinking to include the concept of using agile everywhere, including where it “isn’t allowed.” Here’s what I’m talking about. What does your work environment look like? Many of the places I end up working either are using no formal process at all, or weakly attempt some form of Scrum or Water Fall. In fact, my current major gig has a “project manager” (I use the term loosely) that manages our project with MS Project. There is not even a formal issue tracking system. And this is at a very LARGE organization that SHOULD know better.
I heard this so frequently, I decided it is time to write about it.
(When writing web applications) Business rules always belong on the server.
One of the last conversations I had at the last place I was working was on this same issue. And, I had a similar reaction a couple of years ago when I was doing a Selenium testing presentation and mentioned that the organization I was currently working for put all of the code on the client side and that the only thing the server did was save the data.
Maybe you believe the same thing? Nothing is ever that cut and dry.
A couple of weeks ago, I posted 7 Reasons Every Programmer Needs to Learn JavaScript. In the comments, Dean tried to refute my arguments first by claiming that my sources for JavaScript’s popularity were “a problem” because JavaScript is used in combination with other languages. A point I refute in the comments. But then he goes on to claim that “JavaScript is poorly suited for client side applications” because JavaScript is “Single Threaded”. At this point, I just sighed and realized that Dean doesn’t want to learn JavaScript and that there MUST be some reason I’m not seeing for why he is so critical of JavaScript.
But then Brandon jumped in and offered a very clear defense of JavaScript on the server side. Nearly making this post unnecessary.
And yet, there are things that were not said, and most people will never see the great comments that Brandon supplied. And so we look at Multi-Threaded JavaScript in depth.
Last week I mentioned that it is possible to create a desktop application using JavaScript and that I had actually started working on an application that used Angular and Bootstrap for the presentation layer. I actually have enough of that working that I can share the “how-to” with you.
In my recent discussions with hiring managers about how hard it is to find good developers, the realization has slowly dawned on me that the programming language to learn today is JavaScript. This is particularly true if you are a web developer, but I would be inclined to just make a blanket statement. If you are a programmer, you should learn JavaScript.
I’ve been using the CefSharp.Offscreen library to drive the Chromium browser for a couple of months now. While the code I’ve been working on has been working correctly, I could never figure out why so many instances of Chromium are left dangling in my task manager. Oh, they’d all go away once I exited the application, but then it would take a very long time for my application to completely close because there were so many instances of Chromium hanging around.
This past week, I finally figured out how to keep the number of Chromium instances in line with the number of off-screen browser windows I was actually creating.
I’ve been looking at Angular.js recently. I’ve already got enough of a project done in MongoDB (with Mongoose), Express, Angular and Node.js (MEAN) to be comfortable with how Angular works. But I wanted to give it a try using ASP.NET as the back end. I’m always learning. Always improving.
To start out, I just setup an index.html page to hold my basic form as I got the basic look and feel going. But as I progressed, I wanted to make sure I progressed, I wanted to add in the capability of using Angular’s html5mode for the client side routing.