Independence for Content and Layout - Moving away from blogger

Perhaps it's about time. Move on. Try something different. The way I write and need to publish content changed in the past years. Most of the time, I write either in plain text, Markdown or more recently in Asciidoc. I believe plain text, or slightly enhanced plain text formats, represent a much easier solution to deal with on different platforms. Easy for versioning.

I consider content to be fluid. It must fit different formats to represent it properly. This brings me to the next wish: having a modern, easy to maintain design for my blog. I struggle with the template system and the way templates are organized in blogger. Making changes to the layout feels restricting and complex. There are a couple of instructions out there to tweak the hell out of blogger and bend it to your will. But it all seems like tweaks to me. Blogger works for a lot of cases and people out of the box. In my case, I want to experiment freely and make adjustments to my blog. Without the experience of being slowed down by the system. Blogger represents still a great way for people to get started with blogging. Minimal investment and solid foundation. I Believe, that I grew out of this whole system over time. I feel like I want more space, more breathing room.

In the next couple of weeks, I will move to a different space. I haven't made a decision yet. There are a lot of cool static site generators that I'd like to explore. When I made a decision, you will be notified.
I'll keep all the old content here. Nothing is about to go, but there won't be many new posts in the future.

Sometimes, you want to say good bye to say hello.

Call me! PythonJS and variadic functions

I’m currently developing UI automation tests for Adobe Experience Design, aka Adobe XD. Or, for anybody who hasn’t heard of the recent name change: Project Comet!

Combine and attach different material 

1. This is a note to myself. Mostly

Today, I got stuck in something that looked pretty straight forward to me. I wanted to call a function in a Python API from my JavaScript code. We use PythonJS to make this magic happen. In the most cases, calling a function in the Python API is not a big deal. Scalar values work well, named arguments work well, but variadic function args do not.
The function I wanted to call looks like this:

def menuItem(self, *args)

Calling the function from JavaScript, I tried several things. The most promising for me was to convert the JavaScript arguments into an Array and pass it on.

pythonObj.menuItem(['value1', 'value2', 'value3'])

The result was an error, telling me that I should call the function with a string or int. Okay, the function signature accept either one or multiple `int`s or `string`s. In various combinations.
I guess, my initial approach was a bit too naive. A JavaScript array doesn’t translate to a vararg in Python. Got it! But how do I pass the list of varargs from JavaScript to Python? I tried to apply the arguments from the JavaScript function to obj.menuItem. But this didn’t work with the same error.
I tried to call the Python function by

obj.menuItem("value1", "value2", "value3")

That worked well. But I can’t make this happen from the JavaScript side? How can I split up an unknown number of arguments and pass them all as single arguments? I had no answer for that.

2. Workaround, Hack, you name it

If I would have a fixed number of arguments, the solution would be easier. I ended up with a hacky solution (IMHO), since I didn’t wanted to spent more time on this interesting but blocking issue.

function callPythonFunction(args) { switch (args.length) { case 1: { return app.menuItem(args[0]); } case 2: { return app.menuItem(args[0], args[1]); } case 3: { return app.menuItem(args[0], args[1], args[2]); } default: console.error("Unsupported amount of arguments for args", args.length); } }

Is this a good solution? Until I find something better, I consider it as a good solution.

3. Summary

Bridging languages and make up for missing or non transferrable features requires creative solutions. They might not be the best solutions, but they unblock and let you move on.

What do you think? Is there a better way of doing this? Let me know in the comments.

Thanks for reading!

DxO One - Ein Erfahrungsbericht

Schon als die interessante Ansteck-Kamera im Frühjahr 2015 angekündigt wurde, hab ich ein Auge auf sie geworfen. Da die Kamera aber nur für den Anschluss an iPhones hergestellt wird, hatte sich die Sache nach Durchsicht der technischen Daten dann aber auch schon erledigt. Ich hatte zu diesem Zeitpunkt kein iPhone. Lediglich ein iPad, aber ich halte nicht so viel davon, mit meinem riesigen iPad durch die Gegend zu laufen und Bilder zu machen.

