Skip to content
October 21, 2014 / mb

change single column collation in MySQL with ALTER TABLE

Ok, I may be a little rusty with SQL, but this took me surprisingly long to figure out.

If you want to change the collation for a single column in one of your tables, the correct syntax is

ALTER TABLE myTable 
MODIFY myColumn VARCHAR(width) CHARACTER SET charset COLLATE collation;

so for example, if you want to set your ‘id’ column in your ‘users’ table to accept case-sensitive ascii strings of length <= 10 characters, you would execute:

ALTER TABLE users
MODIFY id VARCHAR(10) CHARACTER SET ascii COLLATE ascii_bin;

Yes, it's easy, but I guess I was relying on google a bit too much this time (I could only find how to modify tables and databases, and many answers about columns in stackoverflow are just.. wrong!)

July 24, 2014 / mb

sudo asks for password even if NOPASSWD is set in /etc/sudoers

TL;DR when a script is not marked as executable and you try to run it with sudo, you don’t get the usual -bash: myScript.sh: Permission denied message, you are prompted for a password instead!

This one was very frustrating.

What I wanted to do was to make a user (let’s call him bran) able to execute a specific script (let’s call it /home/hodor/calm_down.sh) without having to provide his password, because the script will be executed by an automated tool (Jenkins).

I reached back to my earlier post about sudo, and updated the /etc/sudoers file so that its User privilege specification section looked like this:

root    ALL=(ALL) ALL
bran    ALL=(hodor)  NOPASSWD:  /home/hodor/calm_down.sh *

The last line gives user bran the ability to run /home/hodor/calm_down.sh as user hodor passing it any number of parameters (*) without having to provide his password (NOPASSWD:).

Saved it, su‘ed into bran, ran

bran@laketower:~$ sudo -u hodor /home/hodor/calm_down.sh "it's ok"

aaaaand…

[sudo] password for hodor: 

d’oh.

I checked the syntax in /etc/sudoers, and it was ok.

I checked whether any of the declarations that followed in /etc/sudoers could override the line I set for bran and hodor, none to be found.

Heck, I even put that line as the last line, so no line could override it. Nothing.

After a good hour of googling around and finding nothing, I remembered that the script is in a Git repository for which I just checked out a different branch. As it turned out, the script lost its executable bit.

So I set the executable bit again, as user hodor:

hodor@laketower:~$ chmod +x calm_down.sh
hodor@laketower:~$ logout
root@laketower:~# su - bran
bran@laketower:~$ sudo -u hodor /home/hodor/calm_down.sh "it's ok"
hodor.
bran@laketower:~$

it worked!

I’m sure there’s a legitimate security concern for this behavior, but dang! was this hard to figure out!

July 23, 2014 / mb

ForkedBooter steals window focus on Mac OS while Maven is running

This is about running Maven, specifically.

For most Java applications, any of the solutions from this question on StackOverflow should work.

It’s a matter of passing -Djava.awt.headless=true to the Java process, which can be done for all Java processes by saving that option to a variable named JAVA_TOOL_OPTIONS in your .bashrc.

That’s fine as long as you have direct control over the Java process, which is not the case with Maven.

In my case, it was the Failsafe Maven Plugin that caused that annoyance, but some were experiencing the same behavior with an old version of Surefire. The following snippet fixes both.

In your pom.xml, change your existing <plugin> definitions so that they look like this (the important lines are highlighted):

<!-- this is inside your <project><build><plugins> block -->
<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-surefire-plugin</artifactId>
    <version>${maven.surefire.plugin.version}</version>
    <configuration>
      <includes>
        <include>**/unit/**/*Test*.java</include>
      </includes>
      <!-- prevent the annoying ForkedBooter process from stealing 
        window focus on Mac OS -->
      <argLine>-Djava.awt.headless=true</argLine>
    </configuration>
  </plugin>
  <plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-failsafe-plugin</artifactId>
    <version>${maven.failsafe.plugin.version}</version>
    <configuration>
      <!-- prevent the annoying ForkedBooter process from stealing 
        window focus on Mac OS -->
      <argLine>-Djava.awt.headless=true</argLine>
      <includes>
        <include>**/integration/**/*Test*</include>
      </includes>
    </configuration>
    <executions>
      <execution>
        <goals>
          <goal>integration-test</goal>
          <goal>verify</goal>
        </goals>
      </execution>
    </executions>
  </plugin>

