AngularJS vs ReactJS, both.. because it “Depends”

AngularJS-vs-ReactJS-detailed.jpgAngularJS is managed by Google and ReactJS is owned by Facebook. Both of them are unique and resourceful in their own ways. These frameworks are quite easy to use with high-end potential to build cutting-edge mobile and web applications. However, they have their differences too. Which brings the topic ‘AngularJS vs ReactJS: which is better?’Before…

via AngularJS vs ReactJS — DZone Web Dev Zone

What Makes a Team Great?

2016-09-15_12-45-25.pngI have had the privilege of being on 3 different teams that were great.   This same question has come up each time.  Opinion:  One or two drivers, those who help push the group tp greatness without appearing pushy, very difficult.  Open communication where everyone gets a turn to talk and systems to help that process along.  One great team had a Remote Bulletin Board System yes, a BBS.  It was called HARLIE and I still have a copy of it on diskettes floating around somewhere.

via What Makes a Team Great? — DZone Agile Zone

Atlassian JIRA, Agile and GIT what a combination.


Git is the de facto standard for agile software development when it comes to version control systems. This well-supported open source project is flexible enough to support a range of workflows that suit the needs of any given software team.  This Atlassian article is a great overview on how to handle the branches in a typical development project that has small and big changes as well as things breaking.

Farewell to Node.js v5, Preparing for v7

You may have missed it but at the end of June, the Node.js project said a final farewell to version 5. There will be no more patches, critical or otherwise, for this branch. To those who have been using Node.js for some time this may seem anomalous, shouldn’t major versions stick around for years?
We have a plan!
Last year, the core team devised a Long-term Support (LTS) and release plan to balance the various wants and needs expressed by Node.js users. Chief among those were:


The io.js diversion was useful for many reasons, including the opportunity we had to lean into this “progress" thing. We learned that there is a necessary trade-off between "stability" and the rapid iteration of the platform. Some of it was manageable but much was unavoidable. Breaking the entire C++ add-on ecosystem each time we upgraded V8 turned out to be quite painful for the Node.js package ecosystem. This is due to the heavy reliance on compiled native components in Node.js userland and the difficulty Node.js has had in maintaining API and ABI stability while upgrading V8.
On the flip side, it was clear that v0.10 went on far too long and the slow downward trend in release frequency was hurting the platform’s reputation for being innovative and modern and was preventing iteration on the features and fixes that Node.js actually needed. This was one of the key reasons io.js even existed.
So, all this experience and history put us in a position to try and formulate a plan for combining both stability and progress. We didn’t just find a compromise, we found a way that these often competing goals could coexist.
Which brings me to Node.js v5.Every 6 months, we plan to release a new major version of Node.js. The version is major in the semver sense in that we hold back breaking changes on our master branch until the 6 month point where we can release them together in a batch. The creation of these new release lines occur during April and October each year. Even version numbers happen to come in the April release while odd version numbers are in the October release.
Each major version of Node.js has an active life of 6 months in what we are now calling "Current". During this period we ship most of the active work that goes in to the Node.js codebase except for some items that we reserve for the next major release. Node.js version 5 was first released in October last year, so its "Current" period ended in April this year. At the end of this 6 month period, something different happens for odd and even versioned release lines. The even versions turn in to LTS and receive another 30 months of life; this happened for version 4 in October last year and will happen for version 6 in October this year. The odd versions, however, don’t get this extended life. Instead, as a transitionary measure, we provide another 2 months of support where we’ll ensure that important fixes make it into that release line.
And this is exactly what happened to version 5. It lived as Current for 6 months from October, 2015 to April, 2016 and then in a special Maintenance phase for another 2 months until June, 2016. At the end of June, we ceased supporting Node.js version 5 and it will no longer receive any fixes or updates from the core team (although you’re welcome to play with the v5.x branch on the Node.js repository if it’s important to you!)
The core team is focusing all of its activities on the following release lines:

