I have been working on a specific code change with a client for about two weeks. This included about a dozen commits to the git repository before making a pull request. The client reviewed the pull request before merging, and requested I roll back a few changes. I had made these commit 8 commits ago, and from the dozens of files changed I only had to roll back two.

How do you do it?

I didn't see an obvious way to roll back just those files using SmartGit, my tool of choice, so I had to drop back to the command line. This did it:

The SHA is the unique identifier for each commit. I opened up SmartGit, viewed a change log, found out which commit I changed these files, went to the commit before that, clicked 'details' and the SHA value is listed right there. You can also get the SHA value from GitHub if you prefer. Go into the Pull Request, and select commits. The value is in the table, to the right of the commit message.

The path to the directory is your local system path. I had to use the absolute path. Since I'm a Windows user that started with the C drive, drilled down into my project folder, to the repository. And then I drilled down deeper into the repository to find the specific subdirectory I wanted to revert. Reverting the subdirectory is easier than reverting all the files individually.

I executed the line inside of GitShell. Everything worked.

I found a bunch of posts covering this topic, but most of them confused me. Hopefully this helps someone. Let me know!

I've been working on a legacy AIR application for a client. It integrates with a backend I have no control over. According to their documentation, we need to pass the form parameters in a specific order. This seems unusual for a form post, which contains key-value pairs and is probably not accessed in parameter order. But due to other problems integrating with this service, I decided to see what I could do to specify the parameter order and remove that as a possible point of failure. I wrote about my attempts in this StackOverflow question.

What Didn't Work

This is what we were doing. First, create an HTTPService:

Then, create the parameter object in code:

When the parameter object is created for the service call, I added the parameters to the object in order.

Then make the call:

You may have already guessed why this won't work. Object parameters, or keys in a dictionary, are by definition, not in any specific sort order. When the Flex code looped over all parameters to add them to the outgoing service, it was accessing them in alphabetical order. However, that is not something I would bet my life on happening every single time due to the unordered nature of object properties. I also noticed that the outgoing request in the Flash Builder network monitor had the parameters in yet another order. Something with them changed between the Flex code and the server hit.

So, what am I to do?

Using Lower Level APIs to make this work

The final solution was to use lower level APIs. I created the request using URLRequest and URLLoader classes. Instead of passing an object to the request I also had to manually create the request body which is very similar to a URL parameter string.

First, create the parameter string:

Then, create the URLRequest:

The data is set to the parameters string. The method is set to POST and the contentType is set to 'application/x-ww-form-urlencoded'.

And finally, create the URLLoader:

After doing this I could see in the outgoing requests that the parameter order was retained. So, things were good and my issue was solved! This is a lot more tedious than using the HTTPService, but at least I eliminated it as a possible error.

I was working with a client to create a specific layout on the page and I wanted to align a div inside another div. But, I couldn't use text-align because I didn't want to right align the text elements in the inner div. How do you do it?

First, create the outer div and inner div:

A simple div is inside another div, and the inner div has some text. The outer div's only purpose is a wrapper for positioning purposes. Both the outerDiv and innerDiv have CSS Styles attached.

This is the CSS for the outerDiv:

It enables the outerDiv to use flexbox styling and floats the content to the right. Flexbox is an advanced way to position CSS elements.

The innerDiv doesn't need any special CSS styling to make this work, but let's give it a background color:

Play with the code here.

The implementation is really simple once you figure it out; but sometimes getting there is a stumble.

I've been working with a client on a project that uses AEM and ran into a problem committing code changes to their git repository. The error told me that the filename was too long.

The error was something like this:

error: unable to create file 'really long path to file' Filename too long

I banged my head on this for a bit, but eventually found a solution.

I had to change a flag with the version of Git that was included with SmartGit. Open up a console window. Move to your SmartGit install directory. For me that was:

You should have a git subdirectory in there. Switch to it, and drill down into the bin directory. My full path would be this:

Now run this command:

And try the commit again. Things should work fine.

I've been having some issues with Angular 2 [now Angular 4] and the RouterModule. I put together this screencast to demonstrate the problem and how I fixed it:

I've written in the past about migrating ColdFusion instances from one machine to another. Most of the time when I have to do this it is because of a hardware failure and I'm setting up a machine from scratch. This seems to happen every 4-6 years. Despite it's impending immediate death, 20 years running, I still do a quite bit of ColdFusion development. It's the devil that I know on the server side.

