Easier pretty emails for your web and mobile apps.

tldr; Use mailchimp automation emails

A little background

We build web and mobile apps built with Angular frontends and firebase backends.

These micro-service architecture apps are a great idea — till you have to do something that needs a server. Things that need to use API keys for example. A simple feature that falls in this bucket is sending an email at an event.

The firebase ecosystem’ answer to that is firebase cloud functions.

A cloud function trigger starts an on demand Node.js function that has the email content related code, sent out through a third party email provider like sendgrid, mailgun or postmark app.

This means that we have to code out the email HTMLs to pass it through the cloud function to the transactional email provider.

Enter mailchimp.

What we do now is when the the cloud function trigger is to update the list field for a mailchimp subscriber. 
Mailchimp has email automations — which can be triggered on list field changes. The email can now be created much easily — from mailchimp’s own beautiful templates even. A lot of the email look and feel challenges are solved.

The cons.

• Mailchimp automations for some reason only send out one email per user per automation workflow email. So if you’re testing the app — there’s no way to trigger the emails again for the same user. Deleting the list subscribers doesn’t work. Since each automation workflow email has it’s own list of subscribers — which you cannot delete — even with the remove subscribers from workflow option. I’m hoping this is just a mailchimp bug.
• Mailchimp automation triggers for list field exist for “list field value changes to a specific value”. This works for simpler cases — like if a user upgraded. But not for complex situations where we need to send the user a specific value. To counter this we create two list field values.
• Automation list field trigger times don’t have granular controls. It’s either immediately or after an hour. We have a third party voucher code management service to update the user’s referral coupon codes to a subscriber’s list field as well — and this happens at varying times — from between instantly to two minutes later — after a user has been added to the list. To counter this we’ve had to use segments — which also surprisingly have the “not black” qualifier — to do what the trigger should have done — send voucher emails to people who have something in the voucher list fields.

The Pros

• This is still less time than spending time designing HTML emails. That work in all devices. And testing them.
• Mailchimp is an easy to use web app — so the job of “making” the emails can be handed over to the design or content or any other team. That’s time saved using things that are built already.
• There’s something about using well designed apps that brightens my day.

I’ve personally been a Mailchimp fan for a long time. I’m glad to have found a way to do less work while getting more done.

What we learnt while doing remote angular builds.

TLDR; It makes deploying angular apps a consistent experience.

What is a build — in terms of frontend apps?

We use Angular to make frontend applications. The Angular build process is — ng build which creates js bundles of all the code that drives the web app. Angular 4 has ahead of time compiling that takes the code written and makes a build that has a lot of best practices like tree shaking and transpiling for serving web applications.

Why we do remote builds?

So that everyone in our team can deploy code to the staging and production environments. Well, maybe not anyone. But it makes it easy for the project maintainer to focus on writing and maintaining the code.

Build processes are faster too — since they’re on machines dedicated to just doing that one thing. And consistent. It’s easy for everyone to go through logs in case something fails. It also lets us manage code reviews online. Once a pull request is merged after reviewing it — possibly using the web interface.

We currently don’t do automated tests — but when we do, those can be easily shoehorned into this deploy process.

What we use

We’ve had a great experience with Beanstalk from the wildbit team. We tried Deploybot and since we have a paid plan for Beanstalk — Wildbit was kind enough to give us a free Deploybot account 🎉

What we learnt

• Caching the container that the build is made in decreases build time. While obvious, it took us some time to figure this one out. Deploybot — under advanced settings has an option to for preparation of the container (like installing dependencies) and the building of the source code itself.
  Cached build commands are executed only once and then the results are cached for you, until the package.json file changes.

Creating builds and deploying that build go hand in hand.

