Feedback00:09

TripAdvisor00:27

  • Christina from TripAdvisor is here to talk to us about the decisions they made in developing their mobile apps.

  • TripAdvisor decided to use a hybrid app, since they wanted to support as many platforms as possible, as well as tablets.

  • They started off with a hybrid app, and fortunately the framework they used had features that supported everything they needed.

  • They also have a back-end API that returns information via JSON that looks something like this:

    JSON results from API

  • With that information, they can populate templates to form entire pages. Not only can the mobile clients use this API, so can the web client. They might have different "views" for the same data "model" in this case.

  • The iPad app for TripAdvisor simply embeds HTML in what looks like a native app.

  • Even though there are still differences for the Android and iOS versions of their app, much of the code can stay the same. Having a presence in both App Stores, as opposed to simply maintaining a mobile site, brings convenience to users since they can just install the app and have a shortcut.

  • At TripAdvisor, there are sort of three sets of engineers. One team works on the API that all clients can access, one team works on Android, and one on iOS.

Questions08:50

  • Can you explain why so many tech tools we’ve looked at in class are using the .io domain rather than .com? (…​also, is it good practice to be buying the .io domain if we set up our own sites?)

    • .io just looks more hip and modern than .com, and it can stand for input/output, a techy term. For branding purposes, it might be better to also get a .com domain, but since so many of them are taken, it might be necessary to get an .io first.

  • On an iPad, we cannot run Youtube in the background while using another app at the same time. Is it due to some kind of synchronous function or not at all?

    • This is probably due to a design decision. If the browser or app stops the video, it won’t be using resources that other apps can use, and conserves battery life as well.

  • In Silicon Valley Season 2 episode 1, the following claim was made in justification of a need for a powerful compression algorithm: "92% of the world’s data was created in the last 2 years. At the current rate, the world’s data storage capacity will be overtaken…​.and there will be nothing short of a catastrophe…​prepare for data shortages and data rationing…​" Is there any kernel of truth to this? On the surface, it does seem that perhaps the rate of data storage is outpacing Moore’s Law.

    • This seems to suggest a finite amount of data storage available, and though it might be true that production of data storage is limited to some extent, much of the data created isn’t ever saved. For example, CS50’s video productions might use multiple cameras that each produce gigabytes of data, but only the usable portions are eventually saved.

  • Will http://cs50.harvard.edu/mba be live after the course is over, or is there an easy way to save the notes/materials and assignments? It would be nice to have this stuff to refer back to in the future.

    • We’ll keep the course website up as long as possible, and since most pages on the site are HTML, you can just do File → Save.

ACT.md16:00

  • ACT.md is a local startup that came out of the iLab a few years ago, whose main product is team management software for the healthcare industry.

  • The software keeps track of who’s on the team for a patient, or what the plan is for a patient, much like project management software might work in a corporation.

  • One of the main issues in healthcare is that the transition of patients lead to dropped information, so using modern technology for communication helps improve patient outcomes.

  • Healthcare providers can log into the ACT.md platform to see the patients they’re working with, as well as what they might need to do:

    ACT.md dashboard

  • They can see team members for a certain patient:

    Patient information

  • As well as a patient’s care timeline:

    Patient timeline

  • Patrick Schmid from ACT.md is here to talk to us about the technology stack that they’ve chosen to use.

  • We’ll start with a demo. For example, links that open a new div on the page when clicked are implemented with a JavaScript callback function:

    Action on webpage

  • Adding comments sends a query back to the server, so that it is saved, and we can see that request in Chrome’s developer tools:

    Request
    Request header

    • The long number in Request URL is a randomly generated ID for the particular item being changed, and since it is so long its unlikely to collide with another ID. They could have decided to use incremental IDs, with 1, 2, 3, 4, and so on for each item, but scaling a database among many servers would require that there’s some difficult synchronization involved. So generating a random, unordered ID is faster and easier no matter how many servers they might have.

    • The request also ends with a token that authenticates the user in their current session, for security.

    • The protocol followed can be described as REST, representational state transfer, which, among other things, means that instead of logging in and out and using session cookies or otherwise, each request includes this token.

    • The Request Method is POST since they are creating something new, and they would use PATCH to modify a record or DELETE to remove one.

  • GET would be used to retrieve a record, or just HTML of a page.

  • The website is an abstraction over the API (users clicking buttons and links aren’t typing out each HTTP request), which is an abstraction over the database (the requests aren’t SQL in themselves), and the database actually isn’t in just SQL, but uses something called an object relational mapper that converts user objects to raw data.

  • The front-end language is mostly JavaScript, using frameworks called Backbone and Bootstrap, the API is implemented in Python with a framework called Flask. Other popular back-end frameworks include Ruby on Rails, Java, Spring, node.js, etc. The framework is different from the language in that it speeds up development by providing common templates or functions that don’t need to be rewritten from scratch. And they’ve also been tested and debugged, so it’s the fastest and safest way to go.

  • In general, choices in engineering have to do with tradeoffs, since if there was a best way it would become the only way.

  • For ACT.md, security is a primary consideration, so that can never be compromised. But even though hospitals might want to keep their data secure, patients might want to take their own data to various providers, so some sort of sharing mechanism needs to be developed that satisfies everyone. Scalability is also important, but only if correctness, or durability of data, is there first.

  • Some other decisions made might include these:

    • choosing a development environment

      • ACT.md uses Macs, since the OS is based on UNIX and so are many web servers, so commands are more similar than with Windows machines. They use VirtualBox to virtualize an Ubuntu system that’s similar to their production server, and inside that they use Docker to actually package the software their web servers use. They chose Docker because it’s easy to use and update or reconfigure all the software. Docker also virtualizes the file system, so none of the changes it makes are permanent, and makes it very easy and fast to swap software configurations. Fabric is another tool they use to run tasks on remote servers more easily. They also prefer open-source software, since more people are looking at them and helping fix bugs.

    • choosing a web host

      • ACT.md uses FireHost (now Armor) for their production servers, and AWS for testing. One of the most important features of FireHost is their live monitoring of network security, so they can see any attack attempts and have a chance to counter them before any data is leaked.

    • choosing a language

      • HTML, CSS, and JavaScript are the standard for the front-end, while Python is the back-end language.

    • choosing a back-end framework

      • Flask is the framework keeping everything together, while alternatives are Django or Ruby on Rails.

    • choosing a database

      • ACT.md uses MySQL, while alternatives include Postgres or Microsoft SQL Server. Redis is used for caching, so the server isn’t regenerating pages constantly.

    • choosing a front-end framework

      • Backbone.js and Bootstrap are the front-end frameworks, Angular.js is an alternative among many. An important factor here is choosing one with lots of community support, so bugs are fixed more often and there is more documentation or questions online that are answered.

    • monitoring

    • caching

    • queuing

      • Requests are also queued with RedMQ.

    • scaling

  • As for advice on making technical decisions, these sites are some of the more useful:

  • There wasn’t enough time to cover everything but that’s it for the course!