Showing posts with label tools. Show all posts
Showing posts with label tools. Show all posts

Wednesday, 4 April 2012

Announcing Lineage

Note: As of late 2015, I don't use Lineage anymore, there's no need. I use the class features of ES2015 (aka "ES6") instead. If my target is a browser, for now I transpile with Babel (no need when working in NodeJS, the latest Node uses the latest V8 which has solid support for ES2015).

Just a brief post to announce my latest mini-project, Lineage. It's a small, simple toolkit for creating JavaScript constructor functions and their prototypes ("classes," if you will) in a straight-forward and concise way. From the project home page:

  • Lineage's API lets you define prototypes with a very concise syntax, while still encouraging you to create functions with real names (rather than anonymous functions); this helps your tools help you (debuggers show function names in call stacks, for example).
  • Lineage provides a highly efficient mechanism for "supercalls" (calling into the parent prototype's versions of methods from an instance using a derived prototype).
  • Lineage's API encourages and supports use of the module pattern for each constructor and its prototype.
  • Lineage is small, <3k compressed (gzips to <1,500 bytes, a quarter of which is the MIT license) — because it doesn't try to reinvent inheritance, it just simplifies access to the power of JavaScript's prototypical inheritance.

Here's an example of defining a constructor called Thing with a spiffy function on the prototype:

var Thing = Lineage.define(function(p) {
p.spiffy = function() {
console.log("I'm a spiffy thing!");
};
});

...or if like me you prefer your functions to have names:

var Thing = Lineage.define("Thing", function(p) {
p.spiffy = Thing_spiffy;
function Thing_spiffy() {
console.log("I'm a spiffy thing!");
}
});

Now, with such a trivial example, that doesn't offer you much on top of the raw equivalent:

var Thing = (function() {
function Thing() {
}
Thing.prototype.spiffy = Thing_spiffy;
function Thing_spiffy() {
console.log("I'm a spiffy thing!");
}
return Thing;
})();

...and that's the point, Lineage works with JavaScript's natural inheritance, it doesn't try to reinvent things. But when you get into inheritance, and in particular start making supercalls, Lineage reduces the code markedly while ensuring everything is hooked up properly, and does so in a way that's easy to use correctly, without retyping a lot of boilerplate code.

Rather than loading up this post with code examples, I'll point you to the progressive series of examples on the Lineage Comparison with Plain JavaScript page for more.

I'm using Lineage in projects now, and so far I'm really liking the simplicity of it. I hope you will too! If you do play with it, please send comments (positive and negative!), the feedback is very welcome.

Happy coding!

Saturday, 23 April 2011

Thinking outside the box with the ASP.Net Development Server

A well-known limitation of the ASP.Net Development Server is that it will only bind to the local interface of the development machine, never the LAN interface, and so you can't bring up pages served from the development server from anywhere but on the box itself via the localhost name or 127.0.0.1 address. And fair enough, it's meant to be a debugger aid, not a web server. But there are situations where you want to think outside that box, and fortunately, it's dead easy to do so.

I wanted to do that because I'm working on a project where the server-side code is C# assemblies and the client-side is pure HTML, CSS, and JavaScript (no server controls or other ASP.Net-isms). I wanted to use VS.Net for debugging server-side C# code, and Chrome's Dev Tools or Firebug for debugging the client-side code in the browser. VS.Net makes it remarkably easy to debug server-side code — just mark the "project" with the client code as the startup project, chooose a port if you want, set the virtual path, make sure the server-side assembly projects are in the solution, and hit F5 (or click Run). It fires up the ASP.Net Development Server and you have full debugging of the server-side code (and client-side code as well, if you like, with its integration with IE). Excellent, couldn't be much easier. But for me, this is all happening in a VM (this is for a client, and I keep all my client stuff isolated from my work and each other using VMs) but I'd like to do the client-side debugging with Chrome's Dev Tools on my main machine.

It was only a mild irritation (I can run a browser in the VM happily enough), so I didn't want to spend any time on it, but I figured this has to be one of the simplest examples of the need for port forwarding or proxy serving on the planet (just bridging interfaces), and so I did a quick web search and found this article about using Squid to do it. Now, Squid is a big hammer for this nail, but it's so easy to set up, that it's still reasonable to use it.

That article's good, but I thought a few things weren't as clear as they may have been, so here's my step-by-step:

  1. Tell the ASP.Net Development Server to use a particular port rather than picking one at random:
    1. Click the client code project in your solution
    2. Look at the properties
    3. Make sure that Use dynamic ports is False
    4. Choose your port under Port number (if you just turned off the Use dynamic ports option, you may have to click away from the properties and click back again to unlock the field; minor bug in VS.Net)
    I'll call that the "internal" port (the one that only works within the VM). In my case, I used 80; the VM doesn't serve any other web content.
  2. Be sure your dev machine's firewall allows incoming connections whatever external port you're going to use.
  3. Get and install Squid. The quick-and-easy thing is to get a binary from these nice people who are kind enough to maintain a Windows port built using the Microsoft toolchain: Just scroll down under the features list and click the "Squid download Page" link. Or, of course, you could grab the source and do it yourself (with the MS toolchain, or Cygwin and GCC). I grabbed 2.7.STABLE8 from the the nice people.
  4. Unzip it somewhere handy. The Windows binary assumes C:\Squid, so I went with the path of least resistance and put it there.
  5. Install it as a service:
    1. Open a command prompt (as Administrator, if you're on Windows 7 or similar)
    2. Change to C:\Squid\sbin.
    3. Type squid -i -n Squid
  6. Set up the default config: Using your favorite file browser:
    1. Go to C:\Squid\etc
    2. Copy squid.conf.default as squid.conf
    3. Copy mime.conf.default as mime.conf (we're not going to edit it, but it's required)
  7. Set up the proxying:
    1. Open squid.conf with your favorite text editor
    2. Go to the very end of the file
    3. Paste this in, replacing the bits in curly braces with your own values (without the curly braces) (mind the word-wrapping, Blogger is giving me a hard time yet again; best to copy and paste):
      http_port {EXTERNAL_PORT} accel defaultsite={EXTERNAL_IP_ADDRESS}
      cache_peer localhost parent {INTERNAL_PORT} 0 no-query originserver name=myAccel

      acl our_sites dstdomain {EXTERNAL_IP_ADDRESS}
      http_access allow our_sites
      cache_peer_access myAccel allow our_sites
      cache_peer_access myAccel deny all
      So in my case, since I want both the internal and external ports to be 80 and my VM's external (LAN) IP is 192.168.142.153, it's
      http_port 80 accel defaultsite=192.168.142.153
      cache_peer localhost parent 80 0 no-query originserver name=myAccel
      acl our_sites dstdomain 192.168.142.153
      http_access allow our_sites
      cache_peer_access myAccel allow our_sites
      cache_peer_access myAccel deny all
      ...but if you use different internal and external ports, be sure to set them according to the placeholders in the above.
    4. Save the file
  8. In your (Administrator) command window, tell Squid to validate the config:
    squid -z
    You should see the message Creating Swap Directories and pretty much nothing else.
  9. Start the service:
    net start Squid
  10. You might choose to have Squid start when you boot the machine, via the usual services.msc settings

Sorted!

Friday, 18 March 2011

No Excuse

I'm active in a couple of places where people go for help with, amongst other things, JavaScript code running in web browsers. Routinely, you'll get questions like this one where the person asking the question is having trouble visualizing what's happening on the client side, and is stabbing in the dark with alert or console.log to try to figure out what's going on. It's like the old days of debugging with printf. I see it over and over again.

Folks, maybe that was reasonable in, oh, 2002 or so, but here in 2011 if you're using a desktop browser there's just no excuse for not using a proper debugger to set breakpoints, walk through code, inspect variables, inspect the structure of the DOM, etc., etc. No excuse at all. None! Pas d'excuse! ¡No excusa! Keine Entschuldigung! Nessuna scusa!

Why not? Because these days, client-side JavaScript debuggers are a dime a dozen, and they're free. Pick your browser:

  • IE8 & IE9: Semi-reasonable debugger and tools built in, or use the free version of VS.Net
  • IE6 & IE7: Use the free version of VS.Net (or the old standalone script debugger)
  • Firefox: Get the excellent, and free, Firebug plug-in
  • Chrome: Has a good debugger and tools built in
  • Safari: Has a good debugger and tools built in (you may have to enable the menu item in the options)
  • Opera: Has a good debugger and tools built in
You get the idea. The next time you're running into a "cannot access property foo of undefined" error, don't guess where it happened, use a debugger to walk through the code and see!

Happy coding debugging!