How to comment in cmd.exe / Windows command line

Published 2018-11-14, 15:02

REM this is a comment

or

:: another comment

(Second one only works sometimes, see comment)

„Turn off“ output truncation of RSpec output

Published 2018-08-27, 19:16

Use this code to increase the output length before RSpec trancates output like e.g. `expected` and `got` in test failure results:

RSpec::Support::ObjectFormatter.default_instance.max_formatted_output_length = 1024

Avoid accidentally closing programs on macOS with Cmd + Q

Published 2018-08-18, 15:24

I am a predominant Windows user. But as I dabble in mobile apps, I of course also have to use a Mac now and then.

This tended to be a pretty frustrating experience, as my Windows shortcut memory always uses Alt Gr + Q to type the @ sign in email addresses – which translates to Cmd + Q on Mac and closes your current program without any additional prompts.

My solution: System Preferences –> Keyboard –> Shortcuts –> Accessibility –> Invert colors: Activate and set to Cmd + Q.

No more accidentally closed programs when typing my email address 🙂

How to install Laravel (5.6) on Uberspace (7)

Published 2018-07-16, 12:57

Laravel is a great PHP framework, and Uberspace is a great and nice PHP host. Why not mix both?

Installing Laravel on shared hosting – which Uberspace still is despite the shell access etc. – can be difficult, especially because of public folder that is used to respond to requests instead of the project root.

Here are the basic instructions for getting a new Laravel project to respond to calls of your <username>.uber.space domain:

  1. Switch folder to /var/www/virtual/<username>.
  2. composer global require "laravel/installer" to install the Laravel Installer.
  3. Create a new Laravel project: laravel new <projectname>.
  4. Delete /var/www/virtual/<username>/html (make sure it is empty, or just rename it maybe) and replace it with a symlink from html to <projectname>/public.
  5. The default Laravel start page should now be available at your <username>.uber.space.

To be able to use the database in the project, you have to make some changes:

  1. Get your generated MySQL password from ~/.my.cnf.
  2. Update the .env file in your Laravel project:
    Username and database should be changed to your username, the password to the one you just retrieved.
  3. Caution: At the time of writing Uberspaces uses MariaDB 10.1.34 (find out by using the command mysql -v). Laravel needs some tiny changes if you work with MariaDB <10.2.2:
    • Edit the app/providers/AppServiceProvider.php file and add the following: 
      use Illuminate\Support\Facades\Schema;
public function boot()
{
   Schema::defaultStringLength(191);
}

      (Add both the method call and the import!)

  4. Now you can run php artisan migrate in your Laravel project to create the default tables.

Of course you probably don’t want to host your project at your uber.space domain, not create a new project but check out your already developed project from git, and also not use the default database – but I am sure you can find your way from here.

Laravel Homestead: Run phpunit with another PHP version

Published 2018-06-22, 13:09

Laravel Homestead is a nice development environment/server, that comes with multiple PHP versions installed. You can configure each project you are running through it for its own PHP version, and use e.g. php5.6 on the command line to execute code with a specific PHP version. Unfortunately phpunit always uses the default PHP version. What if the PHPUnit you installed in a project needs a specific PHP version to work and execute your tests (for example because the whole project only works with PHP 5.6)?

You can run phpunit with a specific PHP version by using this command:

php5.6 vendor/phpunit/phpunit/phpunit

Website Performance, Code, Images and SEO Testing Tools

Published 2017-09-29, 12:48

There are loads of web site and page analyzer tools out there that look at them under performance, quality, image compression, code or SEO aspects. Many are just (thinly veiled) lead generation tools that don’t really tell the true story, but some are actually useful. As I need them again and again, I collected them here:

More on the marketing-y, rarely even questionable side, but sometimes still interesting to look at:

Visualize `git reflog` in a GUI (and put it in context) with SmartGit

Published 2017-09-28, 11:31

Recently I messed up an important git repository that I was working on. I had created some content in a specific file a few weeks ago. After multiple merges, commit squashing, git reset, rebases and other types of history rewrites  I noticed that this content was missing.

Oh-oh, seems what everybody warns you about when rewriting history happened: I lost some stuff.

But lucky for me, git never really deletes anything. Even if you do stupid things, each commit that was there before still is – just orphaned and without a connection to your normal branches.

Unlucky for me the tool to fix this is called git reflog and not supported by my usual git GUIs that I use, SourceTree and GitKraken.

I tried to use git reflog on the command line, but to be honest this didn’t help much. reflog just outputs a list of changes to the repository, and you have to sift through these manually to find the one you are looking for. There is no context which files where changed or what changes to these files were made. (Disclaimer: There probably is a way to work around this with some bash scripts – here or here for example – but I have no idea about how exactly. That’s why I normally use a GUI.) I had no idea when in the last month stuff broke, so I had no idea where to start looking.

After quite some time googling around I (re)found SmartGit.
SmartGit is also a Git GUI and calls itself „Git for Professionals.“. This means it doesn’t look as fancy as SourceTree or Gitkraken (its design reminded me of working in the Delphi IDE back in the day…), but it is indeed powerful. And most importantly, it can visualize lost commits in a way that is useful!

Funny enough this feature is only very lightly mentioned in the documentation, so here is how it works:

How to visualize lost and „orphaned“ commits with SmartGit

