Skip navigation

Tag Archives: friday fix

Friday Fix: console.log does not work in IE

I encountered a rather obscure IE bug at work this week. After coding up a series of text inputs that enable/disable other radio buttons based on their values, I was dismayed to find out my javascript code wasn’t working in a test environment. I opened Internet Explorer’s F12 Developer Tools to check for any errors.  Unfortunately, the javascript console was useless; nothing was there! No errors, no warnings, nothing. Maybe the console hadn’t recorded an error because it wasn’t open at the time or something, I thought. So I entered another value and found that the javascript was all of a sudden activated! The radio buttons were disabled appropriately and the console was displaying my console.log statements. I was confused. I attempted several other scenarios and variations of input, attempting to lock down what exactly was causing my code to become active. No luck. Fortunately, a colleague of mine had experienced this exact problem before and let me know how to fix it.

Simply remove the console.log lines.

Did you know that console.log does not work in IE unless you have the F12 Dev Tools open?! I sure as hell didn’t. And not only doesn’t work, it breaks other javascript on the page too.

Here is a stackoverflow link that explains the issue in more detail.

So I learned my lesson here, be certain that all javascript debug statements are removed from my code before delivering it.

Friday Fix: WordPress code tag with a bad character

Inside WordPress’s WYSIWYG editor, if you start a line of text, inside a code tag with a bad character, in my case, the ‘#’ character, the output gets screwed up. Here’s how to fix it.

If anyone looked at my previous post in the first week or two after I posted it, you may have noticed how ugly the post was when it came to the displaying my console’s output. This is because I put the console’s output inside a <code> tag in the WordPress WYSIWYG editor. My intent was to differentiate my blog post text from the output of the console I was using as an example. However, after wrapping the console output in the tag, this is what it looked like:

Code Tag with Incorrect Output

 

I have successfully used the <code> tag in WordPress before to stylize blocks of text, so that’s what I was using here to represent the console output. I didn’t have any trouble in any previous posts, so I wasn’t sure what was different this time. After experimenting a bit, I found that the “#” character that begins each line was the culprit.

code tag with a bad character at the start of each line

 

The fix was simple, I added a space before each line.

Code tag with a bad character, but prepended with spaces

 

This small change gave the output the desired effect.

Code output with corrrect formatting

 

Squashing commits in git

My first open source contribution was just accepted! (Technically, it’s my 2nd contribution, but 1st accepted one!) It was a very minor change, just an update to the user’s profile page on GitLab. Nevertheless, it’s a great feeling, knowing that I can directly improve a great product that I actually use. And I gained a bit of git experience because of this as well.

simple git history

So pretty!

Before I get to what I broke and how I fixed it, I feel the need to defend my self a little first. I like seeing the pretty, flowy lines that are used to track the commits of a project in git. However, the entirety of my git experience has been as a solo developer. As such, I have noticed that every time I merged my feature branch into master, there was no fork reflected in the history (using git log --oneline --decorate --graph). Just a boring-ass straight line. So, purely for aesthetics and not at all efficient or appropriate, I found a way I could get this fork & branch history to show in my logs. I performed my merges with no fast-forwards (git merge --no-ff). This creates an additional commit that mentions the two branches that are merged together, but achieved the effect I was looking for.

So fast-forward (HA!) to today. I followed my usual, ignorant workflow for my submission to the Gitlab project. I forked their repo, cloned locally, branched, made changes, merged with no-ff back to master, and pushed back to origin. From here, I made a merge request for my change to the official GitLab Community Edition project. An admin wrote back that I needed to squash my two commit messages into one. Blerg, I should have known that this practice would eventually bite me! I spent the next few hours unsuccessfully trying to figure this out on my own. After responding to the admin the next day, that I was still working on this, he wrote back with a very helpful link.
So, to squash my pointless commit that --no-ff generated, I had to rebase back to the commit before my first commit. I did this, in interactive mode (git rebase -i <hash of commit>). This opens a text editor with the history of commits between the latest commit and the one that was selected for rebase. In my case, saw my commit, and the autogenerated commit. From the text editor that appears, I can then select what happens with each commit.