• Firebase tools has a login for CI which generates a token that can be passed along while doing a remote build which allows us to use firebase hosting. This gives us an inexpensive way to use CDN backed hosting. Firebase hosting has a one-click rollback option to the serve the previously deployed build in case of a buggy build. That has saved our bacon more than once.
• To combat failed production builds we sometimes create a production build locally and bug fix before using the automated system again. We do this mostly before a big feature release.
• We usually have the npm modules defined as the latest ones in our package.json. This would sometimes cause build errors. To counter that we added an ng -v to the build script. This gives clear logs on what version modules were used during the remote build.
• Using environment variables is a good idea to keep production variables away from the dev environment. Adding the output-hashing=all flag worked well as the cache buster for non prod builds.
• We would also have random issues regarding firebase not being able to understand which project was associated.
  Adding the — project flag sorted those issues out.

The result of all this:
No one spends time deploying anymore.
Well not most of the time

The struggle needs to be real

I started intermediate level weights at the gym today — it was legs day today. My trainer wanted me to use enough weights — so that I would not be able to do 15 reps of one set. That’s quite tough.

I want my life to be easy. I don’t want to be in pain. I don’t want to be stretched too thin. Maybe I’m just getting old.

But doing a lot of weights is tough only for a little while. And then your body gets used to it. I did squats with 30 kgs on me — which I would have not thought possible some time back.

A story is no fun if there’s no conflict. What’s the point of watching a story where everyone is comfortably living their lives. What’s the fun in living a life with no journey.

Bojack Horseman has a great scene where a Hollywood agent gets this amazing pep talk.

Like they always said. No pain No gain.

An easy frontend trick to test Angular2 apps on multiple devices

While building an MVP mobile app — it’s a great idea to build out a mobile site first. This gives you an opportunity to lock down on the details of the product before you build out an app.

We use Angular 2 to build out the web app. The same web app can then be packaged into a hybrid mobile app using cordova.

One of the tricks we use to test out things quickly is check the web app on a mobile browser at the same time.

To do this easily we use

ng serve --host=<local IP address>

Then we use at least a couple of mobile browsers pointed at the local IP (after making sure that they’re on the same network). So when you save the file it refreshes not just the desktop but the mobile browsers as well.

This works especially well when using flex — which is a beautiful way to get CSS to work on multiple screens.

Hey Prasad, Actually we do use firebase for all the Google services mentioned — except for notifications. We started using One Signal before Firebase cloud functions was released and just stuck to it.

Why we build serverless web and mobile apps.

The drive to microservices by giants such as Netflix has shown everyone why building monolithic applications is a thing of the past.

Serverless apps have to be microservices-based.

The stack that we use for our apps

Angular for the frontend
Services we use

• Database — Firebase
• Storage — Google Cloud Storage
• Server dependent tasks — Google Cloud Functions
• Email — Mailgun
• Authentication — Firebase auth
• Push Notifications — One Signal

The benefits of this stack

• No server management expertise needed
• No maintenance needed on services except maintaining the app itself.
• All of these are high availability services built with scalability in mind
• The pay per use pricing of the services means that costs are small since our clients don’t have to pay for idle capacity.
• It’s very easy to scale up or down depending on usage.
• There are generous free tiers on all the services.

Practice makes perfect

This post was first published in 2012 and updated in 2017

I say this to anyone who will listen to me — web development is all about practice. You do it repeatedly and you’ll be a pro at it. But slowly I’ve come to realize that this is true about everything.

I remember a long time ago I used to be really scared of driving. I’m not anymore. I kinda like driving around now. In the past 4 years I’ve fallen down, been yelled at for accidentally scraping someone’s car, haven’t really been in an accident — but don’t really want to. But the process is important — and I’m a much better driver now because of it.

I can remember this dialogue from Barcamp9 — some one on stage said “Don’t watch porn. Make it.”. This is true at so many levels. I read about successful web based companies everyday when I should be spending my time building successful companies instead. Instead of reading about hiring smart people I should be hiring smart people. Instead of reading about how to be more productive, innovating, automating, etc, etc. I should be doing all those things.

There’s a strike rate to everything. And you’re bound to be successful most of the times in the long run.

Easy project backups for web developers

We’ve talked about our development workflow. I wanted to discuss actionable backup strategies that are baked into the workflow.

It’s important that setting up backups be made part of the development process. Since the actual backup is a background process — it is much more likely that it will be done.

Our workflow has three environments. 
*local
*staging
*production

Our local projects are all backed up on a remote Git repository. We use Beanstalkapp for projects that are in use and Bitbucket as the final resting place for a project — since Bitbucket gives unlimited repositories in every plan. We usually create a separate repository for large assets like photoshop files and raw images.

Staging environment backups are usually not taken — since staging sites are a transitional space.

Production environment backups are usually done based on the platform used. 
For WordPress project, we suggest WPEngine to most of our clients who can afford it. WPEngine has daily file and database backups baked into each plan. That’s saved our bacon on more than one occasion. For our WordPress clients not on WPEngine, we use VaultPress which also does daily backups of the entire WordPress website.

We’ve recently been working with AngularJS frontend web and mobile apps powered by Firebase databases. We use the blaze plan for daily backups. The major pro with the blaze plan is that since it is a “Pay as you go” type of plan we usually end up paying less than a dollar for daily backups of decently sized databases.

Fun fact — World backup day is one day before April Fool’s day.

How we deploy code to websites.

Our development workflows involve three environments.

1. Development — This is where the code is written. 
    This is locally hosted on the computers that we’re developing on.

2. Staging — usually on the same servers as the live website.

3. Production — the live website.

Our staging environments are set up to be automatic deployments. That means changed files from each new commit are uploaded automatically to the web server.Production environments are setup to be manual deploys. Which means that at the right times — changes that have passed testing are uploaded to the production web servers by someone pressing the manual deploy button within the deployment tool.

We use Git for version control and for collaboration on code.

We use Beanstalkapp to host most of our active repositories. We chose Beanstalkapp over GitHub because Beanstalkapp has the ability to make secure file transfers (SFTP) directly to our web servers based on our commits.

For some smaller or extremely large projects, we use Bitbucket to host the repository and use Deploybot to deploy the code.

Automated deploys mean

• No more manual tracking of files that were changed and more importantly no more manual uploading of the files that were changed leading to much lesser chances of developer error.
• If there’s an issue with the release we can easily rollback the deployment.
• All of our team members are able to deploy code even when they don’t have access to the servers themselves.
• Since it’s so easy — each one of us is continuously deploying code to staging environments — where every change is tested for quality.
• Enormous savings in time saved manually uploading files.

If your team does not deploy automatically — take the time to figure it out. Your team will thank you for letting them focus on developing code not worrying about deploying it.

Reasons why you should consider building a hybrid mobile app.

What is the difference between a native app and a hybrid app?

Native apps are built in native programming languages like Objective-C or Swift for iOS and Java for Android operating systems. Hybrid apps are mobile apps built using HTML/CSS/JS “pages” wrapped in Phonegap/Cordova.

Code once, works everywhere

Hybrid apps need to be written once and can be built for both Android and iOS (and Windows Phone…). This saves development time that in turn saves development cost. With any software come bugs. While there will be similar bugs in android and iOS for hybrid apps — there will be two different types of bugs in native apps since they’re built off of two different code bases.

Frameworks galore

Frameworks such as Ionic reduce the time taken to build feature rich mobile apps. Developers can add common features like Geolocation, dialer support, push notifications by going through a plugin installation. A vibrant plugin ecosystem makes it easy to utilize native capabilities of the mobile operating systems 
https://github.com/driftyco
http://ionicframework.com/docs/native/

Plugins, Plugins, Plugins

Open Source plugins are available for all hybrid app frameworks like phonegap, cordova and ionic and React native. These make it easy to connect to third parties without having to build connectors. 
Here’s a list of examples.
Connect React native and firebase
Angular bindings for Firebase
OneSignal (a free push notifications service) with Cordova 
To connect the SQLite database with Cordova

Build a minimum viable product faster

Rapid prototyping is possible by building on top of existing themes and functionality For eg. http://market.ionic.io/ is a marketplace for Ionic starter packs for all kinds of apps.

Web Application included

The mobile app source code can be hosted on a web server which makes it a web application. You don’t have to develop another web application. Famously https://m.uber.com/v1/ was the same code that used to power the Windows mobile application. You could even go the desktop app route by packaging the app in Electron or Ionic Desktop instead.