Done!

I added this reply to stack exchange as well, but maybe this post will be easier to find (as that question already already had an accepted answer when I replied, and it doesn’t work for Maven). We’ll see!

May 25, 2014 / mb

Fix out of sync subtitles with Python!

This is an update of my old post from a couple of years ago.

After using that script quite a few times, and loving it, I decided to give it a facelift and add the one feature that I’ve been wishing it had for all this time: the option to just tell it the timestamp of the first dialog without performing any math :)

Yeah, it’s simple math, but having to use base 60 means more brain CPU time wasted (and above all, it means more time separating me from my movie!).

I also moved the code to GitHub, so you can find it here: SubSlider. And this is the direct link to the python script, for the impatient.

The old way of specifying offsets using +/- has been replaced my a more argparse-standard system of flags. Also, the new feature I mentioned above can be used by running the script like this:

python subslider.py -s 1:23,450 MySubFile.srt

assuming your subtitles file is called MySubFile.srt and assuming that the first dialog in the movie takes place at 1:23,450. This time, there’s an “interactive” dialog that asks you to choose the first line among the first 10 lines in the .srt file. I added it because sometimes you get the equivalent of opening titles in the .srt, and that doesn’t help when you’re synchronizing.

If you want to get a different number of lines, you can simply change the LINES_TO_SHOW variable at line 43 to whatever number you prefer.

As always, feel free to contribute :)

April 12, 2014 / mb

Another wallpaper changer for Gnome and Unity

The previous wallpaper changer that I wrote in Python served me well for the last 2 years, but sometimes it would get stuck with some wallpapers: of the 200 pictures I have in my wallpapers folder (mostly taken from the paper wall), some were definitely being shown more often than others. Has the script developed a taste? Probably! :)

So this time I decided to put together something very quick, but that does a better job at never showing the same picture twice before all pictures in the folder have been set as desktop background.

It comes as a single bash script, there’s no configuration file to set, it picks pictures from a single folder (whereas the Python version could use several), and it moves files to a folder called shown when setting them as desktop background. Not very elegant, but it gets the job done!

Here it is; you can set your wallpapers folder and the refresh interval at the highlighted lines.

#!/bin/bash
#
# WallpaperChanger.sh
# Copyright 2014 Michele Bonazza michele@michelebonazza.com
#
# A simple script to automatically change your wallpaper in Gnome.
#
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
#
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
# GNU General Public License for more details.
#
# You should have received a copy of the GNU General Public License
# along with this program.  If not, see <http://www.gnu.org/licenses/>.

WALLPAPERS_FOLDER=/home/path/to/your/wallpapers
REFRESH_INTERVAL=$((5 * 60)) # change every 5 minutes
MODE="zoom" # one between none, centered, wallpaper, scaled, stretched, zoom, spanned

# Changes the desktop background, and moves it to the "shown" folder so that it's
# not shown again before all wallpapers in the folder have been used.
# arg1 the file name of the file to be set as new background; must be in the
#      current folder
function change_wallpaper() {
  mv $1 shown
  gsettings set org.gnome.desktop.background picture-uri file://$WALLPAPERS_FOLDER/shown/$1
  gsettings set org.gnome.desktop.background picture-options $MODE
}

# Echoes the next wallpaper to be set, picked at random among images in the
# configured folder
function get_next_wallpaper() {
  find . -maxdepth 1 -type f -name "*.png" -o -name "*.jpg" -o -name "*.gif" -o -name "*.jpeg"| shuf -n 1
}

mkdir -p $WALLPAPERS_FOLDER/shown
cd $WALLPAPERS_FOLDER

