Linus’s Turn

This was a message I sent to the students today where I work.  Also, hello after four years!

Instructor Hat On

In the software world many of you know who Linus Torvalds is — he’s the main developer on Linux and has been for maybe 3 decades. He also wrote GIT because another tool wasn’t working good enough for his community (if not his own) needs. He’s infamous, in many ways. Linus has also secured for himself quite the reputation with angry emails, pointed profanity, and overall being a real negative (jerk of a) person to work with in the software community. If you submit a patch and don’t get it right, beware of Linus!

On one hand he’s been the leader of Linux development, but it doesn’t take much to see his attitude affecting and (negatively) permeating that same culture. Over the weekend, however, he came out with an update email that included an _apology to the community_. That’s news by itself! He elaborates, recognizing his personal limitations and self reflection.

This is my reality. I am not an emotionally empathetic kind of person and that probably doesn’t come as a big surprise to anybody. Least of all me. The fact that I then misread people and don’t realize (for years) how badly I’ve judged a situation and contributed to an unprofessional environment is not good.

This week people in our community confronted me about my lifetime of not understanding emotions. My flippant attacks in emails have been both unprofessional and uncalled for. Especially at times when I made it personal. In my quest for a better patch, this made sense to me. I know now this was not OK and I am truly sorry.

The above is basically a long-winded way to get to the somewhat painful personal admission that hey, I need to change some of my behavior, and I want to apologize to the people that my personal behavior hurt and possibly drove away from kernel development entirely.

[Emphasis mine]

I really wanted to share this with you all because this turning point is important. Linus Torvalds, of all people, is recognizing that the people you work with and how you affect them matter. It’s not just about the code; it’s not just about the release. As computer scientists and developers we can get pegged as anti-social, basement dwellers, angry towards “users,” and generally hard to work with, that _does not have to be the case_. You choose how you interact with your community, and you can choose to counter those stereotypes. When Linus stands back and recognizes it for himself, it’s an example I hope you recognize and follow in your own careers.

I invite you to read the email in full and keep tabs on how the community reacts. Full email here: https://lore.kernel.org/lkml/CA+55aFy+Hv9O5citAawS+mVZO+ywCKd9NQ2wxUmGsz9ZJzqgJQ@mail.gmail.com/

Converting SVN to GIT with Gitolite

What a great resource!

Convert an SVN repo into a GIT repo

First, start here. http://john.albin.net/git/git-svn-migrate and http://john.albin.net/git/convert-subversion-to-git.

This was the best first-step I found in converting one of our project’s SVN repo into a GIT repo. This was a FANTASTIC walk through, and the script really made it simple. I had to modify a few of our authors into a dummy account we have (per instructions), since they don’t work here yet I wanted to preserve their history.

The whole SVN-to-GIT process was smooth.

Get old SVN code into a clean gitolite GIT repo

After doing this, however, I needed to update the working copy on our dev machine(s) so that they too were connected to the git repo. We use gitolite to manage our repos, so there were a few things I had to do along with the conversion.

  1. Create a bare repo using a normal gitolite-admin commit/push.
  2. Do the conversion as described above, to a local bare repo into a temporary working directory on the dev box.
    # ./git-svn-migrate.sh --url-file=repository-list.txt --authors-file=author-transform.txt /tmp
    
  3. Clone a copy of the new (local) GIT repo from this new temp location.
    # cd /tmp
    # git clone repo.git (makes a new "repo" folder)
  4. Remove the remote origin
    # cd repo
    # git remote rm origin
  5. Add in my normal origin URL for our gitolite installation:
    # git remote add origin gitolite_server_url:repo.git
    
  6. Push my code into the repo
    # git push origin master
    

Adding in the extra steps to start with a blank repo via gitolite, and then pushing into it, is what got me set! I initially tried to copy the bare-repo by replacing the one in gitolite’s repository directory, but I wasn’t able to get it working right away. This was clean and works with the rest of our scripting systems!

Move the GIT repo into the dev space

We have clones running in the webroots for most of our projects. Now that the GIT-version repo is ready, I simply copied off the original SVN-littered webroot directory, and replaced it with a fresh clone from the new GIT repo. I also had to add some “empty” files into the empty directories since GIT doesn’t track them, but that was minor.

Done!

Now we have a fully converted GIT repo that includes the history from SVN, running for our dev box and for the developers to clone!

Thanks to Matt N. for the initial gitolite setup, too.

Configure PHPStorm to use Git-bash

In our office I use git-bash for a my commit needs, and PHPStorm for my php scripting.

I’ve taken a moment to configure PHPStorm to use git-bash for its terminal tool instead of the default cmd.exe from Windows.

To set up git-bash as PHPStorm’s terminal:

  1. Open File…Default Settings
  2. Click the “Terminal” option from the left navigation menu
  3. Enter the path to git-bash’s sh.exe with –login and -i switches, for the Shell path input box
    “C:Program Files (x86)Gitbinsh.exe” –login -i
  4. Enter  “GitBash” for the Tab Name

Done!

 

gitbash config for phpstorm