1. TL;DR

1.1. Kaufen? Ja, Nein, Weiss nicht

1.1.1. Pros

• Bildqualität ist sehr gut
  
• Selfie Mode (für alle die es brauchen)
  
• minimales Gewicht, handlich, passt in jede Tasche
  
• mit der Kamera App lässt alles aus der Kamera rausholen
  
• Akku lädt sehr schnell wieder auf
  

1.1.2. Cons

• Batterie hat eine kurze Lebenszeit (und kann nicht gewechselt werden)
  
• Braucht beim speichern von Super RAW Bildern extrem lange
  
• neigt zu überhitzen
  
• der Lightning Connector macht für mich keinen robusten Eindruck
  

2. Jetzt aber

Mitte 2015 ist die Kamera dann für den Preis von $599 hier auf den Markt gekommen. Der Preisschock ging nach kurzer Zeit wieder weg, aber die Frage blieb: warum ist die Kamera genauso teuer wie ein iPhone oder wie eine gute handliche Kompaktkamera? Und diese Kamera macht definitiv nur mit einem iPhone Sinn, weil sie nur ein winziges Display zur Anzeige von Statusinformationen hat. Also ohne iPhone praktisch unbrauchbar. Ein iPad mit Lightning Anschluss würde auch funktionieren. Aber wie gesagt, bin ich kein großer Freund davon.

Im Februar 2016 hatte dann ein Händler die Kamera für $350 im Angebot. Das war dann der Moment. Ja, ich konnte nicht mehr widerstehen und hab die Kamera gekauft. Ja, ja, ein neues Spielzeug in der Sammlung.

3. Die Kamera

Ist sehr handlich und die Elektronik befindet sich in einem Aluminium Gehäuse. Eine Plastikklappe verdeckt den SD Karten Slot und den USB Anschluss. An der Seite des Gehäuses ist der Lighting Connector angebracht. Er wird einfach eingeklappt. Mehr Anschlüsse hat die Kamera auch nicht

4. Die iPhone/iPad App

Um die Kamera überhaupt bedienen zu können, muß die kostenlose iPhone App installiert werden. Die App kann vom iTunes Store installiert werden. Die App bietet alle Einstellmöglichkeiten die man von einer Kamera her kennt. Es gibt einen Auto Mode, verschiedene Szenenprogramme und die üblichen manuellen Modi (P, A, S, M). Blende und Belichtungszeit kann eingestellt werden. Der Fokus Mode kann aus der App heraus geändert werden. Die App dient auch dazu die Bilder von der Kamera auf das iPhone zu kopieren. Auf dem iPhone kann man sie dann weiter bearbeiten oder direkt von dort im Internet verteilen.

iPhone App - Camera Modi

iPhone App - Sucher und Einstellmöglichkeiten

5. Die Verbindung

Die Kamera wird über einen ausfahrbaren Lightning Connector an das iPhone angeschlossen. Der Anschluss klappt nur aus, wenn man den Objektivschutz ganz nach unten schiebt. Damit wird die Kamera eingeschaltet und der Lightning Connector fährt aus dem Gehäuse heraus.

Der LIghtning Connector zum Anschluss ans iPhone

6. Sensor

Die kleine Kamera hat einen nicht ganz so kleinen Sensor. Im Gehäuse steckt ein 20MP 1 Inch Sensor. Das gleiche Kaliber wie in einer guten handlichen Kompaktkamera. Leider habe ich nicht herausbekommen, ob der Sensor eine Eigenentwicklung ist, oder von einem anderen Hersteller lizensiert wurde. Macht aber auch nicht wirklich einen Unterschied. Ich wollte hier ohnehin nicht die Sensoren vergleichen.

7. Geschwindigkeit

