Over the past weekend I had some time to explore new tech. I found Flutter and watched couple of presentations and keynotes and it grabbed my attention right away.
In my current company I lead a mobile project using Xamarin Forms, targeting Android and iOS. I always think about how to boost productivity and performance of the application and at the same time maintain an acceptable level of standards and maintainability. Having that said, I’m not personally involved with the coding a lot and I mostly observe the development.
After years of being actively working with Xamarin I realized that if I want to depend only on the built in controls I cannot get very far from just a prototype. In order to have a production level polished app I need to spend lots of time developing custom controls. You are still sharing the same code base in terms of logic and the main flow of the app and it’s all great but it takes time and effort to make an app look great.
Flutter in the other hand is different. It’s based on Dart (which is new to me) and has a very expressive way of working with the UI. Soon after my second video I found my self typing flutter create hello-world. I followed couple of the online tutorials and managed to put a smooth working app together in a very short time. Then I couldn’t stop there and I created a new project to try out form fields and see if I can put a page together on my own. One hour later I had a login screen with icon-text-fields, validations, hints, moving labels, tap screen to dismiss keyboard and even a small little snack bar with cute notifications. It looked like a production ready screen to me comparing to what I could achieve with Xamarin in the same amount of time.
Here are a few bullet listed facts regarding my first experience with Flutter and Dart.
Continue reading Flutter first impression
In the current project I’m working on, we are intensively writing unit tests with 100% code coverage following TDD.
In this post I’m going to share one of very exciting situations that I faced couple of days ago while working on a module which is supposed to initialise database on fist access.
While the first caller is waiting for the database to be initialised, the second caller needs to wait as well and do not trigger the initialise method again. After the wait is over the second caller needs to know that the database is initialised and continue the normal work.
The fact of putting the initialisation in the database client is not the centre of this post.
There are couple of ways of tackling this but IMO the best way is to actually make a race situation happen in your unit test. Some developers do this by firing an action and delaying that by putting the first thread to sleep and fire the second thread while the first thread is asleep. The biggest problem is that how long do you want to put the first thread to sleep. On different machine the process of running the unit tests in the test runner takes different time to run. So you should either introduce a very long delay (seconds) or a short one that runs on your machine but may fail on the build server.
Here is how I solved this issue:
Continue reading Unit Testing Race Situation
We use BitBucket for our source control and VSTS for CI. VSTS build definition has a trigger option which will monitor the repository every so many seconds (min is 60s) and if new changes are there it will trigger the build. But that feature only works when you have VSTS repositories and for any external repository the developer needs to login to VSTS after the changes are pushed and wait for at least 60 seconds for the build to kick off. I’m pretty sure that manually triggering the build takes less time. Also, that model by itself is not efficient specially in the world of Webhooks.
BitBucket supports Webhooks. For example you can call add Webhooks for each push (unfortunately you can not specify a branch). The problem is that VSTS CI build definition does not accept Webhooks as trigger.
In this post I’m going to show how this can be done by using BitBucket Webhooks , Azure Function Apps and VSTS REST API.
Continue reading Trigger Visual Studio Team Services (VSTS) CI Build from BitBucket
Creating extensions is one of the very useful techniques in C# that can help us extend the functionality of an existing class or library without modifying the origin. It is also aligned with the 2nd principle of SOLID programming, Open Close Principle.
In this article I will focus on creating a LINQ extension method and will point out a simple but important tip that you need to watch out for.
Continue reading Creating LINQ Extension
This week we decided to create a new isolated mission critical but dead simple and small api in order to publish our web api endpoint address to the mobile clients.
The use-case is very simple: pass platform, version and environment (dev/prod) and receive the api that you need to work with.
Why did we decide that?
This is going to help us seamlessly and gradually shift between old production environment to the new production environment.
Last week I watched a presentation about Azure Function Apps and kind of fell in love with the concept.
Because of the following advantages I knew right a way that’s the best solution for us in order to implement that single, very small and mission critical api method:
- next to nothing development time
- automatic deployment from a git repository
- use dynamic or classic app service instances
This week while starting to do the design an implementation and after some experiments I decided to go with API Apps instead, because of following reasons:
Continue reading Why did I choose Azure API App over Function App?
During 5 days of Ignite Sep 2016, Microsoft has generated weeks of presentations. I subscribed to their YouTube channel and oh boy! The list of the videos coming up was taking over any my entire subscriptions list.
Probably watching all of them is practically impossible for me but here is the list of my favorite sessions that I have watched:
Continue reading My favorite sessions from Microsoft Ignite Sep 2016
A few months ago I came to know PaintCode. PaintCode is a nice piece of application that probably will put an end to all the icon dramas that app developers have. As a programmer I find it very annoying to prepare all the different sizes and shapes of icons for different screen sizes and different platforms. What could be better than bringing the icons (and vector graphics) into your application as code?
Here, you will find a sample Xamarin iOS project which I created, as well as a little bit of discussion about a problem I faced while doing that experiment.
Continue reading Drawing icons in Xamarin using PaintCode
These days I’m on a mission to balance our server sizes in Azure with the actual usage. As part of that it’s very important to know our real RPS (Requests per Second).
When you plug your app to Azure AppInsight many valuable data will be captured and recorded. Azure itself, provides some basic queries for showing some useful charts about your usage. For example, response duration, dependency duration etc. however, there will be a time where you need to run your own specific query in order to make business related decisions. At that stage Azure AppInsight Analytics comes to play with an online query builder/editor to help you run custom queries, draw charts and extract meaningful information. Continue reading Calculating Request per Second (RPS) in Azure
Few months back I decided to change my job and become a Software Consultant. I applied for a job at Readify, one of the most well known consultant companies in Australia. I then Worked so hard on brushing up on many subjects because I knew it wasn’t going to be easy.
After a week of preparing myself and passing their online test which relatively was not so difficult, I got an interview appointment with Richard Banks. Richard is a Principal Consultant at Readify. I had the opportunity to sit at couple of his talks. Continue reading The birth of Async.Codes