The current Quickstart guide for the new FB Messenger Chatbot is in Node.JS. I am currently working on a project in Python and couldn’t find any Copy & Paste-able Python webhooks. So, I created one myself. Hope this is helpful to someone else 🙂
If you haven’t picked up any iOS development skills yet, now is the time. It’s never been easier. Below are my reasons to finally take the plunge (successfully), followed by some helpful links to help you learn to create your first app too.
Contrary to popular belief, I’ve never coded up an iOS app myself. My excuse? For one, hiring great iOS developers gave me more time to focus on building great teams and products for my startups. In addition, Objective-C has a unique syntax and requires a deeper understanding of handling memory, which demanded even more learning time. Finally, there was an immense level of complexity involved in testing, certifying and delivering native iOS apps to market. As a matter of fact, those higher than normal learning curves inspired many startups (including a few that I launched) to focus on making developing apps easier.
Since I already had a strong web development background, I always found it easier to build prototypes for my ideas using the latest web-based, app-building, technologies. Year-after-year a new product claimed to have “the right stuff” needed to create an iOS app that felt fully native, without needing to learn to code directly in Objective-C. Year-after-year I found those claims to be more wishful thinking than reality. Although quicker to develop, those technologies always left the final product feeling hacky, unresponsive or limited, and, in order to go full steam ahead with a project, a fully native version would be necessary.
Earlier this year I took another shot at using a new piece of web tech to build out a mobile app idea I had. This time I learned Polymer 1.0. I loved it as a web framework, but my hopes that Google had managed to finally develop an SPA framework that translated into a smooth functioning mobile app was, yet again, overly optimistic.
It isn’t really the technology’s fault though. The rendering mechanisms for HTML/Web (et al.) just weren’t made to process smooth app-like features. It renders top to bottom, grabs all its assets remotely, makes a lot of inferences, is based on standards that try and work across an array of products made by a variety of companies, and manages general security measures that must be spread across every site. In the web world, the browser is the ad-hoc gatekeeper, and its fighting to keep up. The mission of a browser is critically different to that of apps: to allow a user to serendipitously browse a large breadth of sites in a single view, all the while protecting the user from exposure to malicious pages that are inherently sprinkled into a user’s browsing session. Native apps are different. Both the user and the developer have a strong working agreement between what the developer would like you to see and how the user would like to see it. With that level of trust the developer is able to confidently create an experience specifically tailored to the goal of the app and the interest of the user; the OS can focus on greasing the wheels.
Sorry, I digress. Point is, yet again I was disappointed in what the web (and web wrappers) could offer, and, almost as a yearly tradition, I took a stab at learning how to develop directly in iOS again. This time, I’m glad I did!
Maybe it was due to all the free time I had while on our year long trip, but I doubt it; it came rather easily this time around. No, I think the main contributor to my smooth transition is that Apple has done a stellar job incrementally improving the life of an iOS developer over the years. I think the real turn was the release of Swift in 2014. The language is a natural leap from other common languages, as compared to its Objective-C counterpart. Also, there is no longer a heavy requirement to understand how to manage an app’s memory and delegations. The other power ally in creating ease for iOS developers is XCode’s more powerful yet simplified environment, along with interactive interfaces like Storyboards, segues, IB Designables and more. In addition, now that TestFlight is fully integrated with iTunes Connect and Xcode, testing an app on a device, releasing it to external testers, and pushing it to the App Store is only a few clicks worth of effort; fairly brainless really.
All this added up to a surprisingly easily made V1 of my very first fully native iOS app! Yay! This will be fun 😀
Links to Learning iOS
Here are some key links I bookmarked while learning Swift in Xcode 9.0, including: vides, Q&As on StackOverflow, and tutorials. I strongly recommend learning the language by working toward implementing an idea you want to bring to life. Not only does it give you an inherent direction in what needs to be learned, but it also helps you push through the tough parts of learning that would otherwise spell defeat. The app I built used APIs, JSON, CoreData, Table Views (for listing data), Audio, and more. Hope this list helps!
UI Table View Controller
Prototyping a Custom Cell
Storyboards Navigation and Segues
Network and Observers
Page View Controller (Pages on swipe control)
One of my more recent pet projects has been to create a web-based application using Polymer 1.0, a web framework Google released at their I/O conference this past Spring.
In short, I don’t think I can ever go back to developing on the web without it. Not only do I strongly suggest everyone give Polymer 1.0 a try, but I implore new developers to learn web development by implementing it, and current dev teams to incorporate it into their product lifecycle – at the very least during their rapid prototyping stages.
Why is that? Good question!
For one, it is the first time I’ve ever used a web framework where the resulting code base feels legitimate, complete, and inherently organized; not a mesh of scripts and views that the original developer will need to walk other devs through to ramp them up.
For new devs, the clean, class based, object-oriented structure will help mature their web development habits. Even as an engineer with over 15+ years of development experience, I felt like using the framework improved my habits.
For product teams, the scoped modularity of the elements allow their group to quickly re-work layouts and functionality – on an element-by-element basis. You can inherit core elements and layouts, and test them individually as you assemble the project. Designers can perfect a single element’s look and feel even before the structure of the application is built. It makes for an excellent segway between mockup and final product.
What makes Polymer so Different?
1: It uses web components, shadow dom, and pure HTML/CSS to render templates.
2: Each element you create is packaged individually and contains: a tag based HTML layer, a scoped CSS layer, a JS layer and an import framework.
The web world is made up of hacks
The truth is most (if not all) HTML/JS frameworks are made up of what could be described as a series of “hacks” that attempt to create a consistent end-product across all web browsers (and versions of browsers) out there. These hacks are necessary due to the slow pace to which web standards evolve, and exacerbated by the fragmentation created by the popularity, and propriety, of those browsers.
A Polymer Breakdown
Shims and Polyfills
Shims and polyfills are hacks that transparently help protect a developer from the need to implement legacy or cross browser functionality. As the name describes, they fill in all the compatibility holes browsers leave behind.
You actually interact with the Shadow DOM all the time on the web without realizing it. When you use an HTML tag such as <video> you are requesting an element to be rendered by the browser. That element is composed of many subelements you can’t see in the inspector, ergot “shadow dom”. These subelements, such as the ones composing the video tag for example, manipulate and manage each frame of your video content. By creating your own custom elements utilizing the shadow DOM you are able to encapsulate entire chunks of your application’s functionality into a single tag.
Webcomponents.org has created a Polyfill library that allows users to take advantage of custom elements like the ones descrived described above. For example, a profile card you create can be shared and implemented as a single tag: <profile-card></profile-card>, by simply importing the “/profile-card.html” component.
Unlike other frameworks or libraries (such as Angular, Handlebars or JQuery) which work to manipulate and manage separately constructed HTML tags and CSS code, Polymer combines web components, polyfills, shims, CSS, HTML tags, two-way binding and the shadow dom into into a single package.
The Polymer/WebComponents structure solves certain small annoyances of web development, like having to keep track of all your CSS styles and hierarchies across your app. Every Polymer element scopes its CSS selectors to the element itself, thus, these selectors will not affect other CSS selectors outside of the custom element you create. In other words, you can use “.my-box” over and over to style different boxes based on their element context without affecting one another.
Some other useful features:
- Drop-in documentation rendering system
- Drop in testing frameworks
I could really go on and on about how smooth and organized it feels to develop something using Polymer, but it’s best for you to give it a shot yourself. Let me know what you think or if you have any questions.
Here is a look at a basic custom element setup:
If you are unsure of where to begin, start by using Polymer’s sample project (aka Polymer Starter Kit). It is a fully functioning app with a folder structure and gulp file built in. I original strayed away from the starter kit structure, but found myself ending up the same place as they did eventually. They did a good job with it, and it looks like they keep iterating on it.
Note: I should mention that there has been one annoyance I’ve had to deal with while learning Polymer: the lack of documentation and relating forums. The things that ARE available refer to Google’s originally releases Polymer 0.5 from a few years ago. These posts are often unhelpful since so many nuances are different in 1.0. The good news is my new questions posted on Stackoverflow had responses within a matter of hours.
I’m a big fan of Heroku setup for pet projects. With it I am able to quickly deploy a project without having to develop on some proprietary framework or prep a server to host a website. I especially love how easy it is to deploy directly from my local machine through a git push to master, and my ability to run and configure the system through a dashboard or command line toolbelt.
Until now however, I needed to keep two repos to manage my source code. One in Github for sharing, viewing, and tracking; and one in Heroku for deploying. Last week Heroku released a new feature that allows you to connect your Heroku account to Github: https://blog.heroku.com/archives/2015/2/6/heroku_github_integration
You can use this new feature to select which branch Heroku should use to trigger auto-deployments, as well as run pre-checks against your C.I. system tests. In short, I likey 🙂
Per my last post about the splendor of GAE, below is one example of a tool I built for us at Socialize to keep an eye on code coverage and lets the group know if a build is broken (if our tests have failed.) This script is built to run on Google AppEngine, checks against a TeamCity Server install, and expects that each project in team city has code coverage outputted to its artifacts folder.
What is C.I. Server and why is it important?
C.I. stand for Continuous Integration, and is a system used to constantly/”continuously” checks to see if a code base is “working” or not. Team City (by JetBrains) is a product made for that process. Usually it is used to run tests against a code base to make sure it is working as expected, as a part of the QA life cycle. These tests are made up of “unit tests” that are created by the developers whom write code to test the code they are writing. It can be a bit odd for those that have not ever done so, but it is quite important when trying to deliver stable code. In short, and in its simplest form, this whole system makes sure new code/changes doesn’t break old code already in place. You can read more about these processes and purposes here: Unit Testing & Integration Testing.
What is code coverage, and why is it important?
Code coverage examines how much of your code is being tested. For instance, you may have a C.I. system in place, and a unit test frame work running within it, but if the tests only test/”cover” 1% of all of the code you aren’t really delivering a level of confidence you should be. In this tool we track the coverage percentage over time. Seeing it as a graph helps recognize dips in coverage easily.
GAE offers a free to get started approach, along with an instant “hello word” initial environment, making sandboxing ideas and building helpful tools for productivuty a snap.
To get started, download GAE, press the plus sign in the bottom left corner. Set the directory you would like to work out of and your almost done. Well, at least you are already at the stage you need to be to start playing with the system locally, in what we call the development environment (No one can see your system but you.) Just hit the [play] button on the GAE dashboard and you are running with your first environment. Just click the Browser (the compass looking thing), or go to http://localhost:8080 in your browser, and you should see your first “hello word“! It is quite reassuring to see it work so smoothly (if indeed it does), and if this is the first time you have coded, trust me they have taken out a hell of allot of pain out of the tedium it can take to get here.
Without getting into the nitty gritty of code just yet, let’s push your baby to production (That means make it live/accessible to the world). That’s right, you are about to push a web application live to production! First create a new app at the google app engine home page and follow the steps there (setting up your yaml for upload). Your yaml file tells google which app your are updating when you do so. Not making sure your yaml matches your project is like you sending mail through the USPS without out a “from”/”to” address.
Once complete, press the blue arrow pointing upward (the “deploy” button) and it will deploy (AKA: push to prod, go live.)
Once deployed, you can update, monitor, or even share you application with the world. And all for free. Not that this baby would get allot of attention in its current state (just a “hello world”), but if it did, it would also be scalable. I mean 10 years ago this would have cost you quite a bit of time money, especially if you didnt know allot about server configurations, apache, linux, or windows server, or…well you get the idea.
There are a few sample apps you can play with on the GAE site. If you are ready, start developing some code i Python. Maybe had a hellow world message of your own.
When you start feeling saucy, try and create a model. A model is a data structure you can save, or persist, data to your system. Again to you newbies out there, this is the equivelent of your granfather telling you, “back in my day I had to walk up a hill in the snow to get to work, and up a hill in a blizzard to get back.” Setting up a database on a production server was a skill on its own, but to create one that is scalable, and without the need to architect it is amazing. You see, based on the models you create GAE intuitivley creates your “database”, stores it efficiently, and assumes where indexes need to be placed. You really don’t have to understand any of this, but if you want to you can look up those terms have at it: indexing, database, architecture, MVC…. Like I said, I’m just an old guy complaining about hills.
If you are still a bit timid about getting started, don’t worry there is a baby step in between these tween sized steps that can help you get ramped up before you start churning out lines and lines of code. Click on the “SDK Console” button on the GAE dashboard. It will open up a web page that is running locally, on your stage environment, that gives you windows into your system to hack around with. (This console lives inside your development app, so don’t forget to run your new app to get access to it.) Once in the console, click “Interactive Console”. There you will have a very rudimentary terminal that you can write temporary test scripts in. The output is shown on the right of the screen. This is a great place to get errors, make mistakes, and go nuts! (Note: The SDK Console also houses your development DB, so you can check to see what data you are saving after you have attempted to save it.)
Note: The easiest way to get started as a newbie, in my mind, is by using Python in GAE. Java, although awesome, is a bit more advanced.
I recently used GAE to create a few projects to help out the team. One for TeamCity monitor to view coverage reports and if a build is broken or not. And also one for Pivatol Tracker to help our press and marketing interpret what is coming out of the product pipeline, if its ready, and what are the stories of value within. I will post templates for those projects in the near future.