Hey there! I am Christian Liebel from Leimersheim, Germany. I work as a consultant at Thinktecture and I am their representative at W3C. PWA development with Angular and .NET Core is our day-to-day business. Feel free to contact me anytime.
One of our customers at Thinktecture recently wanted to set up an auto deployment of its GitLab repository to an App Service hosted by Microsoft Azure. If you want to set up auto deployments for GitLab, you might be disappointed because this service is not included in the list of available services. Setting up auto deploy from GitLab.com or on-premises editions of GitLab is a manual process—luckily, it’s an easy one.
GitLab.com is a very popular service, as it allows free private Git repositories with up to ten gigabytes in size. If this still doesn’t suit your needs or you want to host the software yourself, GitLab also offers on-premises editions (Community Edition, free and Enterprise Edition, paid per user and year).
Microsoft Azure is a popular cloud service, offering so-called App Services (free plans available). App Services are used for hosting web apps or back-ends based on .NET, Node.js, Java, PHP and other technologies. An App Service can be set up to auto deploy changes that are pushed to a certain branch of a Git repository.
Here’s how to do it for GitLab.com or on-premises editions of GitLab:
Angular 2 is the next version of Google’s popular SPA framework. If you’re not yet familiar with it, you can find an overview here. In this article, I will focus on the dependencies of Angular 2. Whereas AngularJS (1.x) could either be run stand-alone or on top of jQuery, Angular 2 requires some third-party dependencies, which we’ll take a look at in this article:
Angular 2 is the upcoming all-new Single-Page Web Application (SPA) framework from Google. It’s the successor to the well-known AngularJS, which was first published in 2009.
Do you remember? In 2009, Windows 7 was released, which included Internet Explorer 8 as the default browser. The work on HTML5 just started. And the iPad wasn’t even on the market. Since then, the world and the web have changed a lot: Mobile internet usage surpassed desktop usage. Fully-fledged business applications are built using HTML5. And web technologies are on par with their native counterparts in terms of functionality and performance. Angular 2 wants to address these changes by being:
Note: This post was written during Angular’s beta phase. The issue is fixed in later versions of Angular 2.
Starting from Beta 1, Angular 2 applications don’t seem to run in Internet Explorer anymore—although Angular 2 officially supports Internet Explorer versions 9 to 11 and it worked like a charm in Beta 0. This is due to missing ECMAScript 2015 (ES6) shims which es6-shim doesn’t include. This can be easily solved by adding the missing shims which are buried deep in Angular’s package.
For a couple of years now, TeXstudio is my favorite IWE (Integrated Writing Environment) for LaTeX. Last year, I switched from Windows to OS X, but I didn’t take my LaTeX environment with me. Since I’m going to need LaTeX more often in the next time, I finally set it up on OS X 10.11 El Capitan. Unfortunately, this was not an easy task. And here’s why:
Installing MacTeX and TeXstudio
The most common TeX distribution on Mac is MacTeX, and this distribution is incredibly huge: MacTeX’s installation package is about 2.3 gigabytes in size. The distribution contains all important TeX binaries, Ghostscript and some GUI tools for managing packets or modifying global TeX settings. (There’s also a way smaller distribution called BasicTeX, whose package is only 109 megabytes in size. However, I haven’t tested this distribution in combination with TeXstudio.)
On Mac OS X, everything looked nice. But on Windows, the column headers were oddly shifted and did not match the content columns. While investigating the bug, we found out that the columns were shifted by exactly 17 pixels to the left. But why 17 pixels? And not 5, 10, 15 or anything power of 2?
Mono has a –server option that can radically improve the response behavior of .NET server applications when run on Mono. From mono’s man page:
–server: Configures the virtual machine to be better suited for server operations (currently, allows a heavier threadpool initialization).
However, when I tried using the server option for the first time, I was very disappointed that it didn’t work. After some time I found out that I caused the problem myself. Why? Because
mono MyApp.exe --server
is unfortunately not the same as
mono --server MyApp.exe
The latter is correct and works like a charm (on Mono 3.2.3 and higher).
Mono’s options must be placed before the file name, because otherwise the option is treated as an argument passed to the given .NET application. This is a simple, yet mean mistake, because you are used to append any parameters at the end of a command.
Conclusion: Sometimes it can be helpful to also look at the top of the man page, where it clearly states that the actual argument order is like the following:
Recently we brought a Cordova-based web app which already runs successfully on iOS and Android to Windows Phone 8.1. One of the issues you will definitely come across when porting your app to this platform is the handling of the back button, an essential part of Windows Phone’s user experience.
By default, pressing the back button on Windows Phone closes your Cordova-based app, regardless of the current state. Instead, the back button should bring you back to the previous view; except on the main page, where pressing it must suspend the current app (according to the Windows Store Policies, 10.4.4):
Where applicable, pressing the back button should take the user to a previous page/dialog. If the user presses the back button on the first page of the app, then the app terminates (unless it is allowed to run in the background).
Not respecting those policies may not only lead to a rejection of your app, but also to bad ratings in the Store.
Your customers love mobile devices and apps. And they love the way of interacting with them, using touch.
Touch is a very natural input method and multi-touch allows intuitive gestures such as pinch-to-zoom. As mobile or web developers, we also love apps and touch interaction. But, face it, we are also quite lazy. We want to run code written once to execute on several browsers and platforms resulting in one and the same behavior. Unfortunately, there are two competing methods that allow interacting with websites using touch input:
Windows Phone bietet zwei Möglichkeiten, das Aussehen von Betriebssystem und Apps anzupassen: Die Akzentfarbe und den Hintergrund. Bei letzterem kann der Benutzer zwischen dem dunklen und hellen Hintergrundschema wählen. Aber während wir Windows-Phone-Entwickler eigentlich angehalten sind, die Wahl unseres Benutzers zu berücksichtigen und bestmöglich in unseren Apps umzusetzen, so siegt schlussendlich doch die Macht der Gewohnheit: Die unserer eigenen.
Stein des Anstoßes ist das Nichtbestehen der Zertifizierung einer Windows-Phone-App wegen des hellen Hintergrundschemas, dem Light Theme. Da half es auch nichts, dass die App richtig schön aufgezogen war: Mit MVVM, grünen Tests und durchgecheckt mit der Performanceanalyse. Gemangelt hat es dann aber an der Unterstützung des Light-Theme. Problem war, dass auf einem dunklen Hintergrundbild ein Text lag. Denn die Vordergrundfarbe von Textblöcken ist im dunklen Hintergrundschema, dem Dark Theme, standardmäßig weiß – beim hellen Schema hingegen schwarz und damit auf einem dunklen Hintergrund nicht gut lesbar. Dieser Umstand ist während der kompletten Entwicklung nicht aufgefallen: Nirgends war das Light-Theme aktiv, weder im Emulator (Dark-Theme ist hier Standard) noch auf Testgeräten (Dark-Theme nach persönlichem Gusto gewählt).