Secret URLs are Leaky URLs

I’ve implemented “secret” URLs in some projects. Look like I’ll have to go back and revisit these.

If you’ve typed a “secret” URL into a search box, advertisers on the search results page get to see your “secret” URL (and thus your document) since it was your “search term.” Also, the “secret” URL to your document is exposed as the referring link when you click out of a document. Interesting problem.

http://grahamcluley.com/2014/05/dropbox-box-leak/

 

One reason why you shouldn’t type a full URL into Google’s search box.

Right Click Open PHPStorm from a Directory

As silly as this may sound, I wish PHPStorm would open from a directory.  So, I learned how to make a simple right-click menu handler for Windows.

Next steps: only make this appear if the folder contains an “.idea” folder.  These registry keys place a context menu when clicking the folder itself, or in the background of an open folder.

This seems to work. Copy this out to a .reg file and then run it to import the rules into your registry.  Note that the static path will break when you upgrade PHPStorm.  Faults abound, but this is the simplest case!

Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOTDirectoryshellPHPStorm]
@=”Open as a PHPStorm Project”

[HKEY_CLASSES_ROOTDirectoryshellPHPStormcommand]
@=””C:\Program Files (x86)\JetBrains\PhpStorm 7.0\bin\PhpStorm.exe” %V”

[HKEY_CLASSES_ROOTDirectoryBackgroundshellPHPStorm]
@=”Open as a PHPStorm Project”

[HKEY_CLASSES_ROOTDirectoryBackgroundshellPHPStormcommand]
@=””C:\Program Files (x86)\JetBrains\PhpStorm 7.0\bin\PhpStorm.exe” %V”

 

Alternatively, this registry code will  set the default action on an .idea folder to open phpstorm.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINESOFTWAREClassesDirectoryshellPHPStorm]
@=”Open as PHPStorm Project”
“DefaultAppliesTo”=”System.FileName:”.idea””
“Icon”=””C:\Program Files (x86)\JetBrains\PhpStorm 7.0\bin\PhpStorm.exe””

[HKEY_LOCAL_MACHINESOFTWAREClassesDirectoryshellPHPStormcommand]
@=””C:\Program Files (x86)\JetBrains\PhpStorm 7.0\bin\PhpStorm.exe” “%W””

 

I’ve configured the latter!

Polyfill HTML5’s placeholder for LTE IE 8

