Looking for New & Exciting Technologies
I’ve started using Webpack in my build process and I must say, I’m quite impressed. So over the past couple of years my build process has migrated a bit. I started by using Grunt, moved to Gulp and then created my own build process to address some custom items working with Red Pill’s infrastructures and Domino. But since finding Webpack, I’m finding that it does a much better job, with much less effort.
So,
In Part 1 we got a very small taste of node.js and a simple example of what it is. It’s basically a JavaScript engine that runs on the desktop. While Part 1 wasn’t very in depth or that useful, I think it’s a perfectly simple example of node.js in action.
So that leaves to question, what can we do with it? Well, we can do a whole lot with it actually.
With the recent announcement of upcoming node support for Domino, I think we need to start looking into what it takes to get into node.js development. The truth of the matter is, it’s not really that difficult. To start with you need to install node.js. Then find a decent editor (I recommend Visual Studio Code).
Once you’ve got these things, create a new project directory somewhere (I’m gonna use hello-world).
I’ve been thinking about this post for quite some time. I just haven’t had the time to write it. But, JavaScript is both a weird and wonderful programming language. It has some features which are totally NOT the norm but make it cool and interesting to work with. While there are many flavors of JavaScript out there in the wild (ES1 -> ES6, TypeScript, CoffeeScript, etc.) the weirdness remains no matter how your JavaScript is written.
Here lately I’ve been writing a lot of tooling in preparation for upcoming projects. This tooling is meant to lessen the amount of work to start up a new project. A while back I watched this video. That video inspired me to come up with a repository in which a front-end developer could clone, run a couple of commands and be ready to write code for the new project. Going down this route has been quite the eye opener to the complexity of what a modern progressive web app is today.
Since my move to OpenSource JavaScript frameworks, libraries, modules, etc. I spend a lot of time looking at the documentation for whatever it is I’m working on. Some docs are really good. They give a description, example, what something returns, what it expects as parameters, etc. However some are really bad. They define the name of the function/property/whatever but they don’t say what the hell it does. Take this example from the nodejs documentation for the ‘
As web developers the ability to troubleshoot a web application is a very important part of the development process. To be able to see what’s happening and understand what may be causing a certain behavior is key and should be employed during the entire development process, not only when something is broken. In this series I will outline my process of troubleshooting web applications.
First off the tools. While there used to be a hand full of tools you might use now you only need one,
Happy New Year! Lately I’ve been working on ways to simplify and enhance the way in which we develop applications. I watched this video: The Reusable JavaScript Revolution which really got my brain working and trying to come up with a solution for Red Pill Now. One of the pieces of the application part of that project is a context element (now-context) that provides a few different features:
The entire idea here is to provide a communication channel similar to that found in Backbone/Backbone Marionette for application specific communication.
Over the past few months I’ve started working pretty extensively with TypeScript. For those of you who don’t know what TypeScript is:
TypeScript is a typed superset of JavaScript that compiles to plain JavaScript.
It provides strong types to JavaScript. It allows for the creation of classes and enforces those classes in your code. If you define a Redpill.Widget class, you can then use that class in your code and the editor enforces the rules you define within that class.
If you followed Peter’s series on replacing Lotus he outlined some of the pitfalls, processes and decision points to undertake for success. I wanted to point out the technical side to a lot of those decisions. The short answer is that you need a tool to surface your domino data en-masse until such a time when decisions are made on each application. I have been working on that solution for quite some time now and I have to say,