Keep reading if you’re a developer.

Mobile is eating the world. As a developer you need to embrace this. It is now very easy to further your frontend development skills to build mobile applications. All good frameworks do most of the hard things for you already — while giving you the opportunity to work with cutting edge tech like Typescript, Angular 2 (which btw is fully forward compatible with Angular 4) or ReactJS.

You can even postpone learning about dev ops. Firebase is awesome as a cloud-based database solution. You get a scalable database with storage in regions around the world without the hassle of managing DevOps. Serverless platforms like AWS Lambda and Google Cloud Functions can let you run code that would usually need servers without having to manage servers.

We’re looking for frontend developers to help build amazing web and mobile applications.

A simple workflow for moving WordPress websites between servers.

Add the Content Freeze plugin so that no content is updated while the site is being moved

Use the All in one WP Migrate plugin to create an export file.

Don’t download and upload the export file.It makes a lot more sense to move the file directly from one server to the other

If SSH is available on the new host — use wget to download the file directly to the server. Remember that wget supports resuming downloads.

If only cPanel is available use exec to wget the file directly to the server

Make sure the export file is in the /wp-content/ai1wm

Restore the export from the backups section of All in one WP Migrate plugin dashboard.

Make sure the restore has gone smoothly by editing your hosts file to reflect the new host IP and checking in an incognito/private browser window.

Point the domain to the new host IP.

How we moved to HTTPS

Why HTTPS?
Google has been giving better search rankings to secure sites since a very long time . The nail in the coffin for us was now chrome and firefox show you an “Insecure” tag when you’re on a page with a password form.

Let’s encrypt is amazing at giving out free SSL certificates. Our hosting platform (WPEngine) unfortunately did not support letsencrypt SSL certificates till now. Recently that changed and they even made it very easy to enable SSL using Let’s Encrypt.

While moving the root domain to https was easy. We had a CDN CNAME enabled for our site. The CNAME made is prettier — so we had cdn.astechsolutions.in serving out all our static assets instead of the gibberish.netdna-ssl.com address. This posed another challenge. We needed another SSL certificate for the cdn subdomain. This unfortunately was not available for free in WPEngine. We’d have to buy a SSL cert and then plug into WPengine which was not needed. The excellent chat support team helped change the CDN url to the poor looking https://413k2a2926rbn3qij2lhfr1tfu-wpengine.netdna-ssl.com url for all our static assets.

Some things to note:
*A relative URL without a scheme (http: or https:) is valid. Include all scripts with // instead of http:// . This will use the https version of the scripts if one is available
*We used the plugin Really Simple SSL — to force SSL on certain links in the menus and widgets on the site. 
*We had to setup a redirect so that all http links would redirect to https. This is a setting in the WPEngine console.
*It always a good idea to clear the cache and test if everything is working as expected. We had some errors show up when certain content was not secure on the site.
*Always take a backup before you make changes to your website.

Once we did this for ourselves — we got all our maintenance clients on WPEngine upgraded to https 🎉

Daily Presentations — How we made it easy for team members to share what they’ve learnt

We have had a presentation everyday at astech since the last 8 months. We choose the speaker on a rotating basis … in the order your name is written on the score board — yes we keep scores. Winner gets an amazon gift card!

Rules:
1.You cannot miss your turn Has to be at most 5 minutes long — we use e.ggtimer.com/5mins to time
2.The presentation has to made to everyone. 
3.Needs to be something that you have some personal experience with.
4. You get scored from 0 to 5. 5 being the highest.
5. If someone is absent you get 2 points from them.

Pros:
1.Everyone gets to learn something new everyday. 
2.The presenter gets better at presenting
3.Possible blog post material

Some of the topics that we have covered:

How to update content on a WordPress site with custom post types.

Trekking 101

Machine Learning 101

An introduction to Sass

Cannonical URLs in WordPress

Indian Budget highlights (by our accountant)

Webcomponents

Body Language 101

Features of the Visual Studio Editor