# Rebase 408a140..5d5af41 onto 408a140
#
# Commands:
# p, pick = use commit
# r, reword = use commit, but edit the commit message
# e, edit = use commit, but stop for amending
# s, squash = use commit, but meld into previous commit
# f, fixup = like "squash", but discard this commit's log message
# x, exec = run command (the rest of the line) using shell
#
# These lines can be re-ordered; they are executed from top to bottom.
#
# If you remove a line here THAT COMMIT WILL BE LOST.
#
# However, if you remove everything, the rebase will be aborted.
#
# Note that empty commits are commented out

My case was simple. I chose fixup for the superfluous commit and pick for my commit. After saving these changes, the rebase occurred. Everything is fine now, right?
Nope, my dumbass pushed the change to the remote repo already, so I had to overwrite that master branch with my new master branch. A normal git push wouldn’t do it because my local and remote repos were out of sync. Some kind of fast-forward error. So I just forced my changes to overwrite my remote master branch.

git push --force

Ha ha ha Force Push!

git push --force origin master

This force push added my revised master branch to my remote and let me successfully merge my change into the GitLab source! Awesome! Proof positive that you don’t have to be some sort of programming genius to be able to contribute. I don’t even know Ruby!

Friday Fix: Fix dll issue with Vagrant on Nvidia hardware

I discovered Vagrant earlier this week and have become immediately smitten. As I bounce around from my PC to my laptop to my work laptop, I have a lot of dev environments to manage. Vagrant manages all of that business for me now!
The TL;DR of this post is that you need to be sure you are running the most recent version of VirtualBox. Version 4.3.16 as of this post. I was running version 4.3.14 and still had trouble.

I have a Dell Latitude with the usual integrated Intel graphics w/ additional Nvidia or AMD graphics card configuration. In my case, it’s an Nvidia card. I have it docked in a replicator and outputting to 2 monitors and the laptop screen.
Vagrant is supposed to make managing VMs super-easy, so I was a bit confused as to why I couldn’t even boot a vanilla Ubuntu/trusty64 vm. From a DOS prompt, my “vagrant up” would yield:

...everything looks good...
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
The guest machine entered an invalid state while waiting for it
to boot. Valid states are 'starting, running'. The machine is in the
'poweroff' state. Please verify everything is configured
properly and try again.

If the provider you're using has a GUI that comes with it,
it is often helpful to open that and watch the machine, since the
GUI often has more helpful error messages than Vagrant can retrieve.
For example, if you're using VirtualBox, run vagrant up while the
VirtualBox GUI is open.

The error says to try it again with the VirtualBox GUI open, so I do that. But as soon as I open VirtualBox, I get a popup with another error.
VirtualBox.exe - Bad Image
C:\Program Files\NVIDIA Corporation\CoProcManager\detoured.dll is either not designed to run on Windows or it contains an error. Try installing the program again using the original installation media or contact your system administrator or the software vendor for support.

With some quick DuckDuckGo-fu, I find a VirtualBox ticket detailing exactly my issue, specifically comment #3. The last comment has the solution, just update to the newest version of VirtualBox. Just be forewarned, if you are lazy like me, you will try the “Check for Updates” feature inside VirtualBox and find that you are supposedly running the most recent version. But this feature doesn’t take into account tiny sub-dot releases. You will have to go directly to the VirtualBox website to download the latest.

After version 4.3.16 was installed, both issues disappeared. The Nvidia dll error upon opening VirtualBox as well as the command-line issue that was preventing vagrant from starting my VM.

Friday Fix: Android keyboard not working

I have a Samsung Epic 4G. A really old-ass Android phone. Fortunately for me, Android is an open platform and a very talented pool of hackers and coders have created a vibrant non-commercial ecosystem.

Case in point, I am running Android 4.1.2 (Jelly Bean) on a phone that Samsung never intended to get past Android 2.3 (Gingerbread). The features this opened up to me (running apps that previously were blocked, Google cards, enhance system customizability, etc)  made the phone feel as though it were brand new!

Now, to clarify, I am running the very popular cyanogenmod ROM. Currently running version 10. I could go into a whole other blog post about the bluetooth and memory issues I experienced in CM 10.1, but I just want to get to the fix I needed to get CM10 running smoothly.

I immediately started experiencing issues with the software keyboard after I loaded the gapps package for CM10. I was continually getting the error message, “Unfortunately, Android keyboard (AOSP) has stopped working”  popping up everytime I tapped on something that needed text input. This practically made the phone unusable. Fortunately, the Epic has a hardware keyboard and I was able to find a workaround.