Die Kamera legt ein gutes Tempo an den Tag. Fokussieren (vornehmlich mit dem Finger auf dem Display des iPhones) und dann den Auslöser betätigen. Die Bilder werden schnell gespeichert. Es sollte auf jeden Fall nicht an der SD Karte gespart werden (die übrigens nicht im Liederumfang enthalten ist). Mit einer schnellen SD Karte ist die Kamera schnell wieder einsatzbereit.

8. Bild Qualität

Die Bilder sind gut bis sehr gut. Auf jeden Fall besser als die mit dem iPhone erstellten Bilder. Aber das sollte mich auch nicht wirklich wundern. Die Kamera kann Bilder als JPEG und RAW und Super RAW speichern (dazu unten mehr). Ich fotografiere generell in RAW, um bei der Nachbearbeitung die meisten Möglichkeiten für die Korrekturen zur Verfügung zu haben.

9. Super RAW

Hoppla, was ist das denn? Besser als RAW? Ich wusste ja nur, das es unkomprimiertes RAW gibt, aber Super RAW. Okay, und was ist es nun? Die Kamera macht 4 Aufnahmen kurz hintereinander und diese 4 Aufnahmen werden in eine Datei geschrieben. Zum importieren muss man dann DxO Connect bemühen (siehe unten). Das ist eine zusätzliche Software, die man erst downloaden kann, nachdem man die Kamera registriert hat. Leider funktioniert die Registrierung der Kamera nur aus der iPhone App heraus. Beim Import mit DxO Connect (siehe unten), werden die Bilder dann mittels verschiedener Algorithmen zusammengeführt (das Rauschen wird stark minimiert) und so ein besseres Bild erzeugt. Das resultierende Bild liegt dann als optimierte JPEG Datei vor. Das Rauschen ist im JPEG definitiv geringer als in der orignalen RAW Datei. Aber ich weiß nicht, ob das diese riesigen Files Super RAW Files das Ergebnis rechtfertigen. Aber okay, irgendein merkwürdiges Verkaufsargument darf eben nicht fehlen.

Das Rauschen im JPEG ist auf jeden Fall geringer als in der Super RAW Ausgangsdatei

Auf jeden Fall sorgt der Super RAW Modus dafür, dass die Kamera ziemlich lange braucht um die Daten auf die Karte zu schreiben. Das ist auch nicht besonders überraschend, da die 4 fache Datenmenge gespeichert werden muß. Und ein RAW Bild ist so um die 40 MB groß! Die DXO Datei ist satte 160 MB groß.

Ich habe es mehrere male erlebt, dass die Kamera im Super RAW Modus ziemlich warm geworden ist. Ich habe nur einmal die Hitze Warnmeldung im Display der Kamera gesehen. Andere Benutzer scheinen damit mehr Erfahrung gemacht zu haben.

10. Firmware Updates

Das letzte Firmwareupdate hat der Kamera einen "Retro-Mode" verschafft. Was ist das? Das kleine Monochrome Display kann jetzt als Sucher benutzt werden, wenn die Kamera nicht an das iPhone angeschlossen ist. Damit kann man dann ohne das iPhone mit der Kamera Bilder machen (hätte man vorher auch schon machen können, wäre aber ein kompletter Blindflug gewesen). Das geht so als Notfall-Lösung durch. Richtig was sehen, kann man auf dem kleinen Display nicht. Nur Schwarz/Weiß und viel zu geringe Auflösung. Aber man sieht zumindest in welche Richtung die Kamera blickt.

Das kleine Display

11. Software

Eigentlich braucht man die zusätzliche Software nicht um die Bilder von der Kamera zu bekommen. Wenn man aber Bilder im Super RAW Format gemacht hat, dann sollte man DxO Connect auf jeden Fall installieren. Denn nur damit kann man den Super RAW Bildern die ganzen Informationen entlocken. Ansonsten können die Bilder auch direkt von der angeschlossenen Kamera oder der SD-Karte in Lightroom oder Apples Photos importiert werden.

12. Testbilder

Closeup

Farben

Abend

Langzeitbelichtung

Closeup

Licht und Schatten

Sonnenschein

Kunstlicht

Tageslicht

Sonnenschein

5 npm script secrets

No Secret

Last week I was hosting a workshop about Electron Shell, ES6 and Reactjs at ForwardJS in San Francisco. Preparing all the sample code, I was inspired by this blog post to avoid any build tool like grunt or gulp at all. In fact, I wanted to remove anything that could distract the attendees of the workshop by throwing another unknown toolset at them. Instead, leveraging the build in capabilities of npm.

The Idea

Why use grunt, gulp, etc. if you can leverage the power of npm scripts? Not having to maintain a build script is a good idea and helps to remove another piece of complexity from your project.

Secrets

Different types of scripts

npm supports custom scripts defined by scripts property of package.json. npm distinguishes between 2 different kind of scripts

• lifecycle scripts

• directly-run scripts

Lifecycle scripts tie into a specific phase of your project lifecycle, like install, publish, start, stop, etc. These scripts can be executed with npm lifecycle-script. Each lifecycle script can have a pre and post script for that phase, e.g. preinstall and postinstall.

The directly-run scripts need the extra run command after npm, e.g. npm run *my-script-name*. Your directly-run scripts can have a pre and post step with the same name as your script name, e.g. premy-script-name and *postmy-script-name. Always without space between the prefix and the script name.

You can read more about it in the official docs.

Call your own scripts always with npm run <script-name>.

Platform differences

Sometimes you need to do things differenly when it comes to build your project on multiple platforms. I ran into the issue, where I needed to copy files. On OSX this is as simple as cp srcfile.txt destfile.txt. On Windows, this didn’t work, since cp is an unknown command, unless you have cygwin installed. Building your project in the default Windows command prompt fails with an error, once you want to copy those important files. On Windows you should use copy instead.

Create an external copy.js file and do the OS specific tasks there. You can use process.platform === 'win32' to determine if you are running Windows.

DRY - refer to anything defined in your package.json

DRY (don’t repeat yourself) is a great principle when it comes to software development. You can even refer to anything defined in your package.json when you execute your script. Let’s assume, you want to create a zip for distribution.

"scripts": {
    "create-zip": "zip -r app-1.0.zip dist"
}

Now you can call npm run create-zip to create a zip containing all the files to distribute your app.

But why can’t we just refer to the name of the app and the version already defined in package.json? Well, we can. npm exposes all config keys from package.json in the form npm_package_configkey for you to use in your scripts.

"scripts": {
    "create-zip": "zip -r $npm_package_name-$npm_package_version.zip $npm_package_distdir"
}

Stay DRY! Refer to information already available in package.json. You can define whatever config option in package.json and refer to it in the same way.

Call any script in another script

What if you want to run more than one script at the same time? You want for example watch *.js files and *.scss files and preprocess them? How can you do this with one npm script?

You can concatenate different scripts and run them all at the same time:

"scripts": {
    "sass-watch": "node-sass -watch src/style.scss dest/style.css",
    "babel-watch": "babel -w *.js dist",
    "watch": "npm run sass-watch & npm run babel-watch" // 
}

npm run watch will call both custom scripts and run them at the same time. This will create two processes that run independently from each other.

Concatenate multiple scripts with & to run them as one script.

Run any script in your node_modules/.bin directory

Installing any node module that adds it’s own executable script, will be available from projectDir/node_modules/.bin. Let’s say, you need babel for your project and you installed it with npm install babel-cli --save-dev, you can run babel from within your project directory by typing ./node_modules/.bin/babel. That is great, since you don’t have to rely on a global installation of babel.

If you want to run babel as part of a script, you would probably specify the whole path to the babel script:

"scripts": {
    "babel-watch": "./node_modules/.bin/babel -w *.js dist"
}

Since npm adds all executable script to the PATH for the script, you can instead write

"scripts": {
    "babel-watch": "babel -w *.js dist"
}

Don’t specify the full path to a script in your projects node_modules/.bin folder. Use the command without the path.

Thank you very much for reading. If you have any comments or questions, please leave them in the comments below.

Einmal Tennessee und zurück

