Getting my Twitter feed under control

Does anyone else out there feel like Twitter just headed south, what with all the politics, and Nazis, and unfortunate negativity towards #MeToo, and the Alt-Right, and the general lack of emotional intelligence, and #<insert-your-complaint-here>? I’m not able to deal with all of that right now, and I strongly considered quitting the service. I even took a break for a week or two. However, I really like micro-blogging, I have a good size following, and I love the different types of information I can access on Twitter, even though I primarily use it for keeping up with business contacts. That last bit is especially true for getting my #StarTrek fix when the work day is done! Twitter’s Trek community is amazing!

Here’s the list of things that I’ve done to clean up my Twitter feed, and make it worth my time. So far it is looking really great and interesting again. If you’re in the same boat as me, I hope this helps you out.

  1. Unfollow some folks – I started unfollowing some folks, mostly those who are inactive or rabble rousers. I especially unfollowed feeds that just depressed me, no matter how “valuable” some might find there feeds. (Here’s looking at you @SenBobCorker! #byebye)
  2. Mute people – Actually @Mrs_Billings put me onto this. Wait… did my wife mute me!? At any rate, muting someone you follow prevents their Tweets from showing up in your timeline, but you still see notifications and direct messages from them. It is a good way to keep following your friends even if you don’t want to see all their My Little Pony tweets, for example.
  3. Use more lists – If neither of the above are a great fit, putting feeds on lists is a good way to only check in when you want. I’m in the process of moving everyone I follow related to #StarTrek to a list because sometimes in the middle of the day I cannot afford to get side tracked by #AshIsVoq, even though I would really love to clear my schedule for it!
  4. Adjust your interests – Twitter tracks your “interests” for its own uses and for companies. You can set which of these auto-generated interests that you would like to see in your feed in the data settings.
  5. Mark uninteresting tweets – I’ve started telling Twitter when I don’t like tweets. I’m not sure how well this feature works since they keep posting certain types of content that I don’t like into my feed, but I’ll keep it up for a few days and see.

There you go. I’ll let you know how well this works in a few weeks. Sorry if I unfollowed, muted, or listed you, and you find that offensive. I promise I won’t be offended if you do the same to me too because I now know just how hard it is to get a Twitter feed under control!

Fitting data to a function with Gnuplot

Put your x,y data in a file that Gnuplot can read, like a simple text file with an x,y pair on a line separated by a space.

Define the function, for example:


Do the fit:

fit gauss(x) ‘gaussTest.dat’ via a, sigma, p

Plot the output with the data:

plot ‘gaussTest.dat’ with histeps, gauss(x)

Connecting IBM Rational Team Concert 3.0 to a Subversion repository

I am migrating my NiCE project to SourceForge so that we can get it out of the door to customers for the low, low price of $Free.99. I’ve been a huge fan of IBM and IBM Rational products for the past couple of years, but the need to have a license and an account FOR EVERYONE in RTC just doesn’t work for an open source project (by the OSI definition, not IBM “free as in puppy” crap).

One of the challenges that I expected as soon as I even thought about SourceForge was integrating the new repository with Rational Team Concert. Sourceforge gives you a choice between SVN and git. I chose SVN because git is poorly supported by RTC, even though they claim that there is a connector that you can download on In fact, if you go to net and look for said git connector, all you will find is some page that will tell you how to make a connector for RTC2.0. So, my git hopes aside, I picked SVN…

It turns out that RTC has great support for SVN. While I’ll have to go through the steps to migrate the files on my own, there are four simple steps to get it setup and running:

  1. Install Subclipse or Subversive.
  2. Add an “SVN Connection” to connect RTC to your new repo using the Jazz SVN Connections view.
  3. Right click the project you want to share, open the properties window, select Jazz Work Items and check the “Link the project to a Jazz work item using SVN bugtraq properties” box.
  4. Share something with your project and give it a valid work item number!

More details can be found here:

There’s still some work to do to get NiCE in the repo, but it looks like smooth sailing from here out. The big thing to remember is that you have to use a separate SVN client – IBM does not provide one – and you may need to run “Update Links” from time to time by right clicking your SVN connection in the Jazz SVN Connections view.

Fixing annoying MOZILLA_FIVE_HOME errors

If you are having problems with SWT crashing because it can’t find MOZILLA_FIVE_HOME on Linux, make sure that you have xulrunner installed, check that it 32-bit or 64-bit to match the version of SWT that causes the error and add


to your .bash_profile file.

For example, on the 64-bit version of Fedora 14, tools from IBM Rational will throw this type of error because they run on a 32-bit JVM with a 32-bit SWT. Running

yum install xulrunner.i686

and setting


in .bash_profile fixes the problem.

Migrating to RTC3.0 from RTC iFix 5.

I had trouble upgrading from RTC Express-C iFix 3 to RTC3.0
Express-C with both versions using the Derby database. I was able to get it
working using the instructions below. Some key points:

1.) Copy the repositoryDB *FOLDER* not the zip archive.
2.) Run the server.startup.bat as an Administrator in PowerShell.
3.) You should not be asked to create a user for the JTS, but if you are,
*DO NOT* create a user that was part of a project in your 2.0 install. This
will destroy the user mapping created during the migration and you will not
be able to access your project.

—–Instructions for upgrading to RTC3.0 from RTC Express-C with the
Derby database on Windows Server 2008 R2 —–

Create a back-up of your RTC install.

If you have an older version of RTC, make sure you download and install
RTC iFix 5 before upgrading to RTC3.0. All you need to do to install
RTC iFix 5 version of Express-C is:

1.) Download the .zip archive from
2.) Extract it somewhere
3.) Copy the repositoryDB folder from the /server directory
of your original install to the /server directory of your new install and
4.) Copy /server/tomcat/conf/tomcat-users.xml from your old install to the same
directory in the iFix 5 install.
5.) Copy /server/conf/jazz/ from your old install to the
same directory in the iFix 5 install.
5.) Start the server.

The repotools-jazz script that is used below would not work properly for me
until I first migrated to iFix 5. I noticed a 1MB difference after running
iFix 5.

Now, you can start to migrate to version 3.0:

1.) Download the web installer from
2.) Run the installer and, when prompted check the “Upgrading from a previous
version of RTC 2.0.x.x” box. *DO NOT* start the server after the install.
3.) Remove both the repositoryDB folder and the file from the
/server/conf/jazz/derby directory of your RTC 3.0 install.
4.) Copy the repositoryDB file from your iFix 5 install to the
/server/conf/jazz/derby directory of your RTC 3.0 install.

After completing these steps, you need to migrate the configuration info from
your old install to version 3.0 and then migrate the database. To migrate the
configuration info, follow the steps outlined at

in the “Using repotools to start file migration” section. Follow the
instructions in the “Repository database migration” to migrate your
database. Make sure you receive a message stating success at the end of each
step. Ensure that the database repository URLs in your
files point to your new install, not the old one.  Also, note that on Windows
you have to run .repotools-jazz.bat and .repotools-jts.bat instead of simply
repotools-jazz and repotools-jts as described in the documentation linked
If all of this is successful, you should be able to start the server and run
the setup scripts. The server will take a very long time compared to its
normal startup time when you start it for the first time, but subsequent
starts will drop back to about twenty seconds. The instructions for how to
launch and setup the server can be found in the documentation above under
the “Deploying and starting the Apache Tomcat server” section.