For one of the projects today, our designer made up a nice, simple, sign up form with a modern look and fun feel. (See http://codecrush.unomaha.edu)

We installed the jQuery Placeholder polyfill by Mathias Bynens, but it didn’t work in IE.  At first we thought it was IE 10 not properly failing in IE8 document modes.  Deeper digging was needed.

Turns out, our code had two versions of jQuery – 1.9.1 and jQuery 1.10.  The jQuery 1.10 won out over the 1.9.1, and if you remember, jQuery changed a bunch of things in 1.9.2 requiring the migrate.js library.  After realizing the mistake with the mis-matched jQuery versions, we dropped the 1.10 libarary and all was right with the world!

Lesson for today: even sample code can have errors in it!

 

Happy coding 🙂

jQuery Troubles Lately? Use Migrate.

If you’ve come back into jQuery recently and noticed that things aren’t working like you remember, you’re not alone!  I’m talking to you, Drey and Greg!  Apparently I’ve been out long enough to find a new library bundled with jQuery CDN download/source example, “jquery-migrate-1.2.x.min.js.”  What is this?!  I guess I haven’t been paying attention! Things have changed pretty dramatically in jQuery since 1.9, so much so that old code may/will break.  Here are two of things I think will cause me trouble from their upgrade guide:

See them all at http://jquery.com/upgrade-guide/1.9/ Another good thing to note, when you’re using the migrate plugin.  The uncompressed version (the one without .min in the filename) will send console log data if it comes across old code.  So if you’re wanting to be a forward-thinker, download the uncompressed jquery-migrate-1.2.x.js file and then run your pages.  Watch the javascript console for warnings, then correct them whenever possible.  Sounds like the 1.9+ direction is here to stay!  (Duh, they are already on 1.10, and 2.0.3…) Yep.  The 1.9 announcement was in January if that gives you any indication of how long it’s been since I’ve done much with jQ.   Happy Coding 🙂

PHPStorm’s Integrated Editing Capabilities: Setting up CSS-X-Fire

In my last post (moments ago!) I went through the install and setup for PHPStorm’s LiveEdit plugin.  That plugin works well for Chrome, but I find that another plugin will work handy with Firefox+Firebug: CSS-X-Fire.

You know the drill: you’re making CSS changes in Firebug because it’s blazing fast.  You have to pay attention though, because the changes you make will be lost on refresh.  Not only that, but you will have to type them back into your CSS file.  One can only imagine how difficult that can get when you’re modifying someone else’s CSS–you know the one, with 14 CSS files and in four directories?  Wouldn’t it be nice to save those right back into the file, straight from Firebug?!?! Now you can! </infomercial-speak>

CSS-X-Fire

This plugin is a community developed jar file that you can drop into most IntelliJ IDEs.  I’m using PHPStorm (www.jetbrains.com/phpstorm/).  Once you install it, you are prompted to install a Firefox extension xpi file, which links the two together.  I’m still just trying it out, but it looks like CSS-X-Fire is intelligent: it supports some media query features, and recognized SASS and LESS variables when modifying your CSS files. Let’s walk through the install.

1. Download the CSS-X-Fire package

Get it here: http://plugins.jetbrains.com/plugin/5348?pr=phpStorm

Project Home: https://github.com/ronniekk/css-x-fire

Documentation, however, is here: https://code.google.com/p/css-x-fire/wiki/Installation

2. Drop the jar file into your PHPStorm’s plugin folder

css-x-fire-folder

(You may have to restart PHPStorm)

css-x-fire-restart

3. Install the XPI for Firefox

When PHPStorm came back up, it prompted me to install the Firefox extension (xpi) file.

css-x-fire-xpi-install

Don’t worry, if you miss it, you can click the CSS-X-Fire button in PHPStorm to bring up the about.html page again.

css-x-fire-help

4. Make changes to your HTML using Firebug

I found that it was best when I created an external style sheet first with definitions, and linked it to HTML.  When I was editing elements without defined CSS rules, it wasn’t quite as clean.

css-x-fire-working

5. Bring the changes into your CSS files

Now that you’ve modified your CSS using Firebug, go back to PHPStorm.  Open up the CSS-X-Fire window.  Here you can see that I’ve made a few changes in the style.css file, and the plugin is ready to bring them in.  Click “Apply all changes” and you’re done!

css-x-fire-change-window

The CSS-X-Fire window shows the incoming changes, which you can choose to allow or remove from the changelist. Try double clicking the change to see where it comes from in the CSS before it takes effect.

Notes about CSS-X-Fire

This was just a simple example, but I’m looking forward toward seeing more of its features — especially SASS/LESS integration, and media query features.

css-x-fire-config

I hope this is enough to get you interested in trying it out.  Share experiences in the comments!

Happy Coding!

 

PHPStorm’s Integrated Editing Capabilities: Setting up LiveEdit

I’ve come across two nifty plugins with our new office editor, PHPStorm.  The first is LiveEdit, which allows us to have Dreamweaver-like previews running in a native Chrome window.  The second I just installed tonight, CSS-X-Fire, which allows CSS edits from Firebug (Firefox or Firebug-lite in Chrome) to be brought back into the actual CSS file.  Read more about that on my next post here.

LiveEdit

LiveEdit is a built-in plugin from JetBrains that connects the PHPStorm editor to a Chrome tab.  When you edit text in your HTML or CSS document, chrome updates automatically.  No more CTRL+S-ALT+TAB-CTRL+R key combos. This works great for two monitors, too!

1. First Step, install the LiveEdit plugin.

Go to the File…Settings menu in PHPStorm.  Search for the “Plugins” section.  Click “Install JetBrains plugin…”.  That should open up the list of plugins which aren’t installed yet, but can be.  I’ve compressed the steps into one screenshot here.

liveedit-install-plugin

When you find the LiveEdit plugin, double-click to install it.  You will have to confirm the install and restart PHPStorm.

liveedit-install-restart-phpstorm

2. After it is installed, and PHPStorm restarts, enable the LiveEdit plugin

Open up the File…Settings menu again.  Find the LiveEdit section and just make sure it is enabled.  When I installed the plugin, it was enabled by default.

liveedit-install-enable

3. Next, install the Chrome plugin

PHPStorm will probably complain at you if the plugin is not installed by now.

liveedit-install-chrome-plugin

Note: I recently updated PHPStorm to version 6.0.2.  In order to get the plugin to recognize PHPStorm again, I had to uninstall the Chrome Plugin, and then re-install it.

You can find the Chrome plugin at this URL: https://chrome.google.com/webstore/detail/jetbrains-ide-support/hmhgeddbohgjknpmjagkdomcpobmllji

4. Confirm it is installed and working

When you preview your web page in Chrome coming from PHPStorm, with LiveEdit enabled, the editor and browser will start talking to each other.  The JB icon in Chrome will be colored in (not greyed out), and the web page will highlight as you mouse over HTML in the editor. Just like developer tools!

liveedit-install-verify-chrome

liveedit-install-working

More Notes about LiveEdit in PHPStorm

You may be asking yourself, does this only work for static HTML files?  No.  I was able to get LiveEdit to work with PHP files as long as I had my server configuration correct.  As soon as PHPStorm was asked to preview the page using my localhost URL, the LiveEdit feature synced up right away.

This may not work out of the box if you are using an MVC framework or mod_rewrite rules.  Be sure to set up your path mappings correctly.  I can’t say that I have, but I imagine it will work OK if you do.

If you ever lose your way, you can always head back up to the View… menu and enable or disable the LiveEdit feature.  You can also re-send the page to the browser from there.

liveedit-install-view-menu-live-edit

 

Next up: the CSS-X-Fire plugin.