I remember when (Accelerated Mobile Pages) first came out, and it was very restrictive and weird. I think this ultimately hurt the AMP Brand Beyond this, several companies have built AMP experiences which haven't always been the best experience. I do however think AMP pages always load extremely fast. A lot of that is just the constraints of AMP. Last night I put my blog posts on AMP for a laugh, and it was much easier than I thought it would be.
Turborepo is a tool that came across my virtual desk recently. Monorepo develoment has been around for a long time. This is a strategy where all of your code remains in one repository regardless of services. A lot of people use monorepo's even for microservices. The huge upside is to keep everything in one place, which allows for development efficiency, such as grepping an entire codebase for specific keywords. A quick example would be a top level directory which has child directories that each contain an npm package, unlike publishing these packages, you access them locally as though they were published.
I've been getting back into building scrappy little web apps for my friends. On top of this, I recently joined a startup and getting away from Enterprise class software has made me make a huge mind-shift. In the recent past when I wanted to build apps I was thinking Kubernetes, Helm Charts, etc. However, in small app, and startup land reducing the barriers to ship is very important.
I've been working at CarGurus.com for the last 2 years or so. One of the biggest journeys we've been undertaking is to take accessibility far more seriously. However with an engineering team way into the triple digits it gets harder and harder to scale accessibility knowledge.
So I'm currently sitting on a plane at the moment. A recent project I started on was a travel guide where I live. Being on a plane without wifi for a long time is a quick wakeup to me how much I rely on the internet to code.
When Visual studio 2015 launched, I wrote a blog post titled Resharper without Resharper. This was clearly aimed at giving people the ability in 2015 to divorce themselves from the very expensive product. In writing the post however, I didn't realize people would just want a low down on cool vs2015 extensions.
Today marks the release of Visual Studio 2017, and with it the final release of the tools for dotnet core. This means as of today you can build, test, and deploy an application completely supported by microsoft. Not just the runtimes, but the tooling as well. The CLI for dotnet core has been finalized, and its awesome. The csproj system has been revitalized. New csproj's can be created, and are fully compatible with the old. Visual studio 2017 has finally released. This is probably the greatest version of visual studio ever created. Finally VS has gone from a slow, archaic editor, to a fast moving IDE. An IDE with a DevOps-First Cloud-First mentality. An IDE ready to tackle today's modern challenges.
Growing up I always wanted to work with electronics, and as soon as I could work I was working with a computer. I currently work as a Software Engineer at Vistaprint. I work on the Gallery team, which is an agile development team that works on our platform to display products in a gallery (hence the name). Before I joined the gallery team, I spent most of my career doing ops things.
I have used Linode for quite a long time now. My blog was hosted on linode, as was my StarBound server. My linode was the CentOS Pet I always wanted. Full of manual Fail2Ban configs, I make sure I fed my VPS every day. I even used cowsay to give me a cool message from my pet every login.
The major reason I moved my things away from Linode, was not the devops story itself. I could have stuck with linode, and used chef or something to manage my former friend. I decided to host everything in Azure Web apps. Now before I give you my long ramblings why I like azure; I must tell you. I put everything in azure, because my MSDN gave me free credits. There was no huge scientific analysis behind this. The simple fact that I got free money in Azure was the only reason why I started using it.
Where I work .NET rules supreme. Personally I really don't care that much about the technology so long as it supports really good workflows. One of my major issues with nuget is that is very opinionated.
Up until the last few years the only devices on the market were all full operating system work horses. However the majority of us would easily sacrifice functionality for portability. This statement has been backed up by the increase of market demand for tablets and ultrabooks over the years.
To install on CentOS follow these instructions.
Well verdict is in boys, and girls. Personally, I thought the platform needs to mature more. For those people who can pay for the business edition ($1000 USD/developer), and really prefer c#; then go for it. For most of us that can either do c# or Java; you may want to stick with Java.
C# vs. Java for Android
If Xamarin provided more in the way of automation tools, and documentation; it would be the clear winner
The fact is going straight to Java for most people is probably a must. Even if you are more comfortable with c#, finding help on the internet is much easier. As the platform matures, and more features are added hopefully things will change.
License cost deterrent
One of my biggest gripes with Xamarin is the very inflexible license schemes. You can get by with the $300 indie edition, but it is pretty clear they want people to go the $1000 business edition route.
The biggest deterrent to the Xamarin platform is the high cost of licensing.
With no sliding scale prices based on organization size, or project scope Xamarin is a tough sell (especially for open source projects).
Xamarin, does provide a student discount. They give 90% off for enterprise edition, and for those of you whom go to school this is almost a must buy. You could probably make it back with this simple formula.
Flappy bird-like animal + Mario pipes + admob = $$$
Personally I like Xamarin platform. The ability to re-use code for multiple mobile platforms can be helpful. For most of us tinkerers out there Android Studio is probably enough. For serious businesses, with a major focus on c#; Xamarin is probably the prefered method of development.
Room for improvement
Before I can fully back Xamarin I'd like to see better componants that provide more mobile platform abstraction, increased automation tools (visual studio macros could help here), and better documentation. From the activity of there web pages, I suspect all of these things are coming.
This will be a series of blog entries where I discuss the Xamarin platform for Android.
When I heard about Xamarin I naturally, wanted to give it a shot. Having tried Eclipse, and Android Studio for android development I was no idiot when it came to the platform. So I got a license, and did nothing with it for six months, until a few weeks ago. After only 3 days I created Ultimate Gravatar Sync. An app that sync's your contacts gravatar images to their picture in your phone.
C# with no compromise
The Xamarin platform uses mono, and some kind of voodoo bindings to the Java libraries to make it work. I wont go in depth, but the native features of the C# language are there to use. I never felt like my hands had been tied, that all of a sudden I couldn't use a library that is normally part of the GAC (Global Assembly Cache). When I needed multi-threading, System.Threading was there, and when I needed to use C# Generics I had no issues implementing them.
Manage Android Manifest files
One of the things that blew me away about the platform, was that I never had to add anything to my manifest file. For those of you whom don't know, Android requires an XML config detailing the permissions you require, and the classes you have in your application.
Simple decoration such as:
[Activity(Label = "Label", MainLauncher = true, Icon = "@drawable/Icon")]
Will Generate in your manifest file as:
<pre> <activity android:label="Label" android:name=".logoActivity" > <intent-filter> <action android:name="android.intent.action.MAIN" /> <category android:name="android.intent.category.LAUNCHER" /> </intent-filter> </activity> </pre>
Adding permissions is also easy:
Using Java Libraries
Xamarin provides some kind of crazy visual studio project, that will essentially provide c# bindings to Java libraries you require. To bind Simply create a Java Binding project, adding the .Jar files, and then build. Watch the magic happen. They do note that you sometimes need to do some configuration for certain libraries, however I had no issues with the one I tried. On top of that if you really needed to, you could access the Java Native Interface for even more power.