An introduction to the Electron Framework for building desktop apps

An introduction to Cloudflare

How to play Black Jack

Different types of Life Insurance

TDS (Tax Deducted at source) calculations and exemptions

An introduction to Easy Engine

UPI (Universal Payments Interface) 101

How to use Netflix

Documentation needed for home loan (from one of us who got a home loan recently)

How to look for cheap airfare

The Grammarly chrome extension

Here’s what we’ve learnt.
Everyone in astech is an expert at what they do. Even our accountant is an expert, at managing the books.

Sharing the process of how you learn new things helps others to learn better.

Sometimes it is the little things that matter. A little thing that has taken you hours to understand and master. The time taken to explain this saves on the time that someone would have to spend in the future.

While not all topics are technical — they are all interesting. Non interesting topics get weeded out since this has turned into a competition.

Since people work in their own silos it is easy to get caught up in what you’re doing and not share what you’ve learnt.

Some things come naturally to some people. While to some people those exact same things can be difficult for someone else.

You don’t know what you don’t know. It helps to get an exposure on new things.

Sometimes these presentations are a way to show your team something cool you found out.

A Play Store experiment

The story begins three years ago when we created an app as an exercise for a new javascript developer in our company. We usually hire interns who are just out of college. College, especially in India, teaches you a lot about theory but not about the applications that exist already. The exercise was to implement an open API with PhoneGap while using data from a phone sensor.

While at McDonald’s a couple of us decided on making an app that gives you a list of McDonald’s closest to you. The intern knocked out the app in about two days. We passed the location from the phone to the foursquare API and then used jQuery mobile to show that list.

Got a logo designed by a friend. We even celebrated by putting it up on the play store.

Then we forgot about it.

Two years later on a whim I decided to open the Play store developer area. I noticed that the app had 2000 active installs! That felt amazing. I’d looked up the app analytics only because we had a new intern and we were considering repeating this tried and tested app exercise.

We built the app again. This time with bootstrap and phonegap. We added some features as well like deep linking the location within google maps. That’s it.

A year later we redid the app in React Native. You see the pattern here. This was mostly an app that we used to exercise our skills. We like to be on the cutting edge of tech — or at least slightly behind the cutting edge. We started listening to user feedback by enabling review notifications from within the play store publish module.

Most recently as a new exercise for another new employee we rebuilt the app again using Ionic (which is AnuglarJS and Phonegap) put up a small Google Ad widget as well.

The app earns around $8 a month — not bad at all for an exercise where we’re able to hone our skills.

Our plan with the app? Rewrite the app in Ionic2 next time someone new joins the team.

How we communicate using two chat apps @astech for a better work life balance.

Team astech works out of Mumbai — but it is easy to forget that Mumbai is one of the largest cities in the world. Travelling from one end to the other can take almost two hours one way. That is why we have a very comfortable work from home policy.

Remote working comes with its own challenges. The biggest amongst those is communication. We solve this by using a couple of different ways. Non project related chats are on WhatsApp and all project related talk is on Slack. Everyone uses the WhatsApp mobile app and the Slack desktop app. This leads to a clear line between work and life.

We love slack for the freedom it gives shared teams to be on the same page with many projects. We’re a results-oriented work environment. That means that people don’t check Slack while working. When they need to talk to a co-worker, even one in the same office, they Slack. This asynchronous communication leads to more time on the maker’s schedule.

Our workflows for Slack include:
*Channels for projects
*Slackbot reminders to do daily presentations and to get away from the screen for lunch
*Private groups for team discussions. Eg. business development talks that combine accounts and client management folks.
*Bots to do repetitive tasks — we use Howdy to do our daily standups and Kelasa to keep track on Workfront tasks.

We also use WhatsApp quite a bit. We have a broader office group with ex-colleagues and friends of the company to discuss current events and… well to forward forwards. We also have a team group on WhatsApp where someone could talk about urgent activities like for eg. if they might be late to work or announcements and planning for the latest movie or outing.

Hope this helps other companies create a culture where there is a clear distinction between work and life.