v0.10 which will receive occasional critical fixes during its current Maintenance phase and will cease to be supported in October this year.
v0.12 which will receive occasional critical fixes during its current Maintenance phase and will cease to be supported in December this year.
v4 which is in Active LTS and is receiving more regular patches and occasional important feature additions, this will continue until October 2017 where it will switch to Maintenance and operate in a manner similar to v0.10 and v0.12 until April 2018.
v6 which is still a Current release, due to become our second LTS release in October where its life will continue under Active LTS and Maintenance until April 2019.
v7 is being planned for a release in October this year at the same time that we switch v6 to LTS. You can already try out nightly builds from our master branch at but expect to see a focus on quality and stability of these in the coming months as we create a v7.x branch and becoming more choosy about what gets to make it in to v7.0.0.

It sounds like a lot, but once we move beyond the legacy v0.12 and v0.10 release lines we expect the steady cadence of major versions and their various releases to become easier to understand.
Armed with this knowledge, what’s next for you? We suggest you make a judgement on the stability and quality requirements for your own use of Node.js and pick a release line that suits. For production deployments of Node.js we generally recommend version 4 where stability is taken very seriously. For everyday development, non-critical deployments and where Node.js is used as part of a toolchain (e.g. for building frontend components), a Current release should work just fine. We’d love your help testing nightly builds of the next major version of Node.js and while we do continuous unit testing and smoke testing of our master branch, we can’t provide any assurances of stability or quality of these nightly builds, so buyer beware.

Javascript (and Node.JS) Continues to Eat The World


“Node is a passing fad!” Just heard this again, this week from a Large Government Agency.  “Java is still the number 1 environment” was another phrase uttered at the same time.  Here is a secret between you and me….  don’t tell anyone else, let it be a surprise.  Javascript and Node.JS are eating the world.  Get with the program people, FTP and CSV files are being replaced by something “New” called JSON.  This post is a very good read and provides additional fuel to the JS fad that is underway.

The Need for Speed in Web Applications


This post has a video where a developer did a grid using the Sencha EXT.JS in 1.5 minutes.  I can’t find the article in that amount of time.   The Need for Speed in Web ApplicationsOften, web applications are slower than we would like them to be. Companies like Google and Facebook have in-house solutions for speeding up their applications. There is a need for a third-party tool that we developers can use to achieve something similar, without needing to spend hours to optimize…

via The Need for Speed in Web Applications — DZone Web Dev Zone

Powershell Learning tool

  • Learn PowerShell quickly from the interactive learning center
  • Execute PowerShell fast and accurately using the powerful IDE
  • Access hundreds of pre-loaded scripts from the QuickClick Library
  • Use the script editor to code & debug PowerShell faster
  • Visit the IDERA PowerShell Community for the latest tips and scripts

Interactive Learning Center

Experience PowerShell by example. Short tutorials guide you through basic concepts at your own pace. The comprehensive learning center also includes dynamically created help topics from currently installed PowerShell CmdLets, Snap-Ins, Modules, Providers and WMI objects.

Powerful IDE

The Console allows you to work interactively with PowerShell from a feature rich Windows UI. The Start page offers easy access to tasks, recent files and Getting Started topics. Plus, many productivity tools including System Explorer, Variables Monitor, Code Snippets, Command History, Remoting and many others.

Pre-loaded Scripts

Access hundreds of pre-loaded scripts for SQL Server, SharePoint, Active Directory and Exchange from the QuickClick™ Library. The tree structure organization lets you easily execute scripts in the Interactive Console, edit in the Code Editor and publish as self-contained XML documents that can be shared with colleagues and friends. PowerShell Plus includes all the scripts from the IDERA PowerShell Scripts for SQL Server free download.

Advanced Script Editor

The advanced debugger and script editor lets you build and test complex PowerShell scripts, try one line PowerShell commands from an embedded console, and sign your script with a security certificate all from a single workspace. Editor and encoding features include: code folding, bookmarks, breakpoints, formatting, find and replace, and much more.

Download Community Scripts

Search and download thousands of community scripts from PoshCode and Tech Net script center libraries – directly from the PowerShell Plus console and editor. Plus, publish and share scripts you have created to any network share.