"Put on my blue suede shoesAnd I boarded the planeTouched down in the land of the Delta BluesIn the middle of the pouring rain"

Chattanooga

Diese Zeilen aus dem Song "Walking in Memphis" von Marc Cohn, hatte ich im Kopf, als ich letzten Donnerstag mit dem Flugzeug in Chattanooga gelandet bin. Wow, wo bin ich hier gelandet? Alles irgendwie anders, langsamer, aber spannend und interessant. Chattanooga ist eine Kleinstadt, die wirtschaftlich stark gelitten hat, als die großen Industriebetriebe ihre Türen geschlossen haben. Viele gutbezahlte Arbeitskräfte haben ihren Job verloren und zu einer hohen Arbeitslosenquote geführt. Mehr als 20 Jahre hat die Stadt gebraucht, um sich von diesem wirtschaftlichen Untergang zu erholen. Heute hat Chattanooga den Tourismus für sich entdeckt. Ansonsten finden eine ganze Menge Sportveranstaltungen in Chattanooga statt. Die größte Veranstaltung ist ein Ironman.

Chattanooga Airport

Die orangenen Laufschuhe

Statt Lederschuhen hatte ich meine Laufschuhe an.

Downtown Chattanooga

Coco Cola in Chattanooga

Ein paar weise Worte.

Market Street Bridge über den Tennessee River

Sonnenuntergang am Tennessee River

Leider auch hier: Bausünden

"Kleine Kuchenauswahl" in einem lokalem Cafe

Ich war hier angekommen um an einer, ich möchte mal vorsichtig sagen, verrückten Veranstaltung teilzunehmen: ein Staffellauf von Chattanooga nach Nashville. Distanz ca. 200 Meilen (ungefähr 320 km). Teams haben entweder 12 oder 6 Läufer. Gelaufen wird die ganze Zeit. Egal wie spät es ist. Ankunft aller Läufer in Nashville ca. 24-30 Stunden später.
Mein Team bestand aus 12 Läufern und jeder von uns ist 3 mal in dieser Zeit gelaufen. Die zu laufende Distanz pro Läufer variierte zwischen 3 und 10 Meilen.

Jedes Team hat 2 Vans mit jeweils 6 Läufern. Ich war in Van 1 unseres Teams und der letzte Läufer der 6er Gruppe.
Ich bin das erste mal am Freitag um 14:30h unterwegs gewesen. 3.1 Meilen in der prallen Mittagssonne. Nicht meine Lieblingsbedingungen zum Laufen. Aber was solls. Immerhin hatte ich eine relativ flache und kurze Strecke zu absolvieren.

Mein nächster Einsatz war dann erst Nachts um 23:30h. Kurze und flache Strecke mit 2.7 Meilen Länge. Der letzte Lauf war dann am nächsten Tag um 9:00h. Diesmal 4.5 Meilen und mit ziemlich vielen Anstiegen. Immerhin war die Temperatur angenehm zum laufen.
Danach war ich aber auch froh, dass ich nicht nochmal Laufen musste.

Nach dem letzten Lauf. Fertig, aber glücklich.

Jo, genau das richtige nach dem Laufen: Zucker, Mehl und Fett in Kreisform. Auch als Donut bekannt.

Zieleinlauf in Nashville bei bedecktem Himmel

Lea und ich warten mit den anderen auf die Ankunft unserer 6 Läufer aus Van Nr. 2

Sehr coole Idee: alle unsere Medaillen ergeben zusammen eine grosse Medaille

Abendessen mit dem gesamten Team nach fast 30 Stunden

Die ganze Veranstaltung war sehr gut organisiert. Viele Helfer bei den Übergabestellen. Für die längeren Pausen wurden immer Schulen hergerichtet und die Turnhallen zu Schlafplätzen umfunktioniert. Auch in den Schulen waren sehr viele Helfer unterwegs. Sei es nun, um das Chaos auf den Parkplätzen zu koordinieren oder aber um Essen und Getränke in der Schulkantine zu verkaufen.