We are looking for the „Recyclable Commits“ branch in the „Log“ view: Open the repository in SmartGit, right click on the repository in the „Repositories“ panel,  select „Log“ in the context menu, then in the opened „Log“ view, select „Recyclable Commits“ in the „Branches“ panel additionally to the already selected branch or „HEAD“:

The light orange-dot entries (vs. the bold black-dot ones) are the „orphans“ that are not part of the current tree any more.

You can filter these down by using a „Filter“ input, which optionally can search for File name and even File content! (So I could just type the filename I knew I had put my content into, and look only through these relevant commits – and even search for a few words I knew I wrote about in the file – how awesome is that!)

Important and super useful is that these commits are shown in the context of the current tree, so you can click the individual commits and see the file changes it includes, click the files to see the diff as you normally would. So much easier than on the command line.

After you found the missing commit, either copy the text over to your editor manually or cherry pick that commit with all its changes to your current branch by right clicking on it and selecting „Cherry-Pick…“. Then commit as usual (and dance a bit as you just saved a few days of work).

How to commit and version changes in a git fork/branch but not merge them back

Published 2017-09-21, 11:38

Recently I tried to figure out how to have both a production and staging environment of a Jekyll website hosted with Github Pages.

This turned out to be not that simple, as both repositories (Github Pages can only host one branch per repository, so you need two – one organization repository and one personal for example) need to have a CNAME and _config.yml file with different content.

So the actual question to answer was how can one commit and version changes to files in a git fork/branch but then not merge them back into the source, while still having a fully merged branch (so actual changes can be merged back via Pull Requests)?

The answer is to use the ours merging strategy when merging the changes that should be skipped:

  1. Assume we have our production repo and staging repo both checked out locally, for now being identical (and having the same CNAME and _config.yml).
  2. Check out staging, make the changes to the files and commit and push them.
  3. If we were to do a normal merge to production, this change would now get merged over.
  4. But now we run these commands:
    git checkout production
    git merge --strategy=ours staging
    (Source)
    --strategy=ours makes sure that during this merge, the production file remain unchanged. But the commit is still marked as merged.
    If we want, we can now also edit the merge commit messageto be a bit more descriptive what we just did: We merged the two branches, but made it keep „our“ (in this case: production) version of the files.
  5. Then push the changes to production:
    git push production production:master

Your next changes to staging can the be merged with production normally, without getting the CNAME and _config.yml changes.

Windows 10: WLAN/Netzwerk von „Öffentliches Netzwerk“ auf „Privates Netzwerk“ umstellen

Published 2017-03-30, 13:20

Mit Windows 10 hat sich (mal wieder) geändert, wie man sein WLAN/Netzwerk von „öffentlich“ auf „privat“ umstellen kann. Das ist relevant weil die Windows Firewall zwischen diesen beiden Klassen von Verbindungen unterscheidet und manche Verbindung aus Versehen falsch kategorisiert werden kann. Also muss man es ändern. Nur wo?

Die Einstellung findet sich nun in den „Einstellungen“ (bzw. „Eigenschaften“, je nach dem wo man es findet) des jeweiligen WLANs/Netzwerkes und wird dort als „Dieser PC soll gefunden werden“ bezeichnet. Ist dieser Schalter auf „Ein“, wird die Verbindung als „privat“ gehandhabt, bei „Aus“ eben als „öffentlich“.

Logisch, oder? *augenroll

Viele weitere Möglichkeiten finden sich hier: https://www.deskmodder.de/wiki/index.php?title=Netzwerk_%C3%B6ffentlich_privat_%C3%A4ndern_Windows_10

git: How to rewrite history on commits that you already pushed to the remote/origin

Published 2017-02-14, 18:42

(Written October 2013)

Let’s phrase this another way:
How to rewrite commits that are already on Github?
Ho to clean up commits that I already synced?
How to rewrite public history on git?

As you probably know git is much more flexible with branches, commits and all that stuff than other CVSs like SVN were. Commits are done locally and more like local snapshots that still can be changed, where commits in SVN are directly on the server/repository and can’t be changed. So there are lot’s of tutorials that explain how all this works:

But the one thing all these instructions don’t tell you, is what to do when you already synced (pushed) these commits to the remote origin. We only get quotes like these:

Once you have published/pushed your work to shared repositories, we very much recommend against going through post-production with it. That is known as rewriting public history and in general requires telling everyone of your failings as a developer so that they can do the necessary work to recover on their side.

A word of caution: Only do this on commits that haven’t been pushed an external repository. If others have based work off of the commits that you’re going to delete, plenty of conflicts can occur. Just don’t rewrite your history if it’s been shared with others.

Don’t include any commit you’ve already pushed to a central server — doing so will confuse other developers by providing an alternate version of the same change.

or my favorite one from the GitHub documentation:

Warning: It is considered bad practice to rebase commits which you have already pushed to a remote repository. Doing so may invoke the wrath of the git gods.

There are good reasons for this if you work with other people.

Obviously this doesn’t help, when you want to rewrite public history. There are lots of cases where you want to do that, especially if you are the only committer to a project and there is noone else to consider.

Before you start playing around with rebase, it’s probably a good idea to make a backup of your current state to a branch:
$ git branch backup-branch
Then if something goes horribly wrong with you workign copy you can just get the old state back:
$ git reset --hard backup-branch

Then you can continue doing the rebase like it is described in one of these tutorials:

And after all that, the magic thing to do is this:
git push --force origin master

By the way, the sources I finally found for this, after fighting for several days, were these:

16 queries. 0,148 seconds.