Without a working machine, I can't sign into the CF Administrator and export CF Admin settings, so I have to go to other methods to get my config up and running. I've written about similar experiences with ColdFusion 8 and migrating from ColdFusion 8 to 9. But, time moves on and most of my production clients use CF10, so that is the version I have installed on my local.

How do I get the old CF configuration set up the new machine when all I have access to is the old CF installation directory? this is how I did it.

1. Install Apache: ColdFusion is useless without a web server, so first I installed and configured the Apache web server.
2. Install ColdFusion 10: Get ColdFusion 10 from the cfmlRepo site. More specifically, go here. be sure to download app the patches. And send thanks to whomever takes care of that site.
3. Install CF Hotfixes: Next, install all the ColdFusion hotfixes. You'll have to install the first few manually before you can use the update feature inside the ColdFusion administrator. Uses these instructions, but basically do this:
   
   C:\ColdFusion10\jre\bin\java -jar hotfix_008.jar
   

   I installed hotfixes 7-13. The rest I updated through the ColdFusion administrator.

4. Compare Directories: Now compare your old ColdFusion install directory to the new ColdFusion install directory. You'll be surprised at how many of the files will be flagged as identical. Those aren't the ones you need to worry about. I focused on the config files in cfusion\lib\*.xml, and copied them over from the old directory to the new one. These are the configurations I moved:
   • new-cron.xml: Not sure what this one is for.
   • neo-datasource.xml: this file contains DSN configuration information.
   • neo-debug.xml: This contains CF Debugging settings.
   • neo-logging: This contains log related settings.
   • neo-mail.xml: This contains mail server settings.
   • neo-metric.xml: I couldn't figure out which settings this one contains, but I copied it anyway.
   • neo-runtime.xml: This file contains misc settings.
   I was making some educated guesses here. I think Neo was the code name for ColdFusion MX, so it is funny to see the name still kicking around.
5. Restart ColdFusion: After the restart, you should find all your CF settings restored.
6. Change DNS Passwords: I did notice that I had to reenter the passwords for all my data sources.

Overall, the process worked a lot better than I would have hoped.

I recently upgraded this blog to run exclusively on SSL. The first thing I noticed is that many of the links and image references inside blog posts were not HTTPS and the browser would show one of those 'this page is not secure errors'. The reason that the text of my posts use absolute links instead of relative is so that they'll show up properly for those who consume the blog via RSS and read it elsewhere.

I spent a few hours white boarding a bubble sort algorithm before deciding I was getting nowhere, I decided to try a Google Search for the answer.

In SQL Server, which is my blog's data store, you can use a replace function to make the change. I can do a simple search for text inside a column and replace it with something else. Perfect, that is what I need.

Here is a StackOverflow answer with more details. The query they recommend is:

Of course, when I did that I immediate got a conversion error. The body of these posts are stored as ntext fields inside the database. and the replace() function will not work on ntext or text fields. Thankfully, there is a solution to that too. A simple cast addressed the issue.

If you use BlogCFC and need to do this on one of your blogs, here is the final script I used:

I hope this helps someone.

This is part of an ongoing series about building Angular 2 TypeScript applications with Gulp. Start with Part 1, and then read Part 2, Part 3, Part 4, Part 6, Part 7, Part 8, and Part 9.

There was one more thing I wanted to touch on for the purposes of this article. When changing code, I want the app to automatically be recompiled. Gulp provides built in functionality to make that happen. Iterative builds help improve performance, and get you reviewing your app in the browser without having to manually compile every time.

Watch for TypeScript changes

Create a task named buildWatch:

The first thing this task does is build the application. The array before the function does this. This makes sure that we have the most recent code in the build directory before we start making changes.

Then we need to start watching for changes. We can use the watch() method of gulp to do this. First, the TypeScript files:

The first argument to the watch() function is the glob array that points to the TypeScript source. The second argument is an array which represents the tasks to execute when a change is detected. In this case, the buildTS task is executed. When a change is detected, I chained an on() event after the watch() task. This outputs the name of the file that changed.

Let's try this:

You should see something like this:

Notice that you are not sent back to the console prompt after running this. The task is waiting for something to happen. Change the main.ts file by adding something simple like this to the end:

Then look at the console:

The changed file was output the console, and the buildTS was re-run. The buildTS task runs tslint before building the code; that has not changed.

Watch for HTML and JavaScript Changes

You can use the exact same approach for watching changes with HTML and the JS Libraries. Add these to the buildWatch task:

As files are changed, the relevant tasks are rerun. I don't usually watch the Angular libraries because they are rarely changed or updated during development unless it is a big project decision.

Final Thoughts

Build scripts are important. When I started doing Angular 1 development with JavaScript, I could just use JavaScript directly in the browser and was able to push off dealing with build scripts to a future time. However, when using Angular 2 with TypeScript, the build process became much more important since a compile process is needed before you can test your code. I had to jump in earlier than I would have otherwise.

Remember, you can get all the code for this series in our seed project repository. Thank you for reading, be sure to sign up on our mailing list to get information like this direct to your inbox each month.

This is part of an ongoing series about building Angular 2 TypeScript applications with Gulp. Start with Part 1, and then read Part 2, Part 3, Part 4, Part 6, Part 7, and Part 8.

Sometimes I like to create a build intended for production servers which does not include source maps. To make that happen, I use a gulp-if plugin to conditionally decide whether to generate the source maps, or not. First, install gulp-if:

You'll see an install screen like this:

Now, import the gulp-if library as part of the gulpfile.js:

Before we modify the buildTS task, let's add a variable named devMode:

This is the variable we will use to determine whether or not to generate the source maps. It is set to true by default. Primarily we will change this variable as part of tasks, not as a configuration option. Review the buildTS task:

We want to use gulp-if as part of the two source map statements. First replace the source map init statement:

Instead of just calling sourcemaps.init(), we now wrap it in a gulpIf. This will check the devMode variable and conditionally init the source maps.

Also change the sourcemaps.write() pipe:

With the buildTS task updated, we can now create a task for building a production version of the app. The purpose of this task is to set the devMode value to false; and then run the cleanBuild task:

We can use gulp.start() to run the cleanBuild task. Running cleanBuild will delete the build directory, and then run the build task to compile the TypeScript files, move the HTML, and move the JavaScript libraries.

Run the task:

You should see this:

Take a look at the build directory:

You'll notice that the maps directory is missing; meaning that the sourcemaps were successfully bypassed when running the cleanBuild. We can use this same approach to perform other actions as part of a build process. In the future, I plan to make changes to the buildProd script to force the Angular application into production mode, instead of development mode by default.

What's Next?

I have one final entry prepared for this blog series. The next one will talk about recompiling code as you make changes.

Get our white paper for even more information:

This is part of an ongoing series about building Angular 2 TypeScript applications with Gulp. Start with Part 1, and then read Part 2, Part 3, Part 4, Part 6, and Part 7.

This part of the series will show you how to delete the build directory and produce something that I call a clean build. This is important when refactoring code, which may leave remnants of old files in the build directory.

Delete the Build Directory

To delete a directory, we can use the NodeJS Plugin, del. This isn't a Gulp plugin, but can be wrapped in a gulp task. First, install it:

You'll see the install screen, like this:

Next, you can load the del library inside your gulpfile.js:

Create a glob array with everything that needs to be deleted:

The destinationPath variable is used, with a wild card after it. This tells the del task to delete everything. Next, create the task:

The task is named clean. It calls the del() module with the deletePath value. Run the task:

You'll see this:

Check your project directory:

The build directory is noticeably absent, which is exactly what we want.

Run Clean, then Build

Let's combine the clean task with the build path. To do that we'll want to run the two tasks in sequence, as we don't want the clean task to delete files the build task is creating. To do that we'll use a gulp plugin named run-sequence.

Install the plugin:

You'll see this:

With it installed, we can create an instance of it in the gulpfile.js:

Then, create the task:

I named the gulp task, cleanBuild. It uses the runSequence library to run the clean task--which deletes everything in the build directory, and the build task--which will create a fresh build.

Run the task:

You'll see something like this:

You see that the clean task is run first; and after it is finished the build tasks start. This will delete the build directory and all other relevant files, and then re-generate using the other tasks we wrote about earlier in this chapter.

What's Next?

The next part of this series will create what I call a production build. The final part will show you how to watch directories for changes while the code is in development.

Sign up to our mailing list to get an expanded version of this series.