Drei Dinge sind mir aufgefallen, als ich in Tennessee war:

1. Hier läuft die Zeit langsamer! Im Vergleich zur Bay Area, wo sich alles schnell bewegt, ist in Tennessee alles ein paar Takte langsamer. Aber das war sehr entspannend, obwohl die Wartezeit in Restaurants manchmal schon als grenzwertig lang zu bezeichnen war.
2. Die Menschen sind hier sehr freundlich. Jemand hat mir gesagt, dass das die Southern Hospitality ist. Aufgesetzt und hinter der Fassade sieht es anders aus. Ich hab mich dort aber sehr wohlgefühlt und die Interaktion mit den Menschen war ausgesprochen nett.
3. Es mangelt hier nicht an Kirchen!!!

Nashville ist cool!

Wirklich? Ja, ich finde schon. Die Stadt hat ein paar schöne Ecken. Für Unterhaltung ist auf dem Broadway gesorgt. Bars und Restaurants mit Live Musik. Country Musik ist nicht jedermanns Sache, aber es passt alles zusammen hier. Die Menschen haben Spass und die Stimmung war überall toll. Es gibt noch ein Football und ein Eishockey Team. Beide Teams haben ihre Stadien in Laufweite vom Broadway. Rundherum um den Broadway gibt es eine ganze Menge Geschäfte zum Einkaufen (Cowboy Hut und Stiefel gefällig?). Des Weiteren sind noch eine Menge Museen vorhanden. Allen voran die Country Music Hall of Fame. Leider war die Hall of Fame am Sonntag geschlossen und wir sind ins Johnny Cash Museum gegangen. Sehr interessant und in einer Stunde gut zu schaffen.

Der hippste und teuerste Coffeeshop in Nashville

Noch eine kurze Anekdote zum oben abgebildeten Coffeeshop: ich wollte für mein Team Kaffee besorgen, da wir vor dem Restaurant auf unser Frühstück etwas länger warten mussten (Ansage was 30 Minuten). Ich bin also schnell um die Ecke gegangen, hab dort ein paar Kaffee geordert und wollte dann schnell wieder zurück sein, damit die anderen ihren Kaffee trinken konnten solange sie in der Schlange draussen warten mussten. Nach 20 Minuten bekam ich eine Nachricht von meinem Team. Die Frage nach dem Kaffee musste ich verneinen und meine Bestellung hab ich per SMS übermittelt. Leider hatte ich nach 20 Minuten immer noch keinen Kaffee in der Hand. Kurz darauf hab ich den Kaffee bekommen und bin schnell wieder zurück zum Frühstückslokal. Schmunzelnde Gesichter bei meiner Ankunft. Der Kaffee war gut und teuer (Cappucino $5,50, Ice Cafe Latte $7,50) und hat ewig gedauert. Wie ich eingangs schon mal erwähnte: alles läuft hier langsamer als anderswo. Lektion gelernt.

Und zurück in die Bay Area

Die Kolumne in der New York Times heißt  "36 Stunden in xxx" (xxx=nimm irgendeine Stadt auf der Welt). Leider hatte ich weniger als 36 Stunden in Nashville. Ich hab ein bisschen was gesehen von der Stadt. Aber es gibt noch soviel andere Dinge zu entdecken, die ich mir für einen zukünftigen Besuch gemerkt habe. Also, bis bald mal wieder in Nashville. Dann mit etwas mehr Zeit.

Install ownCloud on Synology NAS DS413

Here is a list of steps required to install ownCloud on a Synology NAS. I have a DS413 and I was able to install ownCloud on it. I don't know about the other Synology models out there. Let me know, if you succeeded to install ownCloud on any other model.

ownCloud is not part of the official Synology packet repository. You need to add the community repository to install packets from there.