First, you will need to download some alternative keyboard app. I had purchased SwiftKey a while ago when it was on sale, so I just added that to my phone again. I imagine that you can install your keyboard app of choice.

Select Menu (hardware key) -> System Settings – > “Language & input”

language & input

Select Language & input

Select SwiftKey or whatever keyboard app you downloaded

Select alternative keyboard app

Select SwiftKey or other keyboard app

Notice that the Android keyboard (AOSP) can’t be unchecked. This is a problem. Even though the SwiftKey keyboard now appears whenever a keyboard is needed, the Android keyboard is still being opened too. The error message is still appearing. This can be fixed by disabling the Android keyboard app.

In order to do this:

From the Home screen:

Select Menu (hardware key) -> Manage Apps

Swipe all the way to the right until “ALL” app list is displayed, and navigate to the list until “Android keyboard (AOSP)” is displayed

Navigate to Android keyboard (AOSP)

Navigate to Android keyboard (AOSP)

Select the Android keyboard to bring up its properties. Then select ‘Disable’.

Disable Android Keyboard (AOSP)

Disable Android Keyboard (AOSP)

This will deactivate the keyboard and thus, Android won’t continue to try to open the broken keyboard.

I haven’t had a keyboard error message since I have done this.

Friday Fix: Credit score

Just a quick teaser post for today’s Friday Fix. It is of a personal nature as well.

About two or so weeks ago, I began looking for a house. What should be a fun and exciting life event, has been marred by the incredibly frustrating and stressful process of trying to get a loan. I am going to do a proper write-up on my situation shortly and the challenges involved. But in the mean time, I want to point out that not having a credit score, even if you have no other debt or delinquent payments, is a huge deterrent to getting a home loan. Without a credit score, a person is automatically deemed a high risk individual until proven otherwise (via manual underwriting).

Friday Fix: My first open source contribution

Hey everybody, kind of an exciting Friday Fix this week. I just submitted my first pull request to an open source project!

First, a little back story. A short while ago I noticed a discussion on Twitter, that spread to github, regarding the name of a particular javascript testing library named Testacular. I believe that it was meant to be a play on the work ‘spectacular’, but it doesn’t take a huge leap to notice that it is one vowel away from the word ‘testicular’. A very valid argument was made that by naming the library in such a way, the project’s author was potentially alienating women and thus undercutting the project’s adoptability. After a semi-heated debate on the project’s github issue tracker, the name of the tool was changed to ‘Karma’. Fast forward to this week, and I’m checking out AngularJS to see what the buzz is about. In checking out the tutorials page, I see a reference and link to the Testacular framework for testing. Knowing that this information is no longer accurate, I click the “Improve this doc” button, modified the references to Testacular, created a pull request, and submitted! As of the writing of this post, the change isn’t on the site. But it does look like it passed testing and will be merged into master at some point.

It is an odd feeling, the level of accomplishment I experienced for having done something so simple. But I guess that’s the nature of open source. So many individuals providing contributions, both large and small, all striving toward a common goal. Everyone wants to improve the project, and anyone can contribute. And now, in a very tiny way, I have helped make the open source community a little bit better.

Friday Fix: Liferay’s SASS parser on CentOS 6

In working with a Liferay theme recently, I came across a curious bug involving jRuby and CentOS 6. It manifested itself in a rather confusing SASS parser error (the details of which I don’t have anymore). To add to this confusion, I had just switched from using the traditional Ant-based Liferay plugins build to using the Maven liferay-theme-archetype. After spending almost two days trying to figure out what was going wrong with my project, and a lot of help from our NetOps genius, I stumbled across the answer. It was a library problem that existed only on Liferay systems running on CentOS 6.

Fortunately the fix is simple, as it’s just a property override.

Add the following lines to your portal-ext.properties file and bounce your server. Everything should be ready for deployment after that.

scripting.jruby.load.paths=
classpath:/META-INF/jruby.home/lib/ruby/site_ruby/1.8,
classpath:/META-INF/jruby.home/lib/ruby/site_ruby/shared,
classpath:/META-INF/jruby.home/lib/ruby/1.8,
classpath:/gems/chunky_png-1.2.1/lib,
classpath:/gems/compass-0.11.5/lib,
classpath:/gems/fssm-0.2.7/lib,
classpath:/gems/sass-3.1.7/lib

%d bloggers like this: