Nordic.js and .NET Fringe

Ok, so many of the conferences out there you’re going to get fed the company line. You’ll probably experience some odd behaviors and people pushing product on you. If you’ve got the same feeling about conferences as me, and you’d like to experience these things at a conference:

  • A diverse audience of many different people from many different places.
  • You’d like to talk to others that are passionate about the future direction of technology and what we can create with that technology!
  • Listen and watch presenters provide insight to technology, ideas, and spaces that I don’t regularly get to hear about or discuss.
  • Meet many new friends, build my cohort of coders, and learn from each other.
  • Have a good time, relaxed, and not under the pressure of being sold things.

…then these conferences are for you. Seriously, I wouldn’t and won’t ever direct anybody to corporate conferences anymore except maybe in super rare occasions. The conferences to attend are the grassroots, community organized conferences like these two! There are too many other truly awesome conferences where the future is being discussed and made RIGHT NOW! There’s a few lined up that I’ll be attending and am currently working with as an organizer. Here’s the top two RIGHT NOW!

Continue reading “Nordic.js and .NET Fringe”

My Train of Thought on JavaScript, Web Analytics, & Segment

Beware, this is my brain dump as I attempt to figure out Segment integrations. It might seem disconnected at first but I’ll make every effort to loop things back around. First a few pieces of context, or more simply my goals for this blog entry:

1. My goal here is to implement a server side integration with Segment that allows for data, which flows through their system, to end up in another system.

2. The term, it appears, for the software one would build and deploy to their system for them to feed data into another system is called an integration. There is a long list of the integrations that they have available today. It’s so long, that Segment actually has a search feature and all of the integrations divided into sub groups of integrations by advertising, analytics, marketing, sales, support, developer, and user testing.

Continue reading “My Train of Thought on JavaScript, Web Analytics, & Segment”

I’m so mad!!! My response to the fork of node.js to io.js!

I’m so mad!!!

No, actually I’m not. This is cool.

It’s so confusing! No, it’s actually not. Use your learnings and read this Node Forward and read Max’s @maxogdenWhat you need to know.” gist.

It’ll be so hard to test this and test with node.js. Not really, again, read the threads there are a million different ways that you’ll be able to setup a clean build against either while keeping both around on your dev machine. Again, repeating myself, this is cool.

Summary for Devs: This is cool. It’s not going to wreck your projects. Just read up on it and it’ll all be a most excellent journey.

Summary for Decision Makers: Read @eranhammer‘s blog post here. TLDR; is, don’t second guess your decision to go with Node.js, don’t flip out about a Node.js or io.js investment, this isn’t anything more than a healthy ecosystem at work. It’ll be cool.

Getting in Some Code Stylings, Looking Good for the Code Dance

In every language there are opinions about how to format code. With JavaScript, the community abounds with opinions about how the code should look, how variables are declared, whether there should be semi-colons to end each statement, spaces before or after parenthesis, and more than I care to list in a simply worded paragraph like this. Recently the team at Deconstructed sat down to determine what our ongoing code style format would be and how we can enforce it.

The first thing we did was figure out what we could use for enforcement of the coding style. Milan (@milanloveless) quickly discovered node-jscs per suggestion from Adam Ulvi (@s5fs). He implemented that code as follows.

Continue reading “Getting in Some Code Stylings, Looking Good for the Code Dance”

More on Using the Nools DSL and Engine…

Nools Objects

In the helloworld.nools object there is a single object defined called Message. This object has two elements defined; the text property and the constructor. The specific object definition is shown below.

define Message {
    text : '',
    constructor : function(message){
        this.text = message;
    }
}

This object can now be referred to by name throughout the nools file. The other way to reference this object is to call the getDefined function from the flow object that is being used in code processing the business rules. In the nools language any javascript has can be put inside the define blog. By defining the constructor as shown, it overrides the default constructor behavior. Continue reading “More on Using the Nools DSL and Engine…”

Learning “nools” Rules Engine

Recently I sat down to work up a solution around a rules engine. There were a few things I noticed right off.

  1. When there is a request to implement or build a rules engine it is very often (I’m guessing a solid 40-60% of the time) reasoned that there is a need solely based on a lack of understanding around what the problem space is that actually needs a solution. The simple assumption, is 40-60% of the time somebody says “let’s implement a rules engine to solve these unknown problems” really translates to “we really don’t know much about this domain so let’s implement something arbitrary as a stop gap”.
  2. Implementing a business rules engine can quickly become a “support the user” scenario for the developers that implement the rules engine. This is a situation in which the developers actually have to help the people writing the rules to be processed. This is not an ideal situation at all, generally developers supporting users writing rules is a quick way to ensure burn out, misappropriation of skills and turnover.
  3. Many developers will, without hesitation, spout out “are you sure you want to implement a rules engine?” and then follow that up with “let’s discuss your actual problem” with that leading to “are you sure you want to implement a rules engine?”. Other developers upon hearing that one will implement a rules engine immediately respond with, “shit, I’m out.”

At this point I realized I had X, Y and Z reason to use it and would just have to persevere with all of the threats that are inclusive of implementing a rules engine. Sometimes one just has to step into the realm of scary and get it done.

So here’s what I dug up. I’m really not sure about the name of this project, as it appears to be some sort of odd usage, so whatever, but it is indeed called nools (github repo). Nools is a business rules engine based on the Rete Algorithm, something that is helpful to read up on when implementing. The main deployment for nools is to a Node.js server, but I’ve read that it is prospectively deployable in most browsers too.
Continue reading “Learning “nools” Rules Engine”

Framework: Strongloop’s Loopback

Recently I did a series for New Relic on three frameworks, both for APIs and web apps. I titled it “Evaluating Node.js Frameworks: hapi.js, Restify, and Geddy” and it is available via the New Relic Blog. To check out those frameworks give that blog entry a read, then below I’ve added one more framework to the list, Strongloop’s Loopback.

Strength: Very feature-rich generation of models, data structures and related enterprise-type needs. Solid enterprise-style API framework library.
Weakness: Complexity could be cumbersome unless it is needed. Not an immediate first choice for a startup going after lean and clean.
Great for: Enterprise API Services.

When I dove into StrongLoop, I immediately got the feel that I was using a fairly polished package of software. When installing with ‘sudo npm install -g strongloop’ I could easily see the other packages that are installed. But instead of the normal Node.js display of additional dependencies that are installed, the StrongLoop install displayed a number of additional options with a shiny ASCII logo.
Continue reading “Framework: Strongloop’s Loopback”