1. Log into the Synology admin site
2. Open Package Center and open the Settings. Under Package Sources, add http://packages.synocommunity.com/ as a source (see screenshot). Click Ok to confirm the new repository.
3. 
4. In Package Center, refresh the list of available packets by pressing the Refresh button at the top of the window
5. Now search for MariaDB and install it. This is required to install Owncloud. Otherwise, the installation of ownCloud will abort with an error. MariaDB is a fork of MySQL and is one of two databases recommended by ownCloud. The other one is PostgreSQL.
6. Next enable Web Station in the Control Panel. ownCloud is a webapp and needs the http server to properly work.
7. 
8. Before we continue with the ownCloud installation, you need to create a new shared folder. The installation of ownCloud failed in the beginning, because this folder is required, but could not be created.
9. Open the Control Panel and open Shared Folder. Create a new shared folder and give it the name ownCloud (this is the default during the ownCloud installation).
10. 
11. Check off Hide this shared folder in "My Network Places". Nobody should modify any content in this directory. This belongs to the ownCloud installation!
12. Change the permissions of the newly created shared folder. In order to grant ownCloud read/write permissions, select http from the Local Groups (in the Dropdown list on the left hand side above the table) and check the box in the Read/Write column. Press the OK button when done.
13. 
14. Now search for ownCloud and install it.
15. During the installation of ownCloud, you will be asked to enter the password for the root user. Leave this field empty. By default there root password is not set (this is not secure at all, but for demo purposes, this should be alright)
16. After ownCloud was installed properly, click on the URL in the ownCloud overview page in the Package Center. In my case it's http://192.168.1.22/owncloud.
17. 
18. Now you will be greeted with ownCloud's login page. Type in your admin password and log into your ownCloud installation. The administration is part of another blog post.

Summary

This is a list of steps to install ownCloud on a Synology NAS DS413. The steps cover the installation of dependencies required to run ownCloud. The administration of ownCloud is not part of this post.

I hope this will help anyone to successfully install ownCloud. Let me know if you have any questions or other constructive feedback.

What I've learnt today

Here is a list of things I have learnt today. Things to remember for myself and to reflect on.

1. AppCode has a simple, yet very useful CocoaPods integration. Easily create a podfile and fill in your dependencies. AppCode will provide you with a button to install your dependencies. Bonus: if you remove a dependency from your podfile, AppCode will give the uninstall button. Keeps your project directory neat and tidy. You can do this on the command line too, but it fits perfectly into the IDE.
2. Swift playground in XCode 7.0.1 on El Capitan 10.11 sucks! I had so many crashes in the playground, that I had to restart XCode several times to get it back working.
3. Swift and Objective-C seem to have a "Love and Hate" relationship? Why, you might ask? I tried to use some library that was written in Objective-C with my Swift project. It took a good amount of work to navigate around those little compile errors and find alternative ways to use the library anyways. But it was painful and not fun at all. What I did? I created a custom XML deserializer for Alamofire with Ono.

1st Electron-Shell User Group Meetup

I went to the 1st Bay Area Electron-Shell User Group Meetup last Tuesday, 8/25/2016. The meetup was hosted by (WagonHQ) in San Francisco’s Mission district. It started at 6pm and was scheduled to last until 9pm. The nice folks at WagonHQ provided some food and drinks for all attendees.

The Agenda for this meetup is available (here).

There was a good crowd of interested engineers (between 40 and 60 people). Some of them were already using electron-shell in one or the other project.

The Talks

There were 4 tech talks for this event:

• The History of Electron (Kevin Sawicki - Engineer at GitHub)
  
• Integrating with Native Code (Paul Betts - Engineer at Slack)
  
• Electron, React, and Haskell. Oh my! (Mike Craig - CTO at Wagon)
  
• Making a web app feel native (Ben Gotow - Engineer at Nylas)
  

The talks covered different parts of app development and the specialities of building a cross platform desktop app with web technolgy. A lot of questions around styling, using node modules, write your own node modules, call C# APIs to integrate with Windows, call Objective-C to integrate better with OSX and app packaging (I might have missed something).

I’m looking forward to attend the next meetup. I think that some attendees might have tried electron-shell for their own projects and have some eperiences to share.