Many folks are still confused on the distinction between PhoneGap and Apache Cordova. There are so many articles on the web that further blur our minds :)
I found this blog post on the Ionic site to be the most accurate comparison of PhoneGap vs Cordova.
Jotting down some snippets from the blog.
"PhoneGap is Cordova plus extra Adobe stuff. At first, the differences between Cordova and PhoneGap were minimal. But Adobe always had plans to build out a proprietary set of services around the PhoneGap ecosystem, and has started to execute on that plan with PhoneGap Build."
PhoneGap on its blog has made an interesting distinction between two types of Hybrid applications -
Native Hybrid: In this approach, you build a native app and use native controls for navigation, menus, etc. But most of the content pages are HTML views rendered in a web view. The HTML content can come from the local store or the server.
In iOS 9, Apple has implemented a new security feature called as ATS (App Transport Security), which is enabled by default.
So what is ATS? In simple words, ATS enforces all HTTP requests to be made on SSH - i.e. any API call your app makes to the backend servers must be on HTTPS. If you want to make an unsecured HTTP call, then you have to explicitly list down those exceptions in your Infoplist file.
ATS also enforces the latest protocol version of TLS - i.e. Transport Layer Security version 1.2. This can cause issues if your server is using HTTPS, but an older version of TLS. In such cases, you have two options - either upgrade your server to use the latest TLS protocol or add an exception to your app for these URLs.
A lot of folks get confused over the differences between Git and GitHub and use the words interchangeably. Also when folks talk about GitHub, it is assumed that it is only available on the public cloud and cannot be hosted in-premise.
Git is essentially a distributed version control system. It is called 'distributed' because we can use it locally and disconnected from the internet and then push our changes to another centralized repository (such as GitHub, Team Foundation Server, CodePlex, etc.) as and when required.
For a good comparison of centralized vs distributed source control systems, please read this blog post.
GitHub is a hosted service (public cloud) that can host your repositories and allows you to access your repositories via a web based interface. It is possible to use Git without GitHub, but only on a local machine. Hence in order to collaborate and work in a team, we have to use GitHub.
In the free plans of GitHub, we can create any number of public repositories, with unlimited collaborators. In the paid plans of GitHub, you can create private repositories.
GitHub Enterprise is the on-premises version of GitHub, which you can deploy and manage in your own, secure environment (private cloud).
Centerline has published a neat infographic illustrating the UX design process. While there are a lot of UX related infographics on the net, I liked the simplicity and clear thought process of this one :)
When we create compelling user experiences for our customers, we follow a similar process.
Gain a deeper understanding of the customer and the industry segment the customer operates in. Who are their end-customers? What is the market positioning of their product?
Based on customer segmentation, create personas and user journey maps.
Over the past decade, the simple Markdown text formatting syntax has gained a lot of popularity. Many bloggers and web writers have shifted to using Markdown, though a few still use word processors or WYSIWYG editors.
John Gruber, the inventor or Markdown gives the below explanation for creating Markdown -
"The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions."
This is the reason that Markdown has become popular for web writers who publish their content on to the web or other digital channels.
Markdown text can be converted to HTML or many other formats (e.g. PDF, Word, etc.) using tools such as Pandoc. There are also online editors for Markdown such as http://dillinger.io/, that shows you the formatted HTML side-by-side. Blogging platforms such as Wordpress have also started supporting Markdown syntax. Even the Ghost blogging platform supports Markup.
But there are limitations on what you can do in Markdown when it comes to complex formatting. Hence the format allows you to embed HTML code inline whenever you want some complex formatting.
It's important to understand that Markdown is good for creating content, but would not be a good fit to be used as a generic purpose web site creation tool . As John Gruber says in his philosophy:
"Markdown is not a replacement for HTML, or even close to it...The idea for Markdown is to make it easy to read, write, and edit prose."
Pandoc can also be used for reverse translation - i.e. to convert HTML, Word docx files to Markdown format.
Recently, a colleague of mine asked an innocuous question that was quite interesting. We all knew that SSL protects the URL and hence it is not possible to snoop details out of the URL - for e..g GET params, resource path on server, etc.
But if the URL is encrypted by SSL, how does DNS work? How will the DNS server route the request to the right server?
The way it happens is as below:
When a HTTP client (browser / API client) makes a request to a HTTPS URL, it only send the server name part of the URL to the DNS server. For e.g. if you are making a request to https://myserver.com/secret_path/secret_resource, then the HTTP client would only send 'myserver.com' to the DNS server for lookup.
The DNS server responds back with the actual IP address of the server.
The HTTP client then makes a call to the server using the IP address. What follows is the SSL handshake protocol and a secure connection is established with the server.
Then the HTTP server makes a request for the actual resource on the secure pipe/tunnel.
Quite simple actually, if you break down the steps :)
If you follow the microservices architecture style, you would have a bunch of services running in their own independent process space.
But how do you orchestrate services for a given business workflow? For e.g. a business transaction that spans multiple calls to microservices.
Point to point integrations would result in 'Dependency Hell'. If each microservice calls the other microservice directly over HTTP API calls, then very soon we have a spaghetti of API dependencies.
One simple design pattern to resolve this is by using the EDA (Event Driven Architecture) paradigm. Each microservices does its job and then publishes an event. Other microservices subscribe to the event and act on it as necessary.
This pub/sub model results in loose coupling between the services and makes the system much more maintainable. A good blog-post covering this paradigm in more details is present here.
Setup (installation and configuration) of servers and other infrastructure components is a tedious process.
In the olden days, process-oriented teams created meticulous documentation on 'how to setup a server' - typically in a word document with screenshots and step-by-step instructions.
Folks then tried to automate some tasks using scripts - e.g. unix shell scripts/bash etc.
But today, in a cloud-first world, setup of servers and deployment of applications need to be completely automated. The whole premise of 'Infrastructure-as-Code' is to write code in a high level language (e.g. Java, Python, Ruby) or a DSL (domain specific language) to automate the provisioning of infrastructure and managing configurations.
So this goes beyond just writing simple scripts. You utilize all the best practices of agile development projects - i.e. version control, unit testing, iterative development, etc. The whole revolution happening in DevOps acted as a catalyst in promoting the concept of 'programmable infrastructure'. In DevOps, the core concept of 'You built it, You run it' promotes closer collaboration between the development teams and IT ops team.
Popular tools such as Ansible, Kubernetes, Puppet, Chef, etc. can be used to automate your complete deployment cycle and help you achieve Continuous Delivery.
Laptops suffer from so many idiosyncratic battery problems and have their own ritual of try-n-test solutions that appear so weird !
Recently, I was facing a unique problem on my HP pro book 440. The charger was connected, but the battery was not charging. The status showed - "Plugged in, not charging". I tried multiple options to rectify this - by removing and plugging in the battery, by restarting the machine, but nothing worked.
The following steps posted on HP forum finally did the trick.
- While the computer in running, disconnect AC from the outlet
- Restart computer
- After loading, reconnect AC