iTunes Connect and Umlauts

04 May 2010

Apple is a american centric company, otherwise it is not explainable that you can get a lot problems if your name does not consist solely of ASCII letters. My last name - König - contains a so called umlaut: an “ö”. Everytime apple posts a new license agreement to the developers, the developer has to accept this new license agreement if he wants to continue to develope applications for the iPhone. This agreement affects also the iTunes Connect portal. The iTunes Connect portal is the place where the developer can manage his applications which he wants to put on the app store.

And here the problem begins: if the developer accepts a new agreement in the developer portal, the status of this new agreement “should” also be updated in the iTunes Connect portal. It doesn’t, if your name does contains umlauts like my last name does. The developer portal states that I have accepted the new license agreement, the iTunes Connect portal doesn’t. The consequence is, everytime apple posts a new license agreement, I have to contact the iTunes Connect support and have to wait until they set the correct bit in their database manually. This happened to me already five or six times and it is starting to get annoying as you can think.

Now I have noticed that my application in the app store has been dropped silently, because iTunes Connect thinks, I haven’t accepted the new license agreement. I don’t even know for how long the application isn’t available in the app store anymore, because apple gave me no indication that it isn’t. It is really embarrassing for a huge company like apple, that they can’t even handle encodings correctly in their developer portal and moreover they should sent out status messages to the developer if the availability of an app in the app store changes.

Update - 10 May 2010

It took Apple six days to resolve the problem. Now my application is available again in the app store. At least this has happened automatically.



16 February 2010

Tate Johnson recently created his own fork of Jekyll named tatey-jekyll. He added the support for LESS CSS and growl notifications to it. I liked the idea and merged the latest changes from Jekyll into his fork.

While I was at it, I also added the support for specifying the concrete time for a blog post in the yaml from matter. Whenever do you publish blog posts at twelve o’clock at night?

Tate liked the changes I made and we’ve agreed that we will continue to develope this fork under the name Jekylless. The name Jekylless was chosen to show the projects’ support for LESS CSS.

We both will integrate a few more features into this fork, but we’ve decided to stay as close as possible to the codebase of the original Jekyll, so that switching to our fork should be easy for every existing jekyll user.

For more information about Jekylless, checkout the readme of the project on github or install the Jekylless gem directly.


Dropzone SCP Script with Gallery Creation

21 January 2010

Dropzone is a great tool for all your drag & drop needs on a OS X system. Also cool about dropzone is, that you can extend it to your personal needs. I’ve always wanted a tiny little helper where I can drop my files onto. A gallery should automatically be created from these files and this gallery should be uploaded to my webspace afterwards. This kind of script would especially be useful if I wanted to show a friend some pictures rather quickly. I’ve never found a really good working solution for this on the web. At the end, I’ve created this dropzone script which does what I needed:

This script takes care of a few things:

You need to have ImageMagick installed, if you want to get the resizing to work. The easiest way to install it, is via MacPorts and the following terminal command:

sudo port install ImageMagick

If you don’t have ImageMagick installed, the pictures will be uploaded as is without resizing.

You can obtain the script at github or download it here.


The script resides now at the official dropzone user scripts repository, too!


LaTeX Compile Script

22 December 2009

I am dealing with a lot of LaTeX documents lately. The need to compile every tex document at least two times is really annoying. And if you also have to use bibtex, then it gets real cumbersome to compile all the appropriate files properly. Though I have written this small ruby script, which takes care of all the files and compiles them in the correct order:

#!/usr/bin/env ruby
# default values
compileCount = 3
open_latex_document = false

def outputErrorMessage
  puts "Too many parameters..."
  puts "Usage: 'rubylatex.rb anylatexfile.tex [compilecountnumber]'"
  puts "where [compilecountnumber] is a number greater than 0"

# check arguments
if ARGV.count == 1
  latexfile = ARGV[0]
elsif ARGV.count == 2 || ARGV.count == 3
  latexfile = ARGV[0]
  compileCount = ARGV[1].to_i
  # check if compileCount has a reasonable value
  if compileCount < 1 || compileCount > 5
  # open the latex document if a third parameter has been detected
  if ARGV.count == 3
    open_latex_document = true

# filename without file type extension
filebasename = File.basename("#{latexfile}", '.tex')

# compile latex file at least one time 
sout = system("pdflatex #{latexfile}")

# create bibtex files
if sout
  sout = system("bibtex "+filebasename)

# compile latex files a few times more
if sout && compileCount > 1
  (2..compileCount).each do |i|
    if sout
      sout = system("pdflatex #{latexfile}")

# cleanup
puts "#### cleaning up! ####"
system("rm -rf *.log")
system("rm -rf *.aux")
system("rm -rf *.aux.bak")
system("rm -rf *.toc")
system("rm -rf *.out")
system("rm -rf *.idx")
system("rm -rf *.blg")
system("rm -rf *.bbl")
system("rm -rf *.nlo")
system("rm -rf *.lot")
system("rm -rf *.lof")
system("rm -rf *.tcp")
system("rm -rf *.tps")
system("rm -rf *.brs")
system("rm -rf *.brf")

# pdf successfully generated
if sout
  puts "#### done! #{filebasename}.pdf is ready! ####"
  if open_latex_document
    puts "#### opening #{filebasename}.pdf now! ####"
    system("open #{filebasename}.pdf")
  # failed pdf generation
  system("rm -rf #{filebasename}.pdf")
  puts "#### failed! no pdf generated!!! ####"

The script is a little bit bloated, but it gets the job done and it even takes care of deleting all the temporary files which are created during the compiling process.


Change Terminal Colors on Remote Connections

11 December 2009

I often use ssh in order to work on remote servers. But often it is hard to tell at first sight, if a open terminal window displays the contents of remote connection or if it is a local one. Therefore it would be nice, if the terminal would automatically switch colors, when a remote connection is detected. On Stack Overflow I found a solution for on OS X, which I adapted and improved a little bit:

HOSTNAME=`echo $@ | sed s/.*@//`

# define background colors
BLACK_BG="{0, 0, 0, 50000}"
GREY_BG="{10000, 10000, 10000, 50000}"
RED_BG="{10000, 0, 0, 50000}"

# define font colors
GREEN="{0, 65535, 0}"
LIGHT_GREY="{55000, 55000, 55000}"

set_bg () {
  osascript -e
  "tell application \"Terminal\" to set background color of window 1 to $1
   tell application \"Terminal\" to set normal text color of window 1 to $2"

on_exit () {
  # set colors back to normal when quitting the remote connection
  set_bg "$BLACK_BG" "$GREEN"
trap on_exit EXIT

case $HOSTNAME in
  # you can set your production server in your .bash_profile file
  # like so: export production1=""
  $production1|$production2|$production3) set_bg "$RED_BG" "$LIGHT_GREY";;
  *) set_bg "$GREY_BG" "$LIGHT_GREY" ;;

/usr/bin/ssh "$@"

I’ve put this script into my ~/bin/ folder, which is the first place where my scripts are looked up. So don’t forget to add this folder to your $PATH. Everytime a remote connection with ssh is started, this script is first called, changes the colors of the terminal and issues the real ssh command.

« older entries