while true; do
  NEXT_WP=$(get_next_wallpaper)
  
  # have we used all wallpapers?
  if [[ "$NEXT_WP" == "" ]]; then
    # yes, chdir to shown, and move them all back to the parent folder
    cd shown
    # move them to parent folder
    find . -maxdepth 1 -type f -name "*.png" -o -name "*.jpg" -o -name "*.gif" -o -name "*.jpeg" | xargs mv -t ..
    cd ..

    # check again
    NEXT_WP=$(get_next_wallpaper)

    if [[ "$NEXT_WP" == "" ]]; then
      echo "no wallpapers found in $WALLPAPERS_FOLDER, will check again in $REFRESH_INTERVAL seconds..."
      sleep $REFRESH_INTERVAL
      continue
    fi
  fi
  
  echo "changing background to $NEXT_WP"
  change_wallpaper $NEXT_WP
  sleep $REFRESH_INTERVAL
done

As always, I’ve also added this to my pastebin.

Save it as wallpaper_changer.sh, make it executable

chmod +x wallpaper_changer.sh

and add it to your “Startup applications” list, which can be found in Ubuntu’s main menu (the one you use to log out/shut down the computer), or can be brought up from a terminal using

gnome-session-properties

Click “Add”, use whatever name you want and browse to the wallpaper_changer.sh script (wherever you’ve saved it).

Sometimes I found that “Startup applications” doesn’t work: make sure that after having added your script and closed the window you can see an entry called wallpaper_changer.sh.desktop in the output of

ls -l ~/.config/autostart

If it’s not there, remove the entry and try again (I know, I know. The alternative is to fiddle with Upstart or init.d so if you want a GUI, that’s better than nothing!)

You can also change the effect to apply to your wallpapers at line 23 in the script.

Enjoy your new desktops! :)

March 11, 2014 / mb

How long does it take for the Google Play Store to publish my app in beta?

Your mileage may vary, but it shouldn’t take significantly longer than a couple of hours. If you’re not too unlucky, it should probably take just one hour, both when you’re publishing an app for the first time, and when you’re releasing an update for an existing app.

If it’s taking significantly longer than that (I’m talking more than one day here), you may have been fooled by Google’s peculiar requirements for deployments.

This fooled me twice (so I guess, shame on me).

When you publish an app for the first time, you need to create a Google Group or a Google+ community for testers before the link to your app becomes available. If you try to access the link (even using your own Google account) without being a member of the configured group/community, you’re greeted with a 404 page.

Last time I published an app though, setting an existing Google Group for testers (one that I had configured for a different app) didn’t seem to work. When I created a new Community on Google+, it worked right away. I don’t know if I was just unlucky or if you need a dedicated Google Group for every app, but if you still get a 404 after setting up the Google Group, just try with Google+.

After you’ve become a tester for the app (by visiting your app’s page on the Play Store) it usually takes another hour or so before the APK becomes available for download.

March 8, 2014 / mb

Eclipse freezes after installing LUA development tools plugin

This was an interesting one, but surprisingly very easy to solve.

After installing the LUA tools as a plugin, Eclipse mysteriously stopped working: what happened was, I would launch Eclipse from a shortcut (I’m using Docky in Ubuntu 13.04, but as it turns out, this is irrelevant), it would show me a LUA development tools splash screen (weird), then the Eclipse workbench… and stop there.

I went on to launch Eclipse from the command line to see what was going on and… I discovered that somehow the eclipse binary had been swapped with another one called LuaDevelopmentTools. Funny thing was, the latter was actually the original eclipse binary. Also, eclipse.ini had been renamed to LuaDevelopmentTools.ini.

Solution:

cd /path/to/eclipse/install/folder
mv eclipse eclipse.bak
mv LuaDevelopmentTools eclipse
mv LuaDevelopmentTools.ini eclipse.ini
mv eclipse.back LuaDevelopmentTools

restarted from the launcher, everything works.

Follow

Get every new post delivered to your Inbox.

Join 52 other followers