name: introduction class: center, middle # Polyglot Developer # ## Branching out and diversifying ## Alex Wynter Email: awochna@email.arizona.edu Github: awochna Bitbucket: awochna Learn at least one language every year. .right[\- *The Pragmatic Programmer*] --- name: personal-information # Some info about me # ??? Given the breadth of the topics, I should let you know that I am a human and I don't have unlimited experience. Therefore, I have opinions based on my experiences. Please feel free to disagree. In this presentation, I've done my best to be as objective and neutral as possible. Given that, I want to share some of my information with you so you can better see past those biases. -- * Web Designer/Developer for Mel & Enid Zuckerman College of Public Health ??? * We mostly build grant, project, and center sites in Drupal for the people that need them. -- * Favorite Programming Language: Ruby ??? * It's beauty lies in it's syntax, it's object-oriented design, it's conventions, it's community, and that I feel like it really has been optimized for developer happiness. -- * I do most of my work for the college in Drupal. ??? * Including everything from site building to module development. -- * I also do Linux server administration. ??? * So between those, I do everything from helping people format their HTML properly and updating a page, to site building and design, custom module development, and managing server logs and services. -- Other tools: .third[ * Jekyll * Rails * drush] .third[ * Apache * nginx * MySQL] .third[ * Gulp * vim * git] ??? * And more, of course, this is just a list of the ones I could come up with off the top of my head. --- name: agenda # Agenda # 1. Purpose of this presentation 2. How should we evaluate tools? 3. Taking a look at some languages 4. Taking a look at some tools 5. Looking at a really small website project (deeper dive) --- name: purpose # Purpose of this presentation # When you need to solve a problem, you want to use the right tool. -- We use great technologies to solve a wide variety of problems (i.e. Drupal) ??? And there's a good reason for it. We'll get into that later. -- However, there are some problems that our normal solutions may not be well fit for, typically edge cases, but sometimes our jobs evolve that way. ??? Branching out helps us be prepared and have a good sense of the development landscape to help us handle strange edge cases. And if our jobs evolve in a specific direction, we already have some experience there. --- name: purpose-cont # Purpose of this presentation # What does polyglot developer mean? ??? Cool title, it's got some buzz words in it. * Generally, it refers to a developer who uses multiple languages to create software solutions, using the strengths of each. -- * In this case, I'm using it to mean a developer who uses the right tool for the job, no matter what it's written in. ??? In a lot of cases, the language that a tool is written in is abstracted away from you. Drupal has a good UI that you can do some complicated stuff in without every writing any code. In that case, it could have been written in any language in the world and it wouldn't have mattered to you. -- * Example: You may be already on this path by adopting Sass (SCSS) to help you manage your stylesheets. ??? You are probably already doing this somehow. You just might not be aware of what language some things are written in; sometimes that isn't important, but sometimes it is. For example, if you need to make a small API using a microframework, Sinatra (Ruby) and Express (node.js) are good candidates, but how do you know which one is better fit? Look at the language features. --- name: evaluating-tools # Evaluating tools # There are simply too many options. How do you classify them? ??? * The way I've looked at tools, they can supplement functionality you're already using, or offer a replacement for a tool you are already using. * There are a few different types of tools we can find: -- * *Supplemental tools* help you solve the problem, but aren't the solution. * Sass, git, TextMate, etc. ??? * Then we have replacement tools. These can be further divided into 2 more categories. -- * *Drop-in replacements* are very similar to a solution you are already using. * Wordpress in place of Drupal, Less instead of Sass, etc. ??? * These are the ones you want to avoid using. They will take time to learn and give you a marginal level of benefit. -- * *Edge-case or use-case replacements* are similar to a solution you are using, but handle your particular use case better. * Jekyll instead of Drupal for small, static sites. ??? * Reminder: We'll get to Jekyll in the case study * These replacement categories aren't always clear cut. It'll really depend on what it is you want to accomplish. * For example, Drupal can be considered a 'Drop-in replacement' for Wordpress, but if security is a strong project requirement, Drupal is more of a 'Use-case replacement'. --- name: what-to-judge # What to judge about them? # When you're evaluating a new tool, what pieces of information do you want to pay attention to? -- * Maturity (Check out bug reports) ??? * Project maturity is important. This should not be taken to mean how old the project is, though. Instead, check out the bug reports and go through a couple of them. If the bugs seem major, like something you could see yourself running into pretty quickly, it's not ready. -- * Documentation (If you can't find them, it's a bad sign) ??? * Project maturity can be forgiven to some degree given sufficient documentation. Documentation can also never be too in-depth. As you get more and more familiar with a tool, you want lower level documentation. -- * Conventions/Style Guides (If they don't have one, it's also a bad sign) ??? * Conventions don't have to be explicitly stated. If you need to add an arbitrary file to your project, you should be able figure out where to put it, either intuitively or because a google search should yield a result. If it's 'up to you', make sure to pick a system and stick with it, then document it. -- * Tutorials and learning resources (You don't need too many, but too few hurts) -- * Community and it's values (You kind of have to just jump in and find out) ??? * Community can make or break your experience with a tool. An unwelcoming or dismissive community will be hard to work in when you have questions or want to contribute back to the community. I can't say I've ever seen a *bad* community, but some communities will value different things differently. -- * Ecosystem --- name: languages-1 # Lets look at some languages # -- More specifically, let's evaluate: -- * PHP * Python * Ruby * Javascript (node) * Go -- We won't talk about the attributes previously listed, but instead, we'll discuss their strengths and weaknesses. ??? Instead, I want to talk about more interesting things, like what the languages are known for and what their strengths and weaknesses are. --- name: php # PHP # _You can program websites, too!_ Is known for: -- * Being easy and accessible to new programmers and developers. However, language design issues are counterproductive to learners. * See: http://eev.ee/blog/2012/04/09/php-a-fractal-of-bad-design/ for more info. ??? * Some functions are snake_case, others camelCase. Object Oriented Programming features feel Java-like while Procedural Programming features feel C, etc. -- * Being ubiquitous. However, some shared hosts don't update their PHP versions. -- * Focusing strongly on solving web problems. Consequently, it's not the best choice for more 'general purpose' things, like command line tools. -- * Developers from other languages have a hard time getting over PHP's history (see language design issues link). -- * **Good News**: Good tools built in PHP will try to alleviate and abstract these pains away from you. Except the developers from other languages. -- **Note**: Facebook is written in PHP. At that scale, PHP's performance becomes a major issue, but Facebook is too big to be rewritten. As a result, they created their own PHP JIT (Just In Time) compiler, hhvm: http://hhvm.com ??? So, in short, PHP is good for: * Web development * Ease of deployment * Non-developers * As a platform for other tools (Drupal, Wordpress, etc.) And not so good for: * Non-web development * Really complex programming problems (frameworks can help here) --- name: python # Python # _There should be one-- and preferably only one --obvious way to do it._ Is known for: -- * Being really easy to learn general programming with. It doesn't have a lot of the language design issues PHP suffers from. -- * It's widely used in the Academic and Scientific communities. As a result, there are really good libraries for really cool things, like machine learning, hard core number crunching, etc. -- * Clean syntax. Aesthetics matter! Bonus points for an official style guide: https://www.python.org/dev/peps/pep-0008/ * Can help prevent [broken windows](http://www.artima.com/intv/fixit.html) -- * A huge backwards-incompatible change moving from Python 2 to Python 3. ??? * Just like in Drupal when D7 came out, it took the community awhile to port or rewrite their libraries to Python 3 syntax, causing it to schism. -- * It can be run on the Java Virtual Machine (JVM) via Jython: http://www.jython.org/ --- name: ruby # Ruby # _Optimized for developer happiness_ Is known for: -- * Elegant and extendable syntax that makes creating a Domain Specific Language a breeze. This makes learning harder, as a result. -- * Being extremely object oriented. PHP's basic types are implemented as objects in Ruby. -- * Surging in popularity because of Ruby on Rails. Now that 'cooler' things have come along, some developers in other languages think it'll slowly fade away. -- * The community places a high value on automated tests. This can be good or bad depending on your personal values. -- * It can also run on the JVM: http://jruby.org/ --- name: node # Javascript (node) # _Non-blocking input/output model_ Is known for: -- * Letting a full stack developer work in a single language on the front and back end. This is often debated as a blessing and a curse. -- * The non-blocking input/output model is really cool and gives the illusion of concurrent programming in a single thread, but it isn't true concurrency. -- * For being new to server-side programming, it gave a good dependency management solution really quickly (npm). ??? * As compared to the PEAR project in PHP. Thankfully, Composer aims to change this. -- * It's popularity is almost literally exploding. For example, npm was made in 2009 (6 years ago) and has 173,681 packages (as of 2015-08-11). Check out http://www.modulecounts.com to see the ridiculous curve. -- * It's callback model can get a little out of hand, creating [callback hell](http://callbackhell.com). -- * When combined with [Express](http://expressjs.com), you can build a simple API application easily and quickly. --- name: go # Go # _Try searching for go-lang instead_ Is known for: -- * Being lower level than any language discussed so far. -- * Compiles to binary, so it's very similar to C, but with modern language features -- * **Really** good concurrency. -- * Being made at Google. Naturally people have differing opinions on this. -- * Having a small language footprint, makes it easier to learn, but it has enough in the standard library to handle a lot of situations. -- * Being *really* fast. -- If you want to try a tool in Go, check out [GoBench](https://github.com/cmpxchg16/gobench) for benchmarking website performance. --- name: tools # Tools # We'll take a look at: -- * Drupal * Sass * Selenium IDE * Express * Jekyll --- name: drupal # Drupal # _There's a hook for that._ Is known for: -- * Being very secure. ??? * Given our position as a higher learning institute, hacks, defacement, and security breaches are particularly harsh on us in the public's view. Drupal makes security really easy. -- * Being really flexible, extensible, and modular. Bonus points for having a large module ecosystem. ??? * With the ecosystem of open-source modules, you can build almost anything you can imagine. Anything that gets too complex using contributed modules can be built in a custom module and redistributed to other sites that may need the same functionality. * And being free is a big deal here. I remember looking at Wordpress and Joomla (also in PHP, competitors to Drupal) a few years ago and being suprised that there were plugins and extensions that you had to *pay* for. -- * Being easy to deploy. ??? * Historically, developers don't often get into system administration. Drupal only requires a LAMP stack with minimal configuration. Unless you're deploying a static HTML site, it can't get much easier. -- * Can be used to build a simple 5 page static site for someone's grant, but it's overkill having user accounts, running cron, dynamically caching pages, checking permissions to view the page, etc. ??? * We'll take a look at an example solution later in the presentation -- * It can also power sites with complex forms and workflows for collecting student input and graduation requirements. This can also introduce a lot of complexity that a custom app could handle better. ??? We actually have a site like this at MEZCOPH. -- * Subject to *Drupalisms*, or quirks Drupal has that would not make sense to someone not familiar with Drupal. --- name: sass # Sass # _Hey, you can **nest** CSS selectors!_ Sass is a CSS preprocessor implemented in Ruby. -- It actually implements 2 syntax sets. The more common one is called SCSS and is a CSS superset. ??? * Basically every valid CSS file is also a valid SCSS file. * It also means you can install Sass in your project and make changes to your existing project incrementally. -- It implements features you wish CSS had (and may have in the future) including: -- * Nestable selectors -- * Variables -- * Functions and extendables. -- * Partial files and include functionality -- Check out http://sass-lang.com for more information! --- name: selenium # Selenium IDE # _Record and play back browser macros_ Selenium IDE is a browser automation and testing tool implemented as a Firefox extension. -- If you need to do a very repetitve task more than a few times in a row. It'll be worth setting up a Selenium script to do it for you. One click can handle an entire series of browser interactions. -- Client side testing for site can be difficult to achieve without writing test suites in code and learning acceptance testing frameworks. -- * Selenium can record a series of actions as a test. You can put multiple tests together to create a suite. -- * The entire suite can be exported and saved as code, sent to your colleague or boss, and they can run the suite to see that the site you built works as it should. -- * And you never had to write a line of code. -- Check out http://www.seleniumhq.org/projects/ide/ for more information! --- name: express # Express # _Fast, unopinionated, minimalist web framework for Node.js_ Express is a good framework for building APIs or services in Node. -- * Routing is easy being at the forefront of the framework. -- * With node's increasing ability to run jobs on your server, it's common to put up a small Express app that listens for a certain request and triggers a process. -- * You can even make sure your node/Express app runs [forever](https://github.com/foreverjs/forever). -- * The lack of opinionation and the minimalism can make really complicated web services difficult to maintain. You might want a fuller, opinionated, MVC framework for this ([Sailsjs](http://sailsjs.org)) -- * Doesn't include components of the framework you might find necessary, like an Object Relational Mapper. -- Check it out at: http://expressjs.com/ --- name: jekyll-1 # Jekyll # _Simple static site generator_ [Jekyll](http://jekyllrb.com) is a command line tool that helps you turn a set [Liquid](https://github.com/Shopify/liquid/wiki) templates and markdown files into a completely static HTML site. -- * Jekyll includes Sass, so it'll parse and compile your SCSS files for you. -- * Pages have YAML Front Matter for managing page metadata. -- * Jekyll handles posts like you would expect a blog to, but it also handles custom datasets in a similar way. -- * Deployment is dead simple because your site is _just a folder_. And you can make it easier with [jekyll-hook](https://github.com/developmentseed/jekyll-hook). It's literally automated deployment. --- name: jekyll-2 # So now for that Drupal edge case . . . # We've talked about how Drupal is overkill for a small, static site that will only be updated by web developers. -- However, Jekyll is perfect for this use case: -- * There are no secuity updates. It's all static. -- * There's less performance overhead. PHP doesn't interpret anything. -- * No database is required. Save those resources for more critical things. -- * As long as you have your Jekyll site under version control, there's no reason to have automatic backups for it. -- Have a department IT blog? Jekyll can handle that without a problem. --- name: questions class: middle, center # Questions? Discussion? #