Podcasts about pythonista

Balancing Innovation and Ethics in EdTech with Kelly Schuster-Paredes Join me for a great conversation with Kelly Schuster-Paredes, a veteran educator and computer science teacher, as we dive into the world of AI, coding, and the future of education. Kelly shares her unique journey from science teacher to Pythonista and offers valuable perspectives on navigating the rapidly evolving landscape of educational technology. You can also listen to Kelly and Sean on the Teaching Python Podcast Timestamps: 0:00 - Introduction 1:32 - Kelly's background and transition into computer science 5:08 - Experiences with ChatGPT and AI in education 11:14 - Addressing concerns and establishing guidelines for AI use in schools 16:37 - The importance of understanding AI's capabilities and limitations 23:01 - Training teachers to effectively utilize AI tools 28:30 - Fostering creativity and student ownership in the age of AI 35:23 - Addressing bias and the need for diverse training data in AI models 40:11 - Student perspectives on AI and its impact on learning 44:57 - Striking a balance between innovation and data security 47:26 - Kelly's kryptonite in the current state of education 50:50 - Importance of lifelong learning and staying curious 52:18 - Kelly's dream job and the joy of sharing knowledge 54:48 - Kelly's podcast, "Teaching Python," and its mission to support educators Don't miss this thought-provoking episode as we explore the challenges and opportunities presented by AI in the classroom. ➡️Be sure to subscribe to the My EdTech Life podcast for more inspiring conversations with innovative educators worldwide. --- Support this podcast: https://podcasters.spotify.com/pod/show/myedtechlife/support

Watch on YouTube About the show Sponsored by us! Support our work through: Our courses at Talk Python Training Test & Code Podcast Patreon Supporters Connect with the hosts Michael: @mkennedy@fosstodon.org Brian: @brianokken@fosstodon.org Show: @pythonbytes@fosstodon.org Join us on YouTube at pythonbytes.fm/live to be part of the audience. Usually Tuesdays at 11am PT. Older video versions available there too. Brian #1: The Basics of Python Packaging in Early 2023 Jay Qi Good description of a minimal-ish pyproject.toml file, which includes a build backend and project metadata. That's all you need for a Python-only project. Discussion of how to choose a build backend. Mostly it's baed on extra features you might want, like hatchling's include/exclude features for source distributions. Some discussion of frontend choices. Nice discussion of non-Python-only builds. Specifically, if you need to compile C or C++ extensions, you can use scikit-build-core, or meson-python, or setuptools. Related: "Sharing is Caring - Sharing pytest Fixtures" by Brian Okken (PyCascades 2023) My PyCascades 2023 on packaging pytest plugins is up on YouTube Michael #2: vecs via Oli Python collection-like interface to storing and searching vectors in postgres. Vector search is a key component in building AI chatbots, and semantic document search. If you're familiar with the space, it's effectively Pinecone built on free OSS It's under the Supabase github org but it's fully open source, and compatible with any pgvector vendor, e.g. RDS, or locally in docker If you're on macOS and need Postgres, Postgres App is a good option. Brian #3: Introducing Grasshopper - An Open Source Python Library for Load Testing Jacob Fiola “Grasshopper is a library for automated load testing, written in Python.” Open source project from Alteryx, On GitHub and PyPI under the name locust-grasshopper Built on Locust. Adds Tag-based suites for trend analysis and evaluating changes. Custom trends. Useful for actions that span multiple http calls, and you want to see timing trends for the whole action. Checks. Checks validate boolean conditions in the test. Custom tagging for all metrics Send data to time series db & dashboards. Thresholds. Reporting results to other locations. Some reusable base classes that take care of the majority of the boilerplate that tests often contain Readme has a very thorough introduction including configuration and samples. Michael #4: memocast by Daniel Engvall A small iOS app for e.g. iPhone that allow you to add links heard in podcasts into reminders. Good example of how to use Pythonista to build python scripts for iOS Pythonista just made an update (2 weeks ago) so that'd use Python 3.10 on the iOS which makes it even more interesting. Extras Brian: Help test Python 3.12 beta! Python Language Summit write-ups available PyPI was subpoenaed Michael: You Can Ignore This Post Joke: Careful or you might end up summoning a demon.

GUI-Applikationen am Beispiel von MiaPlan 4. Mai 2023, Jochen Episode Nummer 50, wow

Welcome back to another Pybites podcast episode. In this episode we talk about common pitfalls you want to avoid when becoming a Python developer:Pitfall #1: Tutorial paralysisPitfall #2: Improper sequencingPitfall #3: Obsessing over Pythonic codePitfall #4: Going on your own for too long... after that we look at the 80/20 (aka "Pareto") to focus on  to become a well-rounded Python developer:80/20 Rule #1: Work on bigger projects80/20 Rule #2: Build a portfolio80/20 Rule #3: Work with experienced developers80/20 Rule #4: Become a content provider---If this resonates with you and you want to better your career as a Pythonista, book us in for a career chat: https://go.oncehub.com/pybitesThanks for listening,  Any feedback, write us an email to info@pybit.esWe'll be back next week!

Perché i programmatori hanno il vizio di fare dei progetti personali nel tempo libero? Conosciamo Juna Salviati che ha una lunga esperienza di piccoli o grandi progetti personali. Ce ne racconterà alcuni e scopriremo che valore hanno nella carriera di un Pythonista. Nella puntata abbiamo parlato di - Mazes for programmers - Model Thinking su Coursera

In this segment you will learn how to make a simple Twitter bot to query for a term and retweet posts that include it. This video goes through the process of setting up a Twitter Developer account (though the interface has seen a few updates), as well as Python Coding using the Twython module for API calls. I'm running the script from my iPhone running the iOS mobile app Pythonista. Read this as an article on Medium: https://medium.com/@mdf_365/how-to-create-a-twitter-bot-b94d8abaabc8 --- Send in a voice message: https://anchor.fm/mdf-365/message Support this podcast: https://anchor.fm/mdf-365/support

Today we have Thomas Gaigher (creator of pypyr) back on the show to talk about debugging. We hit on various important areas:- Visualization.- The debugging process.- Tracking and tracing.- Preventative measures.We even unexpectedly (and interestingly) spoke about design patterns. We hope you enjoy the show.Mentioned resources:- A debugging tale PyBites article- Thomas' first appearance on the podcastBooks mentioned:- Metropolitan novel- Design patterns (Gang of Four)Reach out to Thomas:- Twitter- PyBites Slack---Are you serious about taking your Python career to the next level? Our PDM program takes you from scripter to proficient Pythonista in just 10 weeks. You'll become an effective developer that writes robust software and knows how to market those skills well. Does that sound appealing to you? If so, book us in for a chat and we'll see how PDM would look for you, based on your individual needs and goals ...

Welcome back to the PyBites Podcast. In this episode we invited Ed Garcia to share his inspiring journey of becoming a Python developer.He joined PDM almost a year ago as a beginning Pythonista and has built a couple of projects end-to-end boosting his skills and with that his confidence. His latest app is a complete SAAS business idea turned into reality! He also contributed to PyBites OpenSource and is an active member of the PyBites community.Ed put in the hard work, it wasn't easy, he could have given up on more than one occasion. But he didn't! Listening to Ed's story we see important lessons we often teach: don't get stuck in tutorial paralysis, start building, persist / adopt a positive mindset, don't let imposter syndrome stop you in your tracks, embrace it! Be coachable and accept that there is always more to learn, that apps are never done and that's ok (drop perfectionism!) We hope his journey will inspire you to aim higher and to ruthlessly go after your goals, you can do it!Check out Ed's MaxUptime app and WorldClock cli tool / contribution.What we're reading:A Curious MoonInvent Your Own Computer Games with PythonThe Obstacle is the Way The Slight EdgeReach out to Ed on PyBites Slack and/or LinkedIN.

Conosciamo Andrea Biancini, formatore e Data Science Project Manager nella Commissione Europea. Parleremo di politica data-driven e formazione

This week we speak to our fellow PDM-er, Pythonista and friend Ryan Austin about  The Payroll App he just released.What does the app do? How did he tackle coding such a complex app? What were some of the struggles? And what about the mindset he had to apply to get through it all? As usual we also talk wins and books of course.Enjoy and we hope this inspires you to build your own app / project / side gig. There is nothing more satisfying that that and it's an asset on your  resume / for your career. So we challenge you: find a niche and start building a solution. If you need help come talk to us.Resources / links:Mentioned beautiful quote from Henry Wadsworth Longfellow: "The heights by great men reached and kept were not attained by sudden flight, but they, while their companions slept, were toiling upward in the night."Ryan's last appearance on the PyBites podcast where we spoke about following your dreams.Our Time for a break episode where we talk about the benefit of switching off.Ryan used PyBites Tools for AWS S3 uploads.Ryan built this inside PDM. You can learn more about our coaching program here. Books: The Code Breaker / Night / The Phantom Atlas / Skin in the gameGet in touch with Ryan via Twitter or the PyBites Community.And again, check out Ryan's app here.Thanks for listening!

Tässä jaksossa keskustelemme taustajärjestelmäkehityksen skaalauksesta tiiminäkökulmasta. Miten ohjelmistoa voidaan tehokkaasti kehittää, kun tuotekehitystiimejä on kymmeniä ja tiimien määrä tuplaantuu vuosittain. Jakson vieraaksi olemme saaneet Woltilta Jerry Pussisen, joka toimii Competence Leadina Python-teknologiaan liittyen. Pureudumme muun muassa tyypityksen hyötyihin Python-ohjelmointikielessä ja siihen miten autonomiset tiimit toimivat ilman erillistä arkkitehtiroolia.Hyväksi havaittuja periaatteita kehittämiseen isossa skaalassa:tiimien autonomiapalvelujen ja/tai repojen omistajuustiimienvälisen keskustelun fasilitaattoritohjelmointikielen tyypitys, esim tyyppivinkit PythonissaLinkkejä:Python-ohjelmointikieli: https://www.python.org/Kotlin-ohjelmointikieli: https://kotlinlang.org/Jerryn Helsinki Python meetup -esitys tyyppiturvallisesta Pythonista: https://www.youtube.com/watch?v=tKy1idOUW8sStaattinen tyyppitarkistaja mypy: https://mypy.readthedocs.io/en/stable/Type stubs -tiedostot: https://mypy.readthedocs.io/en/stable/stubs.htmlVierasJerry Pussinen, Wolt: @JerryPussinenJuontajat Markus Hjort: @mhjortYrjö Kari-Koskinen: @ykarikos Seuraa podcastia Kotisivu: https://koodiapinnanalla.fi/Twitter: @KoodiPinnanAllaSähköposti: koodaillaan@koodiapinnanalla.fiAnna palautetta podcastista

Michael Kennedy (@mkennedy) returns to the show to talk about Pydantic, a Python library that works with data validation and settings management using Python type annotations. Michael joined us previously to discuss Python's async and await implementations and we are excited to have him back to dive more into all things Python. Michael is a Python and MongoDB enthusiast, has two amazing Python podcasts (Talk Python to Me and Python Bytes), is a trainer, entrepeneur and a Python Software Foundation Fellow. On his website training.talkpython.fm, you can find training videos on Python, DevOps, Front End development and API creation, and more! If you are a beginner just jumping into Python, or even an advanced Pythonista, we highly recommend following Michael and checking out his podcasts and websites. Enjoy the show! Resources: https://talkpython.fm/ https://training.talkpython.fm/ https://pythonbytes.fm/ https://pydantic-docs.helpmanual.io/ https://www.youtube.com/watch?v=A-3_Iw6KNCw https://www.youtube.com/watch?v=6SJ26Q_8Hxc https://github.com/mikeckennedy https://www.python.org/psf/members/

Conosciamo Lorenzo Mele, Python Developer e Technical Leader in Revolut. Non parleremo solo di fintech, ma Lorenzo ci racconterà anche le ultime novità da Python Italia

Guest Mr. Matt Lebrun of YoungCTO Rafi Quisumbing I'm a Software Engineer, Python Trainer, and Tech Community Leader. I've been working in the industry as a Software Engineer for more than 10 years. During this time I've worked in various industries, startups, and the academe. https://www.linkedin.com/in/cr8ivecod...​ In 2013, I co-founded Python.PH, Inc., a non-profit organization that caters to a community of professionals and hobbyists of the Python programming language. My passion and dedication for community work was recognized by the Python Software Foundation who honored me as a Fellow Member in 2019. The software industry has been a perfect fit for my passion for learning and building things. It is a medium for boundless possibilities not only for building creative things but also utilities that drive businesses forward. It is this enthusiasm that I bring when I conduct my consultations and training for the individuals and companies that I work with.

Guest Doctor Sony Valdez, DICT of YoungCTO Rafi Quisumbing Sony is a freelance programmer specializing in Python. He is a current board member of Python Philippines. He plays video games and is completely harmless. Python Philippines: http://python.ph/​ Twitter: https://twitter.com/mrvaldez​ Dragon Ball Fighting https://www.facebook.com/groups/dbfzph/​ Gaming Group/Channel https://www.facebook.com/MamaMoGaming...​

Watch the live stream: Watch on YouTube About the show Sponsored by us! Support our work through: Our courses at Talk Python Training pytest book Patreon Supporters Special guest: Marlene Mhangami Brian #1: readme.so Recommended by Johnny Metz This is not only useful, it’s fun Interactively create a README.md file Suggested sections great There are lots of sections though, so really only pick the ones you are willing to fill in. I think this is nicer than the old stand by of “copying the README.md of another project” because that other project might not have some of these great sections, like: Acknowledgements API Reference Authors FAQ Features Logo Roadmap Usage/Examples Running Tests Note, these sections are listed in alphabetical order, not necessarily the right order for how they should go in your README.md Produces a markdown file you can copy or download Also an editor so you can edit right there. (But I’d probably throw together the skeleton with dummy text and edit it in something with vim emulation. Michael #2: Wafer-scale Python via Galen Swint Many new processors with the sole purpose of accelerating artificial intelligence and machine learning workloads. Cerebras, a chip company, built an AI-oriented chip that is 12”x12” (30cm^2) with 850,000 AI cores on board. Another way to look at it is that’s 2.6T transistors vs. my M1’s 0.0016T. Built through TSMC, as so many things seem to be these days. What’s the Python angle here? A key to the design is the custom graph compiler, that takes PyTorch or TensorFlow and maps each layer to a physical part of the chip, allowing for asynchronous compute as the data flows through. Shipping soon for just $3M+. Marlene #3: RAPIDS This is the library I’m currently working on at NVIDIA. I work specifically on CuDF which is a Python GPU DataFrame library for loading, joining, aggregating, filtering, and manipulating tabular data using a DataFrame style API. It mirrors the Pandas API but operations are done on the GPU I gave a talk at PyCon Sweden a few months ago called ‘A Beginners Guide to GPU’s for Pythonista’s’. Here’s an example of how long it takes for pandas vs. cudf to calculate the mean of a group of numbers in a column in a DataFrame: #we'll be calculating the mean of the data in a dataframe (table) import cudf import pandas as pd import numpy as np import time #lets create a data frame using pandas, that has two columns, a and b #we're generating a dataframe where each column contains one hundred million rows #each row is filled with a random integer that can be between 0 to one hundred million pandas_df = pd.DataFrame({"a": np.random.randint(0, 100000000, size=100000000), "b": np.random.randint(0, 100000000, size=100000000)}) #next we want to create a cudf version of this dataframe cudf_df = cudf.DataFrame.from_pandas(pandas_df) #now we'll use timeit to compare the time it takes to calculate the mean #of the numbers in the column "a" of the dataframe. #Lets time Pandas %timeit pandas_df.a.mean() #Lets time CuDF %timeit cudf_df.a.mean() #These were the results I got (might be a little slower if you're using the notebook on Colab) # pandas: 105 ms ± 298 µs per loop (mean ± std. dev. of 7 runs, 10 loops each) #cudf: 1.83 ms ± 4.51 µs per loop (mean ± std. dev. of 7 runs, 1000 loops each) You can test this out for right now using the RAPIDS, GPU powered notebook for free on Google Colab. Brian #4: datefinder and dateutil Recommended by Ira Horecka Great calmcode.io video on datefinder Neat use of comprehensions to explore sending a bunch of data into a tool: import datefinder date_strings = [ "March 12 2010", "2010-03-12", "03/12/2010 12:42:12" ] [list(datefinder.find_dates(d)) for d in date_strings] # [[datetime.datetime(2010, 3, 12, 0, 0)], # [datetime.datetime(2010, 3, 12, 0, 0)], # [datetime.datetime(2010, 3, 12, 12, 42, 12)]] Nice focused library, used by 662 projects, according to GitHub datefinder finds dates in strings, then uses dateutil to parse them into datetime objects. dateutil is actually kind of amazing also, great for parsing date strings computing relative delas (next month, last week of the month, etc) relative deltas between date and/or datetimes amazing timezone support comprehensive test suite nice mix of both pytest and unittest. I’ll have to ask Paul Ganssle about that sometime. Michael #5: Cinder - Instagram's performance oriented fork of CPython via Anthony Shaw Instagram's performance oriented fork of CPython. They use a multi-process webserver architecture; the parent process starts, performs initialization work (e.g. loading code), and forks tens of worker processes to handle client requests. The overhead due to copy-on-write from reference counting long-lived objects turned out to be significant. They developed a solution called "immortal instances" to provide a way to opt-out objects from reference counting. "Shadowcode" or “shadow bytecode" is their inline caching implementation. It observes particular optimizable cases in the execution of generic Python opcodes and (for hot functions) dynamically replaces those opcodes with specialized versions. Eager coroutine evaluation: If a call to an async function is immediately awaited, we immediately execute the called function up to its first await. The Cinder JIT is a method-at-a-time custom JIT implemented in C++. And can achieve 1.5-4x speed improvements on many Python performance benchmarks. Strict modules is a few things rolled into one Static Python is an experimental bytecode compiler that makes use of type annotations to emit type-specialized and type-checked Python bytecode. Static Python plus Cinder JIT achieves 7x the performance of stock CPython on a typed version of the Richards benchmark. Marlene #6: PyCon US 2021 PyCon US starts today. Its the largest gathering of the Python community on earth! I’ll be hosting the Diversity and Inclusion Work Group Meet and Greet. I recently became the chair of this WG, which focuses on helping increase global diversity and inclusion in the python community. We’ll be going live on the main stage at PyCon on Saturday 15 May at 12pm EST. There will be lots of time for discussion, so I hope to see some of you there! I’ll also be hosting the PSF EMEA members meeting, which will be on Saturday at 10am CAT. You can register on the Meet up page or watch the livestream on the PSF Youtube channel. You can also find me in the PSF booth on Friday and Saturday morning, if you’d like to meet there! Some other talks I’m looking forward to attending are: Python Performance at Scale - Making Python Faster at Instagram More Fun With Hardware and CircuitPython - IoT, Wearables, and more! Large Scale Data Validation (with Spark and Dask) Registration will be open all through the conference, so if you haven’t yet you can register here And of course all the keynotes this year! Extras Michael Keep your fork in sync at GitHub Flask 2.0 is out! (Just interviewed David and Phil for Talk Python) (thanks Adam Parkin) New Major Versions Released! Flask 2.0, Werkzeug 2.0, Jinja 3.0, Click 8.0, ItsDangerous 2.0, and MarkupSafe 2.0 Brian Lots of great feedback about last weeks Test & Code interview with Brett Cannon about packaging. I’m glad it was helpful to people. This week I’m talking with Ryan Howard about Playwright for automated browser testing. Did you know we have 71 patrons on patreon? So cool. You too can support the show at patreon.com/pythonbytes Marlene If you’d like to connect you can find me on twitter @marlene_zw You can also check out my site marlenemhangami.com Joke

This week we talk with Sarah Gencarelli, animation director @ Cartoon Network and avid Pythonista and member of the PyBites community. We talk about how surprisingly common art creation and programming are!Sarah also shares how applying a creative mindset can help you as a developer.We had a blast, we hope you too!If you want to connect with Sarah you can do so here:https://www.instagram.com/sarah_gencarelli/https://pybit.es/community

Elyézer Rezende é Principal Software Quality Engineer na Red Hat Inc., apresentador do Castálio Podcast, um dos mais tradicionais podcasts de tecnologia do Brasil, Pythonista desde 2008, usuário Vim, entusiasta de Software Open Source e Pai. Atualmente mora nos Estados Unidos e nas horas vagas gosta de apreciar uma boa cerveja. Links Twitter do Elyézer Vimcast Livros Dive into Python 3 Python Fluente Practical Vim Filmes The Avengers The Mandalorian Música Linking Park Grey Daze DJ Hardwell - Never Say Goodbye Cervejas Delirium Eisenbahn Rocket Science Blue Moon OsProgramadores Site do OsProgramadores Grupo do OsProgramadores no Telegram Canal do Youtube do OsProgramadores Twitter do Marcelo Pinheiro

Tania Allard is much more than a research software engineer, fostering community growth, and excitement for open source.

En este episodio comparto la aventura de mis pequeños en el mundo de la computación y la programación. Hago referencia a algunas de las aplicaciones que han usado y de cómo le dí un nuevo propósito a dos viejas Mac para que los niños inicien una nueva etapa programando en Python. Enlaces de interés: Scratch Jr: https://www.scratchjr.org/ Scratch: https://scratch.mit.edu/ Code Spark: https://codespark.com/ Hopscotch: https://www.gethopscotch.com/ Pythonista: http://omz-software.com/pythonista/ Kano: https://kano.me/us Screentime / Downtime: https://mashtips.com/ios-screentime-downtime/ Hour of Code: https://code.org/hourofcode/overview Conéctate: - Twitter: https://twitter.com/sehablacodigo - Twitter (personal): https://twitter.com/dkvsky - Instagram: https://www.instagram.com/sehablacodigo/ - Anchor: https://anchor.fm/sehablacodigo --- Send in a voice message: https://anchor.fm/sehablacodigo/message

Episode 6 ShowNotes About: Charty (companion app) - with creator Rodrigo Araujo If you have a question for us just send us a message on Anchor, DM on Twitter, message on our Discord server, or in our category on the Shortcuts discord server, and we'll answer it in the coming episodes. We recently started our new sponsorship program through Anchor, so if you enjoy the show and want to help us keep the episodes going, you can head over to https://anchor.fm/shortcasts/support, we really appreciate any feedback and support we get on the show We have our iMessage sticker pack available if you weren't aware, you can check it out on the iMessage App Store (https://apps.apple.com/us/app/shortcasts-stickers/id1499929222?app=messages) In today's episode we cover the new app called Charty (https://apps.apple.com/us/app/id1494386093) Discussion with Rodrigo: The project started in the end of 2019 and released the app today! What device or devices do you utilize the most for shortcut editing and creation? I should be using my iPad more, but it always seems it’s too far to get, so I end up using my iPhone and trying everything here. It’s an iPhone 8 Plus that I plan to replace this year What kind of background do you have? I have a degree in computer engineering and a masters in oil engineering, and my daily job is at Petrobras, the Brazilian oil extraction company. What got you started in Shortcuts? I’ve always longed for a way to program on iOS! I’ve used Pythonista, and love it. But when Workflow came out, it was a breakthrough. Before it was acquired by Apple and even before iOS 13, workflows and shortcuts were pretty limited. But I remember setting up a whole double entry accounting system with my brother using only 1 writer text files and shortcut actions. Do you have any future update plans moving forward? I do! I’m far from finished on Charty. I want to add area and bubble charts and histograms on a future release. Also, better themes, more icons and more shortcuts are all on the roadmap. Were you a user of the workflow app before it was purchased by Apple and turned into Shortcuts? Yes! They were great ever since they launched, but to me, the breakthrough came with Magic Variables and Federico Viticci’s coverage. What do you think about the future of Shortcuts? And iOS? For the iPhone, I hope for better automation features, especially ones that could run independently from users interaction. This way, the iPhone could become a real ethereal key for our connected world. What is your preferred method for support contact? The best ways to reach are on Twitter, either @chartyios (https://twitter.com/chartyios) if you’d like to discuss the app, or @rodrigoaraujo (https://twitter.com/rodrigoaraujo) for everything else End of Episode We don't really have our next episode ready yet, but stay tuned for more information and for any upcoming giveaways --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app --- Send in a voice message: https://anchor.fm/shortcasts/message Support this podcast: https://anchor.fm/shortcasts/support

Let's look at another programming language we use at bol.com: Python. At bol.com we use Python for Tools, Data Science and more. It has been around since 1991.What this episode coversIt was created by a Dutch guy: Guido van Rossum. Its design philosophy emphasizes code readability. The language's core philosophy is summarized in the document The Zen of Python (PEP 20), which includes aphorisms such as:Beautiful is better than ugly.Explicit is better than implicit.Simple is better than complex.Complex is better than complicated.Readability counts.All well, but what do we do with it? What do we use it for?In the earlier episode “How we tame Google Cloud resources with R2D2” we discussed the Deployment tool we built for our Software Engineers. This tool has been built in Python.But we do more great stuff in bol.com with python, at least that's what we heard in our tech community. We asked around and, not surprisingly, ended up in the Data Science area. So time to introduce our guests to the show….GuestsOlaf Meuwese – A software engineer who has worked mostly with and in Data Science teams in the last years.Bas Dunn – Data scientist, econometrician in Assortment and earlier in Partner Performance Management.Jasper Adegeest - Data scientist, since September 2019 at bol.com in the Personalization team.NotesThe zen of PythonPythonic: When a veteran Python developer (a Pythonista) calls portions of code not “Pythonic”, they usually mean that these lines of code do not follow the common guidelines and fail to express its intent in what is considered the best (hear: most readable) way.SKlearn: Machine learning module for PythonTensorflow: The core open source library to help you develop and train ML modelsDatawarehouse bigqueryJupyter Notebook: The Jupyter Notebook is an open-source web application that allows you to create and share documents that contain live code, equations, visualizations and narrative text.Flask: a lightweight WSGI web application frameworkFastapi: a modern, fast (high-performance), web framework for building APIs with Python 3.6+ based on standard Python type hints.Django: a high-level Python Web framework that encourages rapid development and clean, pragmatic designAxle - the opinionated framework to build Java apps within bol.com

Revisit the early days of Travis Oliphant's contributions to scientific Python and by extension Python's relevance to AI. Catch-up on the high energy, current efforts of the creator of NumPy, SciPy, Numba, and Conda. Travis also founded the NumFOCUS Foundation. NumFOCUS is backing Jupyter and Pandas. In this Episode, we break our 26.1 Minutes rule for a really great and important chat with this legend of Data Science. Enjoy an extra few minutes.

Quail Data #0007 - Stats Wars Rodolfo #1: MOSP MONARC Objects Sharing Platform (MOSP) es una plataforma para crear, editar y compartir objetos JSON validados de cualquier tipo. MONARC - Method for an Optimised aNAlysis of Risks by CASES (Método para un análisis optimizado de riesgos por CASOS.) Puede usar cualquier esquema JSON disponible para crear nuevos objetos JSON a través de un formulario web generado dinámicamente y basado en el esquema seleccionado. Sergio #2: Scikit Geometry "scikit-geometry también viene con funciones para calcular el diagrama de Voronoi, el casco convexo, cuadros delimitadores, la suma minkowski de dos polígonos, un árbol AABB para consultas vecinas más cercanas y muchas otras utilidades útiles para cálculos geométricos, con planes para agregar muchos más!" Rodolfo #3: pandapy Demos un momento para tomar en cuenta el siguiente meme: https://www.reddit.com/r/mathmemes/comments/ewct2v/euler_moment/ Ahora, ¿recuerdan, por una parte a Pandas? Y por otra parte, ¿a NumPy? Pues bueno, pueden pensar en este paquete como un hijo de ambos. PandaPy tiene la velocidad de NumPy y la usabilidad de Pandas (10x a 50x más rápido). Así como importas pandas como pd y numpy como np, el común es importar a pandapy como pp (ya sabes → pd & np = pp). Sergio #4: Como hacer tu propio blog sin ser un experto en computadoras con fast.ai y fast_template Una guía muy fácil de seguir para crear tu propio blog hosteado en GitHub pages sin tener que usar la linea de comando. Es muy practico y facil de seguir y ahora utiliza GitHub Actions para transformar tus notebooks de jupyter a blog posts Rodolfo #5: Construyendo un Python Data Science Container usando Docker Es un blog post que ilustra cómo crear un contenedor de Docker que incluya paquetería como NumPy, SciPy, Pandas, SciKit-Learn, Matplotlib y NLTK. Todo se realiza a través de la construcción de un Dockerfile basado en Alpine, una versión muuuy ligera de Linux. El post te da todos los comandos para levantar el contenedor. Sergio #6: Blog de Juvenal Campos - Como Visualizar Pirámides de Población en R Un paso a paso de como construir una piramide de poblacion con ggplot2 Juvenal usa blogdown de R para este blog - todxs deberiamos bloguear mas! Extras: Sergio: Lorem Ipsum pero mexicano ? jajaja https://ignaciochavez.com/projects/lorempaisum/ RStudioConf está aquí en San Francisco esta semana y tienen los materiales de sus talleres en GitHub pa quién no pudo asistir: https://github.com/rstudio-conf-2020 Rodo: Para la gente Pythonista que nos escucha, ¡ya hay fecha para el PyCon Latam 2020! 27-29 de agosto, Pto. Vallarta, Jalisco. ¡No se lo pueden perder! (https://twitter.com/PyLatam/status/1221886633210982402) Meme de la semana --- This episode is sponsored by · Anchor: The easiest way to make a podcast. https://anchor.fm/app --- Send in a voice message: https://anchor.fm/quaildata/message Support this podcast: https://anchor.fm/quaildata/support

In this episode, Kelly and Sean meet Bob and Julian from PyBit.es to discuss strategies, and how to seek advice and motivation when learning Python. Bob is a driven Pythonista working as a software developer at Oracle.. Bob is passionate about automation, data, web development, code quality, and mentoring other developers.” Julian is a Data Centre Technician at Amazon Web Services. He started coding a few years ago and codes for fun and to solve everyday projects. Together they founded PyBites, a Python blog featuring code challenges, articles, and news. Special Guests: Bob Belderbos and Julian Sequeira.

Heute haben wir uns mit Niklas und Dodo getroffen, die im Chaosdorf die Python-Einsteigerveranstaltung betreuen, und über ihren Kurs sowie ganz allgemein über Einstiege in Python gesprochen. Shownotes Unsere E-Mail für Fragen, Anregungen & Kommentare: hallo@python-podcast.de Allgemein Python Anfängerkurs im Chaosdorf: PythonfooLite github repo Pyddf telegram channel PEP 505 -- None-aware operators huepy Benthams algorithm News aus der Szene Data Classes Namedtuples Python 3.8 alpha - walrus operator Python steering council gewählt Python local packages Quellen für News über Python Planet Python Awesome Python Import Python Python Weekly Github: Trending Python Repositories bzw Trending Repos Subscription Picks Pathlib Sqlparse Pythonista Kivy Termux GPIO Disassembler for Python bytecode Requests: HTTP for Humans Asynchronous HTTP Client/Server for asyncio and Python A Web Crawler With asyncio Coroutines

Episode 8: 1. Code [dot] org for K - 12, free computer science lessons & online coding labs. 2. Invent with Python [dot] com author & coder Al Sweigart's website, free online versions of his published books. 3. Python [dot] org the Pythonista mothership. Download (for free) the latest version of Python for Windows, Mac OS, or Linux. 4. CS First [dot] with Google [dot] com Google's free computer science curriculum for kids (9 - 14). CS First with Scratch 3.0 launches on Jan. 2, 2019. Next episode: What Should a CFK (Coding For Kids) Curriculum Look Like. Web pythonfumasters.com | Facebook @pythonfumasters | Instagram @masterhun

Thea Flowers is a Pythonista and open source advocate. She helps empower developers of all backgrounds and experience levels using Python and open source software and hardware. Thea is the creator of Nox, the co-chair of PyCascades 2019, the lead maintainer of urllib3, and a member of the Python Packaging Authority and Packaging Working Group. Thea works on Google Cloud Platform's wonderful Developer Relations team where she works on API client libraries and community outreach. All of that is definitely cool enough. But she is also building a synthesiser based on Sega Genesis chips. So of course, that's where we'll start the conversation. Special Guest: Thea Flowers.

Vicky Lee is a self-described ‘Pythonista’. She’s a software engineer and community organizer who began organizing events in order to bring people together and create a sense of community. In this episode, Vicky describes how she fell into the diversity-driven sphere of tech, and tells us about her first venture into organizing meetups—which, perhaps surprisingly, stemmed from her forum for Irish-born Chinese people and the difficulties she encountered with her first tech event, Python Ireland. Vicky also delves into why you should never ever put all of your eggs into one basket,  discusses the importance of working well with business partners (even if they are your actual partner!), and why a great community is so crucial for a great event.   Learn more about Vicky here. To get a weekly dose of public speaking tips, information, videos of great talks, conference news, book reviews and more, sign up to the Voxgig newsletter. View all show notes, links, and more brilliant public speaking resources at voxgig.com. If you like what you hear on Fireside with Voxgig, don’t be shy―tell everyone! Use  #firesidewithvoxgig on your social media.

Vicky Lee is a self-described ‘Pythonista'. She's a software engineer and community organizer who began organizing events in order to bring people together and create a sense of community. In this episode, Vicky describes how she fell into the diversity-driven sphere of tech, and tells us about her first venture into organizing meetups—which, perhaps surprisingly, stemmed from her forum for Irish-born Chinese people and the difficulties she encountered with her first tech event, Python Ireland. Vicky also delves into why you should never ever put all of your eggs into one basket,  discusses the importance of working well with business partners (even if they are your actual partner!), and why a great community is so crucial for a great event.   Learn more about Vicky here. To get a weekly dose of public speaking tips, information, videos of great talks, conference news, book reviews and more, sign up to the Voxgig newsletter. View all show notes, links, and more brilliant public speaking resources at voxgig.com. If you like what you hear on Fireside with Voxgig, don't be shy―tell everyone! Use  #firesidewithvoxgig on your social media.

In this grand season finale of Stacktrace, John and Gui review the iPad Smart Keyboard Folio, Apple Watch Series 4, discuss entitlements, electrocardiograms and reveal the latest spelunking findings including (and we’re not kidding) - new details about AirPower. Stacktrace by 9to5Mac is available on iTunes and Apple’s Podcasts app or through our dedicated RSS feed for Overcast and other podcast players. Hosts: Gui on Twitter: @_inside John on Twitter: @johnsundell Topics: The Swift Alps New iPhone Smart Battery Case Swift by Sundell sponsorship Scriptable JSBox Pythonista Carrot Weather HomeRun AirPower patent application Taccy GitX Visual Studio Code Elevation Dock

Jake VanderPlas, a data science fellow at the University of Washington's eScience Institute, astronomer, open source beast and renowned Pythonista, joins Hugo to speak about data science, astronomy, the open source development world and the importance of interdisciplinary conversations to data science.

Logan Wright works at Vapor, which builds the open source Swift web framework, as well as Vapor Cloud. We talk about Vapor, Vapor Cloud, Vapor 3.0, the State of Server Side Swift and much more. Enjoy!   ANNOUCEMENTS   Interested in starting your own Learn Swift {CITY} meet up? Contact me @garricn on Twitter.   LINKS   - Logan on Twitter: https://twitter.com/logmaestro - Vapor: https://vapor.codes - Vapor Cloud: https://vapor.cloud - Vapor Slack Team: http://vapor.team - Vapor article via Medium: https://medium.com/@LogMaestro/server-side-swift-c965b7ebe6e7 - Tanner: http://tanner.xyz - Laravel: https://laravel.com - Swift Server Working Group: https://swift.org/blog/server-api-workgroup/ - Nodes: https://www.nodesagency.com - Node HTTP Parser - https://github.com/nodejs/http-parser - Pythonista - http://omz-software.com/pythonista/ - Intrepid: http://www.intrepid.io - Intrepid iOS Apprentice: https://jobs.lever.co/intrepid/7ab52936-a915-4554-9ee6-8e4ab9b8eac8  - iOS Developers HQ Slack Team: https://ios-developers.io   Listen on iTunes. Support this podcast via Patreon. Questions, comments, or you just wanna say Hi? Contact your host @garricn on Twitter. This episode was recorded using the Cast platform by @JulianLepinski. Wanna start your own podcast? Try Cast!  

Steve Klabnik @steveklabnik | Blog | GitHub Show Notes: 02:56 - Getting Into Rust 05:51 - Working on Rust for Mozilla 07:01 - Writing Documentation and Preventing Burnout 13:24 - The Rust Programming Language 18:45 - Rewriting Firefox in Rust 21:20 - High-level Functions 25:23 - Typesystem and Concurrency 36:35 - Rust and Web Developers; Digging Into Rust on a Deeper Level 43:46 - The Rust Ecosystem and Using Rust on a Day-to-Day Basis 48:38 - The Rust Book Resources: Rust For Rubyists Cargo Servo Application Binary Interface (ABI) MetaLanguage (ML) Tokio Systems Programming intermezzOS Steve Klabnik: Exploring Ruby Through Rust What's new with “The Rust Programming Language”? rustbook Transcript: CHARLES: Hello everybody and welcome to The Frontside Podcast episode 51. I'm here, my name is Charles Lowell. I'll be hosting today. With me is Chris Freeman, also of The Frontside and with us is Steve Klabnik. Now, most of you probably heard of Steve before. My first encounter with Steve was actually at the LoneStarRuby Conference back in... Gosh, I don't know. It was many, many years ago and he was giving a talk on Shoes, which I also had never heard of before. It was a wonderful story of a code archaeology project where he was kind of investigating, rehabilitating, and in carrying forward a project that the 'why the lucky stiff' had done. That was a wonderful introduction but it was certainly not the last time that I encountered him in his writings and in talks and stuff, mostly within the Ruby community. But it popped up again and again, talking about Rust APIs and always making a point to take a good knowledge that he'd learned and spread it around. Personally, I've lost track of Steve or hadn't really heard much of what he was doing for a while. But then Chris came into the office and he was always talking about this language called Rust. While I've heard Rust, Chris was just all about it and wanted to have Steve come on the show because it turns out that Steve, you've been really, really, really into Rust these last few years and sounds like concentrating most of your work there. STEVE: That is totally true and accurate. Also to go back a bit, that means that you are in attendance for my very first conference talk ever. CHARLES: Really? STEVE: That was literally the first one. CHARLES: Wow, it was a great start. That was a great story. It was educational and also touching. STEVE: Thank you. It's actually interesting because what happened was is that someone else who works on Shoes have encouraged me to submit to RubyConf and I was like, "Who would want to hear me talk at a conference?" I submitted the talk and RubyConf accepted it and I was really excited. Then a bunch of other conferences noticed and two other conferences had asked me to give a talk before RubyConf happens and LoneStar was one of them and it was the first one chronologically. That moment was also very special to me as well. CHARLES: Fantastic. What year was that? STEVE: I want to say it was like 2012 or 2011. It's really hard for me to pay attention to time and date. My history is so complicated that I often forget. I've literally told people that I'm 10 years old or younger than I am because I would like mess up to date on the things. It just happens. CHARLES: Yeah, but it was a while ago and it's been quite a journey, in between now and then. STEVE: Yeah, definitely and you're also definitely right. It is now literally my day job to work on Rust so it is definitely the focus of most of my efforts. Partly, why I made that happen was because it was the focus of all my hobby efforts before I made my job. It's definitely been a couple of years that I've been a full-time on all the Rust stuff. CHARLES: How was it that you actually got into Rust? How did you hear about it before everybody else and how did it capture your attention? STEVE: I've always liked programming languages and learning different programming languages. Ruby was sort of where I became known professionally. But it wasn't the first language that I knew and I knew it was never going to be the last. As much as I always loved Ruby and I'm like literally have a tattoo on my body so I will be with Ruby forever. I always try to learn new stuff and I find it exciting. I'm from middle of nowhere, Pennsylvania in the suburbs of Pittsburgh on a cattle farm and I was visiting my parents for Christmas one year. There's not really a whole lot to do out of the very small town so I was just reading the internet, as usual and it turns out that that was the day that Rust 0.5 had been released. I saw this release announcement go by and I was like, "I vaguely heard of this programming language once or twice maybe. I don't have anything to do. Let's give it a try." I downloaded and installed it. I looked at their tutorial and the tutorial has a problem that a lot of tutorials had, which is I read it, I said, "This all makes sense," I tried this down to write a program, and I had no idea how to actually write a program in it at all. I'm just completely confused. I couldn't actually apply the sort of syntax stuff that I learned. At the same time, I was going to be working on this hypermedia book -- that was my plans for that trip -- as always, you just rewrite your tooling over and over again. You [inaudible] like, "Just don't write the thing. Write the tools that make the thing," so I wanted to try out a new way to take mark down and generate PDFs in HTML, involving pandoc. I sort of had that all set up and I said, "Well, let me give this a try run. What I'm going to do is I'm going to write down what I learned in Rust as I learned it," and sort of from a Ruby programmers perspective, I'll use that and working with my new tooling to see if it works to actually work on the real book and it will also help me understand Rust better because one of the reasons why I do all this sort of teaching and advocacy is because I think it helps me learn. Just as much as I like helping other people learn stuff, I find that the repetition and being forced to explain something to someone else really make sure that I understand what I'm talking about. That's what the thing called Rust for Rubyist became boring. I'm a sucker for alliteration and that sort of became the first to tutorial for Rust from outside of the Rust projects proper. From there, I went on to submit some pull requests because everything's open source so I wrote some documentation and funny enough, my first ever pull request to Rust was actually rejected based on procedural grounds. At the time, they didn't actually accept pull request to master, they accept this other weird branch and GitHub don't have the ability to re-target the branch of the pull request. I also, always like this story because the thing that I now on the core team of, like my first attempt at getting involved was wrong and was turned down. But I'd fixed that pull request issue and got that in but it is kind of kept working on an open source capacity for a while and then decided to ask Mozilla if I can make it my job. Luckily they said yes. CHARLES: Wow, so what? Your job at Mozilla, like you just kind of showed up and said, "I would like to have a pretty cool, awesome job, working on this brand new language," and they were like, "Sure, come on in?" STEVE: To some degree, yes. That's one way of putting it. There is always the devil in these details. The first thing is that that wouldn't have worked if I had wanted a different kind of job. But when someone comes to you and says, "I would like to write documentation for you all day," you go, "Oh, my gosh. This literally never happens." If I had wanted to like work on the compiler, I'm pretty sure they would have said no. But because they knew documentation was important and they wanted documentation and because I had already been basically doing that job in an open source way, it's like I've had a year-long interview already. Then finally, they actually didn't have headcount at the time so I actually moved on as a contractor initially and had to do some freelance work and then eventually, once we were able to hire a new person kind of got it in. They're like a cool kid story. It's like, "Oh, yeah. I totally asked Mozilla for my perfect dream job and they just gave it to me," but like that's not really the way that it works. CHARLES: Got you. That actually leads me into a question that I have wanted to ask you. You write a very good documentation as your day job and documentation is extremely hard. For me, it is extremely hard to get and stay motivated to document something that I've worked on. I think that is probably a common enough experience for programmers. We don't recognize because we use documentation that it's extremely valuable and yet, it still this thing that is just a constant uphill battle. I'm curious, how do you manage to stay motivated to write documentation for an entire programming language over the span of years? STEVE: As I'm often want to do, this has like three or four different components. I guess, there's a couple of different things involved. The first one is that I actually got accepted to go to English grad school, although I ended up not pursuing that. Like writing, it's something I have just always enjoyed. I got a Bachelor in Computer Science but then I was going to go to grad school for English and due to university shenanigans, it didn't really work out. They told me I was going to get a free ride and then accepted me and then they were like, "Oh, wait sorry. You have to pay for this." And I was like, "Wait, sorry. No, I'm not doing this anymore. That's ridiculous." That's kind of always a predilection for writing and I think that the reason why that is because I grew up basically like on Slashdot and eventually then on Dig and Reddit and all these other things. I've kind of been writing a couple paragraphs a day, basically every day in my life since I was a little kid. I think that's something that's sort of like underappreciated. Documentation is hard but it's like a skill, like any other thing. Programmers will say, "I really want to learn TDD so I'm going to make myself do some TDD, I'm going to practice it, I'm going to focus on it and that's going to be a skill that I'm going to improve," and then they see documentation, and they kind of think it's this thing that you either have the skill or you don't. But writing is just another thing like anything else that you can practice at and get better. I think maybe it's because it's a little bit farther away from the wheel house of what you do day to day, that people aren't as interested in it but it is something you're truly interested in, I think the best way to get better is just to do it and do it a lot. I say this is I'm kind of in the middle of a little bit of writer's block at the moment to be honest. Then finally, I think the other reason that I'm motivated about docs is that I actually believe that documentation is an exercise in empathy. Like good documentation, the ideal as a programmer, the ideal thing that happens in documentation is I have a question about how to use something, I go to the documentation, and it says the exact sentence that answers my exact question. As those varying degrees of vaguely gives you the right idea, versus literally tells you exactly what to do. I think that the way that you can accomplish that excellent documentation is by understanding what your users need and then preemptively figuring it and/or writing that down. I think that that requires being able to put yourself in their shoes to some degree. I'm not going to say that that's a thing that I am perfect at but I think that a valuable skill when trying to improve docs's like figure out what they actually need and then give it to them. It's doesn't always have to be in that order, like sometimes people will fail to find the thing they need, tell you what you need, and then you give it to them. That's a strategy I've used a lot and that's one reason why I hang out in the Rust IRC all the time, helping people is for a very long time, I would like sit in IRC, someone would ask a question, I would answer the question, I'd go look in the docs and see if they could have figured out themselves. If they couldn't, that would be might next doc PR. It's just like even if it's just a couple sentences like add the question from IRC into the documentation and then just do that over and over and over again and then eventually, people start learning from the docs instead of actually ask questions because they already found what they needed. CHARLES: Right. I have a question about that because once you develop those skill, I think you also still run the risk of like burning out. I know that one of the reasons I tend to always fall back to like, "I'm going to spend my time doing coding instead of documentation," Or, "I'm going to spend my time --" Even with TDD is a great example is like with TDD you get to experience those short term wins. I think that kind of prevents you from burning out, where sometimes when I'm writing documentation, it feels like I'm screaming at the void. I might be screaming really loud and really, really well but I feel like a lot of times, I'm not experiencing those wins and I'm wondering if you have any tips for like experiencing those wins. Or getting that feedback to kind of keep you motivated and keep you doing the job. Also, trying to push the level of your own documentation skill and communications skill. STEVE: Yeah, experiencing the wins is definitely a part of it. But one of the other things that is sort of part of it is that like I do the opposite. I do a lot of coding but that's my side projects. When I get fed up with writing documentation, I maintain the [inaudible] implementation that Cargo uses to resolve Rust packages, for example. If I'm feeling a little stuck on docs, I'll go write some software and then come back to the docs so that kind of help with burnout. Another thing is that I think I'm just like perpetually in a state of just barely above burnout anyway so that also sort of factors in I guess. You know, it's like Bruce Banner. The secret is that I'm always angry so -- CHARLES: So you work on open source, is that what you're saying? STEVE: Yeah, exactly. We're working on open source all the time. I've been lucky enough to make open source as my job for, basically almost my entire professional career. Although not totally. You know, at some point, you just kind of get used to it. But in terms of experience and the wins, this is also one of the reasons why I like to teach beginners specifically is that beginners allow you to remember what it's like to be a beginner, which is also part of building the empathy. By interacting with beginners a lot, you also get a lot of those wins because beginners usually ask easy questions so it's easy to figure out the answer that stuff. Then you've got that positive feedback loop kind of going. To me it's maybe not IRC literally for every project but answering questions on Stack Overflow, or whatever message board forum you have, or Twitter, like actually interacting with other people. For me at least, that's how I get that kind of sense of not screaming into the void that you have to like go into the void and find the other people there, I guess, that I'm just like come to you necessarily. CHARLES: Speaking of empathy for beginners, it just occurred to me that we didn't actually talk about what Rust is. We probably should do that. Why don't you tell us a little bit about the Rust, language, as well as, you've mentioned Cargo and [inaudible] ecosystem for us as well? Let's talk about that. STEVE: Yeah, totally. Basically, Rust is a new-ish. I should stop saying new because it's almost not really at this point. A kind of new-ish programming language, heavily sponsored by Mozilla in development. Its idea is to become a new low-level programming language. But I always hesitate when I say this because one of my old pitches for Rust used to be like, "Rust could be used anywhere. You can use C." Then people go, "I would never write, C is so cool. Rust is not for me." I'm like not do that. But the reason that people don't use C is a lot of the problems that we are also trying to fix. I guess the primary differentiator for Rust in terms of like programming languages theory is that it is safe and safety as they got specific meaning. But basically C is a very dangerous sharp tool and you can cut yourself and people who use those tools often do cut themselves, whereas Rust is like it's got a safety guard on it. It's a compiled language so its compiler actively prevents you from making some of the worst mistakes that you can make in a low-level programming language like C. It turns out that when you start building up these sort of safe abstractions on top of these really fundamentally low-level details, you actually end up with a relatively high-level programming language. I talked to a lot of people, for example from JavaScript or Ruby world or Python world who come to Rust that are modulus, some libraries, and other things. This is actually high-level enough that I feel like I could do this instead of review JavaScript all day and I would be just as comfortable. The other day, I did a little bit pair programming and we actually recreated a JavaScript library in Rust that had virtually the same interface because like you can actually build relatively high-level things so pass an enclosure to a function that does some stuff is totally normal and Rust world. That's also very familiar to people that come from the Ruby, JavaScript, Python background. Also then, as part of that is we also culturally like Rust the projects, not Rust the programming language, really, really cares about helping people understand what systems programming and like lower-level programming means. A lot of people will not program and in C or C++ because they have no idea how to get help or to learn because many people in the low-level space have this RTFM attitude or like, "If you don't know what you're doing, then get out of here," whereas in Rust world, if you ask an extremely basic question, we're like, "Welcome. We would love to have you. I would be very happy to like walk you through," like explaining how that works on these kind of low-level details. Part of the culture of Rust is to bring this sort of low-level programming to people that have rejected it before for various reasons. The reason that Mozilla cares and the reason Mozilla sponsored the project is that Firefox is written in C++, so like four million lines of C++ last I checked. Last time we did a security audit of a really pants-on-fire, terrible security bugs in Firefox, I go to this website and now they run arbitrary code on my machine kinds of terrifying bugs. Basically happened because C++ is dangerous and sharp. If you screw up, there's the kind of bad things that can happen. About 50% of those security issues in Firefox would be eliminated at compile time by the Rust compiler. That's a really huge win in general so the idea is that we are slowly rewriting Firefox and Rust over time. That's one angle of why Mozilla cares about Rust. The second part is Servo, which is a rendering engine that's built in Rust from the ground up. If you think about Firefox proper, it's got Gecko as the rendering engine inside that actually determines where things go on the page and stuff. We're also writing a new one of those from scratch called Servo in Rust. That was also to prove that the language was doing the kind of things that we need it to do. But also Servo is an impressive piece of technology in its own right so it might become its own thing and/or bits and pieces of it are already making their way into Firefox. It's kind of also a way to improve our core products. That's why Mozilla cares. CHRIS: I was curious with Servo and Servo is the layout engine. Do you know if there are any plans to write a JavaScript runtime in Rust? STEVE: That question is complicated. Sort of what it boils down to is that a Git is inherently kind of unsafe by Rust definition of unsafety. It's actually controversial like when I talk to people that work on JavaScript engines, they're pretty much 50/50 split between, "Oh, yeah. Totally Let's absolutely rewrite the whole thing in Rust because we rewrite it every two or three years anyway from scratch so why not use Rust next time," to, "Since it's massively unsafe anyway, I don't see what benefit I would actually get so why not just stick with what we know." It's like very extreme ends. It's definitely feasible but I don't know if it's going to happen and/or when exactly. CHARLES: There were two questions that I had kind of to unpack some of the things that you said in there that were just really interesting to me. You said Mozilla plans to incrementally rewrite Firefox in Rust, where it's currently four million lines of C++. Now, how does that actually work where you're talking about swapping out large parts of the runtime with something that's written in a completely separate language? How does that communication happen between those language boundaries? STEVE: There's this concept called an ABI, not API. It may sound very similar -- Application Binary Interface. What this really boils down to is assembly language does not have function calls. That's not a concept, that's in assembly. People have come up with, "If I write a function and I map it to assembly code, what's the convention about how I do things like passing an argument and return values? How those all that stuff actually work?" Because assembly is so low-level, there are multiple different ways that you can make that happen. There's a number of different specifications how to make that work so C, the programming language, has a very straightforward ABI so any programming language that knows how to call C functions, uses these convention at the assembly level to do the function call. What you can do with Rust is you can say, "Please make this Rust function follow the C calling convention," in that way, any sort of thing that knows how to call C functions can call Rust functions directly. By doing that, you can sort of say like take a chunk of code, write it in Rust, expose a C interface, and then anything that knows how to talk to C, which is virtually everything, can talk to Rust equally as well. For example, one of the earliest production uses of Rust was actually inside of a Ruby gem because Ruby can be extended to C and Ruby knows how to have C extensions. It doesn't actually need to know that it's literally written in C. It just needs to know how to generate the assembly to call the correct functions. That's actually like a thing. Basically, the process is like write a component in Rust, expose this language independent wrapper, and then call into it like you would in C code. CHARLES: So it's really, just they're sharing memory and sharing is like right there in the process and there's no overhead for the intercommunication, it sounds like? STEVE: Yeah, exactly. You could also do all the regular things with JSON-RPC over a socket or whatever if you wanted to. The most efficient way is to literally include it as your binary just like anything else. CHARLES: Which kind of leads me into my next question, which is Rubyist and Pythonista people coming from JavaScript, one of the reasons we don't like to write in C is because, as you mentioned, they're so sharp so we have safety so that you don't have to worry about memory allocation for the most part, the garbage collector kind of has your back there. You access things by reference so you never have to worry about accessing memory. That's not there but kind of the conventional wisdom is that that all comes with a pretty big cost. It's like really, really expensive. I know when I was getting into Ruby and I was explaining a lot of the pushback I got from people doing C and even Java, it was like, "It's going to be super slow because all those high-level features that you love so much, you're paying a lot. A lot for them." My understanding is that's not really true with Rust. Is that fair to say? STEVE: Well, Rust does not have a garbage collector so, yes, it does not pay that cost because it doesn't exist. Now, that also raises a bunch of other interesting questions and basically what it boils down to is a compiler and especially one that has a typesystem, basically asks you to declare certain properties of your code like this function takes one argument only and it's always a string. That's sort of what type safety means. It kind of like a fundamental level. One of the ways that Rust uses type safety is to say, "This pointer to this memory always points to valid memory," and you have to be able to demonstrate that to me at compile time. From those couple of sentences, that sounds extremely complicated but it turns out that most programming code is written in a way that actually works this way. For example, like I'd talk to Yehuda Katz a number of times because we're friends, he also works on the Rust project and he's also well-known in JavaScript and to you all, I would assume. It turns out that the style of Rust code I write is actually extremely similar to the style of JavaScript code that I write is just sometimes there are some tweaks. It is true that those features often do take up a lot of memory and/or rely on any sort of expensive, from a low-level perspective, way of doing things. But it turns out that's actually more of a function of the way that the programming language is made in semantics. You could design a programming language that feels very similar but as very different underlying characteristics. For example, Closures in Rust, the compiler is smart enough to know that if you don't actually capture an environment. Say you're going to add one to every number in a list. You want to do like .map, pass in a closure that takes one argument X and adds one to every single X and then collect that up into like the map join kind of thing, to collect into a new array. That closure that you had passed a map, while it's a closure, it's taking that one argument X and doing X + 1, so it's not really capturing an environment at all. There's actually no reason to allocate a bunch of extra memory because it turns out, it's the same thing as a regular function. The compiler is able to optimize that call away completely to the same thing as if it was a normal function and not a closure, and therefore, you're paying no overhead. Even though, like syntactically, it looks kind of like a closure. Then you're kind of think of that applied to almost everything in Rust. For example, Rust has methods but almost all of them are actually statically dispatched at compile time, as supposed to dynamically dispatched, where you need to look through some sort of object hierarchy because we don't really have inheritance. There's no way to say like this might result to a colon, this class or this class is super class, or this class is super class so I have to do this runtime look up to call functions that just doesn't actually really exist. Part of it is through the fact that these coding patterns don't strictly require this stuff. It's just the way those languages are built and part of it is because as we were building a language, we were extremely sensitive to not include features that would require this really heavy overhead. In a language, that's like a low-level of focus on details, it's extremely hard to talk about the details without code. There's a lot of details, it turns out. CHRIS: One thing that I'm very curious about and one of the things that drew me to Rust actually is the fact that its typesystem is, I guess an ML typesystem. It is like much more [inaudible] to something that you would see in a functional programming language like Haskell, than you would like a regular C++ or Java. CHARLES: Now, a Chris-acronym alert. What is an ML-style typesystem? CHRIS: I'm sure Steve can answer this better than I can but it's a typesystem that uses the Hindley-Milner algorithm for type inference. It does a lot of the heavy lifting for you, in terms of correctness. Is that correct? STEVE: Yeah, I would say more accurately, ML is a programming language. It's the name of the language so by saying like an ML-like typesystem, he means like a Java-type typesystem. It's like a similar statement but about a different language. I always forget what ML stands for specifically but like OCaml has got ML at the end so like OCaml is one of the languages that sort of the family of ML. There's like two branches of functional programming, which of course everything is wrong when you try to organize things this way. Like you could also argue Lisp as a third but there's kind of like the Haskell-style and the ML-style are these two big pillars of functional language stuff and Rust tends to be in the ML sort of family. There's lots of common features between families of programming languages and all that kind of stuff. I think the ultimate point that Chris is trying to make is when I say that Rust is a typesystem, I do not mean it's like Java. There is a wide variety of typesystems and they do all sorts of different things and actually Java has been getting increasingly better over the years as well. But it is much more canned to a functional language in the typesystem, which I think is what you were getting at and serves the actual question, right? CHRIS: Yeah. Actually, I just looked it up and ML stands for MetaLanguage. It is actually is going to serve my question really well. ML was originally designed for theorem improving in math, which is part of why it works really well in functional programming languages. But it also makes sense if you use Rust, how the compiler work from the kinds of things that it catches, like a relatively low effort on your part because it is originally designed to completely prove out a theorem so the compiler is doing that to your program. That leads to my question which is I recently heard someone else on the Rust core team talk about one of the things that Rust really seeks to improve upon is concurrency and parallelism, which is historically very hard. To do that, you could use things like mutexes or reference counting, which Rust has. But they also lean extremely heavily on the typesystem itself to sort of guarantee that your concurrent code is actually going to run safely. On one hand, I'm interested in hearing you expound on that but I'm also really curious how the C, C++, Java programmers take to that sort of thing in Rust because as I understand it, that is a pretty novel approach to that kind of problem. I wonder if there's like pushback from the existing low-level systems community on that stuff. STEVE: I'll do the second part first because it's a little simpler. One thing that I will say is we sort of didn't appreciate over time because we were creating Rust for ourselves, roughly the C++ programmers are working on Firefox, which we had to say for ourselves because I was not literally one of those people but you get the idea, is like assuming that C++ people would be the primary audience. But it turns out that a lot of people that programming C or C++ are pretty happy with it and they like doing things that way. They're a lot smaller of a population than the number of programmers who do not program of those languages, which is true for any language, basically. The sum of all other people is bigger than your specific thing. What that means, I think that in retrospect this seems obvious but at the time, it was like hard to figure out or I definitely did not understand this at that time, that most people would come to Rust from not C or C++ than they would from C and C++, just even by virtue of numbers alone. A lot of the people who are not doing it are not doing it for reasons. They've already rejected it for some sort of purpose and the people who are still doing it often are like happy with what's going on. There's definitely a little skeptical at times of the kinds of things that we can accomplish. Also, our success has been pushing C++ specifically to grow a lot of safety things so we hear a lot of people say like, "In five years, C++ is going to have this tooling that's going to make it also pretty safe, even if it's not as safe as Rust. I'll just wait for that instead." Surprise, low-level programmers are extremely conservative bunch in many instances. The first part, which is the bigger and more interesting one, the typesystem is absolutely how concurrency works in Rust. This is extremely powerful for a number of different reasons. The first one, and I think the fundamental reason why it's done this way is that typesystems don't have any runtime overhead. When you're in a performance-heavy language, that's really the key. Originally, a long ago in Rust, we actually had a garbage collector even, like a very long time ago in Rust. The primary goal was always safety and we thought the only way to accomplish that was with lots of runtime checking, heavy runtime, and all these things. Over time, as the typesystem grew, we realized we could use more and more of a typesystem to eliminate more and more of the runtime because types are checked to compile time so they have no overhead cost, which is awesome. Like Rust references, doing this validation that they're always valid is completely a compile time construct that at runtime, they're literally the same thing as C pointers. That's one reason why the typesystem is really heavily useful for concurrency because you want things to be safe. We also don't want to slow them down. The whole point of concurrency in many instances is to get a speed up. If you introduce too many safety checks to make sure that your concurrency stuff works, you lose all the gains that you were trying to get from being concurrent in the first place. Having that like as low-cost as possible is extremely important. The second one is that concurrent problems are extremely difficult to debug because you need to recreate the exact set of circumstances under which the bug happens. If you have a bug because you have two threads that have a particular access pattern on a particular variable and that's where the bug is introduced, good luck coercing your operating system scheduler into scheduling those two threads at exactly the same way as when the bug happens. To some degree of the way that you fix a lot of concurrency bugs is by introducing an extreme amount of logging and then just kind of let it run and praying that you hit into the situation that causes the bug. That really brutal and doesn't really work. By using the typesystem and verifying it upfront, you just know it will work at runtime because you've already proved the concurrency property before your code even runs. It's also just like a better debugging experience, I think in general. The way that we accomplish this task is extremely novel. I guess I should also say extremely novel to working programmers, like almost all Rust is built off of existing research that has been known in academia for a relatively long time. That's actually one of the places where it gets the name from, it's like taking ten-year old ideas that have a little bit of rust on them, that have found usefulness and bringing them to [inaudible] research. Anyway, the way we accomplish this basically is the typesystem in the standard library, the way that you spin up a new thread, it has a particular type signature and the type signature says, "Only allow the types to be sent to this new thread. There are safe to pass between threads," and/or like, "Only allow references between this thread and that thread of types that are safe to use across thread." What that means is that when you try to spin up a thread and you passes a thing that doesn't work, you get a typesystem error. It turns out this is not concurrent safe collection so it does not have the prerequisite types so therefore, you cannot pass on this thread and you're done. That's sort of like at a core level of how these things work. Then for example, mutex is a type that does have that property so by sticking with non-concurrency thing into a mutex, now you can share it safely. That means we've guaranteed that the compile time that you'd safely done this transfer between threads and that kind of thing. It's not just about mutexes but that's sort of the general approach. The last thing I want to say briefly because I just said a whole bunch of things. I'm sure, I've raised a ton of questions here is that the other powerful thing about using the typesystem for concurrency guarantees is that other people can extend it. If you write a library in Rust, your library will be exactly as concurrency safe as the standard library and as the language itself. It's not like we provide the set of concurrent collections and then we vetted our own implementations and then you're kind of your own or building your own stuff. You can use those exact same types to help guarantee properties on your stuff. Also build alternate threading situations, as well that use the same things and the ecosystem all works together so everything is just concurrency safe by default because it's like a property of typesystems that are being built into the runtime or something. CHRIS: I know that recently, there's been a lot of, I guess excitement about this library called Tokio. It's not like there's future that kind of like promises in JavaScript, then there have been abstractions just kind of consistently being built up but it seems like Tokio is the next step and it's building towards a whole stack of higher-level concurrency things. Is what you just said enables that kind of thing to happen? STEVE: Yes. Tokio is using those exact same typesystem features in order to guarantee that when you have a chain of promises, to use the JavaScript terminology instead of future things, that you make sure that they're safe. This is not literally implemented yet but Tokio, for those who are not paid hyper attention to the Rust space because this is a cutting-edge, the library is gearing up for an initial release in the next week or two. Soon after you hear this or maybe right before you hear this, it's just going to be released. It's extremely cutting edge. But in some ways it follows sort of the node model of concurrency. There's event loops, you chained together, we call them futures, you call them promises together, you put that pile a future chain and do an event loop and watch the concurrency kind of go. One example of how Rust can do cool things is you could -- this is not implemented yet but it will be in the future -- run, let's say, five event loops on five different threads. Then you just tell the framework, "Please run this future chain onto one event loop. I don't care which one," and then it will automatically load balance across the five threads and five event loops because you've guaranteed the compile time that everything is safe to pass between threads so we know that that's just trivial to do and therefore it's like not a big deal. We can add those heavy duty features without worrying about introducing very subtle bugs, which is really cool. CHRIS: That kind of leads me to my next question, which is at The Frontside, we are pretty into web development, in case you didn't know. I am someone who follow Rust a lot and I find it very interesting. But for the most part, I don't have a need to do systems programming on a regular basis. I also wouldn't even really know where to start, if I wanted to do systems programming. As I learned Rust, I tend to always gravitate towards wanting to do things that I would probably do in Ruby or Python, like write the back-end for some web app or something. That goes okay but Rust is very much still in the process of building those abstractions to the point that it's relatively digestible. So I have a couple of questions. One is do you see Rust being a thing that would be used by web developers a lot more broadly and two, how would you recommend that people like me who aren't really familiar with systems programming start to really dig into Rust on a deeper level? STEVE: I would like to think that web programmers will use Rust more often and to be honest, originally, I was extremely skeptical of this. But it's been changing rapidly as time has gone on. Part of that is because as we've gained more experience, actually in programming in Rust, the fact is Rust used to be a lot less ergonomic than it is and now it's fairly ergonomic and will only get more so in the future. That's something that web people or at least, I come from Ruby so Rubyist care a lot about ergonomics, maybe more than anything else frankly. I'm not sure it's the first tool that you'll reach for but I do believe that sometimes, it makes a lot of sense. As one example that I will use, there's not a whole lot about this but basically, npm has started using Rust on the server side for powering the registry. They have three services in production now but they were basically like JavaScript as a language we all know what is the best language for doing this. We have a service that needs a little more oomph so maybe let's rewrite that in Rust instead and use it for those kind of things. I think that there's a lot of situations for web developers where they don't realize they have the power to make things faster without just adding on more servers. I think that's kind of like a compelling sort of [inaudible]. Any sort of background job like any sort of job queue thing is like often better written in a faster language but you would not reach for that faster language first because traditionally, those faster languages have been terrible to use. I think we continue to win on the ergonomics and continue to win the libraries that web developers will reach for Rust like more often than not. In terms of the learning rest on a deeper level, I think that one of the initial things and sounds like maybe you personally are a little past that but maybe not the people who listen this podcast is that I do think that sort of building the things that you would normally build in Ruby or JavaScript or Python is the good first step. For example, right now Advent of Code has been like a really fantastic way of having these little programming projects. If you haven't seen AdventOfCode.com, it's like every day in December up until Christmas, there's a new programming project that you can build the thing in. I've been doing those in Rust and that's a lot of fun and it's a good way to practice and gain some basic literacy. But after that moving at a low-level stuff, my personal thing and I know something you've expressed interest in the past is my side project is building an operating system in Rust. More so, than just that the pitch is, "You've written JavaScript before. Let's write an operating system together. Here is this companion book and I'll show you how," and that's called intermezzOS. It's like I'm basically trying to rebuild an operating systems curriculum but in Rust instead from nothing, like we start off with assembly code and move up into Rust code. CHARLES: Now, you can't even use anything like all the things that we've been describing like threads, kernel level callbacks. You get none of that, right? You have to implement it all from scratch. You can't use POSIX or whatever. You know, 90% of your code ends up going through. STEVE: It turns out that and it's sort of like for reasons that hopefully I'll be able to fix in the future, you need about like 200 lines of assembly code before you get into Rust and then you basically don't need to use assembly again, really. It's not that big of a barrier in terms of [inaudible] things and its copy-paste stuff that I explained extremely heavily so it's like totally an accomplished real thing. Then you're in a real programming language and you can do more normal things on top of it. But one thing about that because it is my side project, the kernel is actually farther along than the tutorial is and I actually need to find some time to write more of the freaking tutorial but this is kind of my personal long-term project over the next, let's say, decade and to have a completely free and open source tutorial for you to learn about operating system developments. That's one of the things I've been doing. Another one that I think that is really extremely useful is once you gain some amount of literacy on this, you can actually start to learn more about how your regular programming language works. I've been giving this conference talk recently. It's called 'Exploring Ruby Through Rust', and I'm like, "Once you know this low-level stuff and you gain this literacy, you can look at the source code of your language as interpreter and learn stuff about it and you can contribute to it maybe even." Maybe that's not the most practical thing or whatever but now that I've spent a bunch of time with Rust, I understand Ruby on a far, deeper level than I ever did before because now I'm not afraid to go poke around in the internals and learn how it really works under the hood and I understand what those internals do far better. Maybe five years ago, I could have told you like, "Ruby is garbage collector. It's extremely basic. But I don't really know what that means." And now I can be like, "Ruby has this mark and sweep generational garbage collector. But it's not compacting or concurrent yet but maybe in a year or two. Now, that's not just a bunch of buzzwords because I have this low-level literacy." CHRIS: Yeah, that's definitely something. I forgot about but every time I go learn something in Rust and initially this happens a lot. Every time I do that and I go back to JavaScript or something else, I find that Rust inadvertently taught me something about the language that I actually work on every day. Especially, when it comes to things like references, values, and the difference between them and debugging weird prototype behavior in JavaScript became so much easier after I had spent some time working with Rust and had had to like actually deal with passing around references or dealing with life times or having the compiler yell at me for a lot of things that I thought were totally normal. Then I'm going back to JavaScript, it's like, "Wait a second --" Suddenly a lot of these pieces are starting to fit together and before what was just as weird mystery, now I can totally see what is happening and start to think about how to fix it. Even though I don't even have the same tools that I do with Rust, it still is extremely useful from that perspective. STEVE: That's awesome. I'm glad to hear it. That's how I definitely felt with Ruby for sure. CHARLES: You know, in terms of actually using it for day to day stuff, is there other plans, is the ecosystem already supporting things, say, a web framework? Like a low-level web framework like Sinatra or Express or even higher one like Rails. STEVE: I guess, like you've already qualified it as web stuff. But I would say, in a broader sense, whether or not Rust is ready today for you, it depends entirely on the ecosystem. I feel like 80% is productive in Rust as I did ever in Ruby. But that's only if there's a library that I don't have to rewrite myself because it doesn't exist yet. That number is actually growing rapidly so I just look because it's like the end of the year and our package ecosystem is actually doubles. This is a request from earlier. I didn't expect Cargo so Rust basically has bundler or yarn/npm built into the language itself. We distribute it with Rust and we have all that great package ecosystem shenanigans. Another great example of Rust over a language like C is the tooling. Basically, what happened was Yehuda and I kind of showed up in Rust world and we're like, "Why are you still using make files. We know a better way." And they're like, "Okay." Then he builds the equivalent of bundler for Rust. Then everyone's like, "Oh, yeah. This is way better. We're not using make files anymore." The tooling situation is very familiar to a dynamic programming language person because we literally had the same people write the tools. That also means you can share packages freely and briefly so operating system development thing is totally intense to be able to use your package manager to download packages to help you build an operating system. For example, X86 has custom assembly instructions that you need to use when interacting with the hardware and someone has already built a package on [inaudible] that wraps the inline assembly up in a nice to use Rust functions. I can just include that package and use it when building my operating system, which is totally mind-blowing. The npm is sort of feel into OS development is just real intense and cool. Back to the ecosystem thing, though. For web application specifically, it's good and also bad. There's actually multiple different web frameworks already at different levels of comparison. For example, you have Nickle which is kind of like Sinatra and you have Pencil, which is kind of like Flask and Python, which is also kind of like Sinatra. Then you have Iron, which is kind of like expressed in JavaScript. There's also like I know of at least two. One of is has been worked on but it's not been actually released. But the code is at least open source yet. I know a second that is being developed fully in private that has not had any public release yet. Then when the Tokio stuff comes out, People are going to be building new frameworks on top of the new async shenanigans and/or porting the async stuff into the existing frameworks. We kind of have a lot of options but there's also a lot of churn and activity and stuff going on in that space so that either terrifies you or makes you enthusiastic. They're basically is like that. We definitely don't have a Rails yet. I don't think that's because a Rails will never exist but because it's a much bigger project to build a Rails than to build a Sinatra. CHARLES: Yeah, and you just need those foundational pieces there in place before you really want to attempt that. STEVE: And I think Tokio is the real foundational piece and it's just taken us a long time to put it all together. The initial tests in Tokio, we could do a 'Hello, World' benchmark like the tech and power benchmark. Some of you are already familiar with those things, or not, they're like 'Hello, World' benchmark. We actually got faster than they are fat than all of them. It just edged out the fastest Java, which is currently the reigning benchmark on it. That's like extremely compelling. Even if after all this stuff is built on top of it but it's taken us a while to build those foundations and we're just getting that point like Tokio is going to have a release, hopefully before Christmas. I've been assured by the end of the year and then people are going to build stuff on top of it and it's just going to explode from there. Here's another little interesting pitch. I'll give you for this, is that one of the things I like about Rust on early ecosystem is it means that if you want to be that person who built the library that does X that everyone uses, there's lots of opportunity in Rust world right now. Where there's a lot of foundational libraries that you could be the person who wrote that thing when everyone knows and loves and uses. Like JavaScript is still kind of there. In Ruby, every library basically exists already so there's no more room to build a foundational thing. But if you're someone who likes working on open source and that story is compelling to you like getting involved in a younger ecosystem, it means that you can have a much larger impact. I maintained the [inaudible] library that things used. The only reason that's true is because I was around before we had one and then Yehuda wrote the initial version and now, I'm maintaining it. There's tons of space out there so if writing a web framework is the thing that's interesting to you, Rust is a great place to explore and actually doing that at the moment. CHARLES: Steve, one of the things that I know you do is you actually write the Rust Book. I heard that you're also in the process of rewriting it along with Carol Goulding, I believe. I was wondering if you could tell us a little bit about that. STEVE: As part of this Steve getting the job right in the docs on Rust thing, I kind of working on lots of stuff so up to Rust 1.0, we knew we needed to have some long form explain all the things that Rust so that became what's called the Rust programming language which I named so because the C programming language and the C++ programming language, the names of the foundational books for those languages so I wanted to continue kind of in that tradition. But there is some problems with that which is I'll say that I'm a little harder on my own work than I think other people are so I hear people tell me all the time that they love the Rust Book and that it's like one of the best programming books that have ever written. But I think it's not that great. The reason why is also because I just know that the way in which I wrote it. You have to remember that Rust 1.0 happened in May of 2015. We were working on language for six or eight years before 1.0 happened so there was lots of changes, language is changing on a daily basis. Now, it's super stable like super, super, super stable. But what that also means is in some like deeper philosophical sense, nobody had had experience programming in what really was Rust yet because we were still like finishing building it's so like how do you write a book on a language that like the precursor language is what you're using and you're trying to see like what is it going to actually end up being like at 1.0. Because it's not like we can just say, "It's done. Now, go write a book, Steve and then we'll release it at that time." The circumstances in which I wrote the original book were I had a very intense deadline of this has to be done by the 15th of May. While the language was coming together, it takes a couple months to put together a book so I had to make sure that the stuff I was starting I would need to go back and re-fix. That also means that I was like much more vague in some places where pieces were still falling into place and you're like, "This is definitely going to be the same. But this might change so I'm going to leave that part off," and then I just have to plow through because the deadline. All those things coming together means that I kind of put together this book that while good and I'm proud of the work that I did, I can do much better. At this point in time, we now have a full year and a half after Rust 1.0 has come out. I know the struggles that people have when learning Rust. I know the ways in which they succeed or fail and I've talked to a lot of people so I'm sort of rewriting the book now, bringing that knowledge and understanding in as well as the fact that the language just been around for a minute so it's much easier. As part of that, I brought on Carol. She goes by Carol Nichols or Goulding. She both has her maiden name and her married name. She's been one of my best friends for a very long time so I'm extremely happy that she's my co-author on this book. The two of us together and working on doing the rewrite, I think that it is possibly the best thing I've ever done or worked on as far as books go, like I'm extremely happy with it and you can read it online right now, if you want to and see if I'm right or wrong about that. But I think it's a far better book than the original book was. It's actually going to publish at No Starch as well. We're donating all the proceeds to charities since we're being paid to actually write the book in the first place, like [inaudible]. It's going to be a much, much easier and better way to learn the language, I think as well. CHARLES: If we want to check that out, where can we find the new version? STEVE: I'll give you a link to put in show notes or whatever as well. But it's Rust-Lang.GitHub.io/book. There's also just like a book repo in the Rust Lang organization on GitHub. All things in Rust is being developed fully in the open so you can read the drafts and see what's been done where. We're getting towards the end, slowly but surely so I'm hoping that's going to be done relatively soon. CHRIS: Well, I'm looking forward to it. CHARLES: Fantastic. Sounds like the documentation is there. It's excellent. The community is there. It's excellent and from what I'm hearing like the kind of the tower of the ecosystem is really being built up. It's not as high as a bunch of other places but it's definitely high enough to jump in and get your feet wet. If you're you know coming from almost any walk of programming. STEVE: It's a lot of work but we seem to be doing good. CHARLES: All right. Well, thanks for stopping in and talking about this with us, Steve. STEVE: Thanks so much for having me. It's been a lot of fun. CHARLES: Yeah, and now Chris, we do need to kind of figure out what is going to be our Rust project here at The Frontside. CHRIS: I'm up for that challenge. CHARLES: Yeah, that'll be some Christmas homework. All right-y. Take care everybody and thanks, as always, for listening. We'll see you next week.

This week we follow up on Raise To Wake, iPhone 7 rumors, iCloud Core Data and the MacBook Air. We examine RESTful, Software's Diseconomies of Scale and also discuss Agile methodologies. Picks: Lulzbot Mini, Maker Festival, Pokemon Go and  Continuous C# and F# IDE for the iPad Episode 99 Show Notes: Evan Dekhayser Raise to Wake System Requirements askMTJC WarningZiOSApp Jaybird Sport Beats 66 Audio BTS Headphones Bellboy BlueTooth Headphones The Deprecation of iCloud Core Data Ensembles FireBase Realm The MacBook Air will likely never get an update Software has diseconomies of scale - not economies of scale Richardson Maturity Model iOS Architecture Patterns Agile Manfesto TACOW Thingiverse Printrbot SketchUp: 3D for Everyone Cura 3D Slicing Software Pythonista Codea The Mythical Man-Month: Essays on Software Engineering String.io vuforia Spacecraft 3D Ingress - The Game Paul McCartney Classic Albums Live Episode 99 Picks: Lulzbot Mini Maker Festival Toronto Pokemon Go PSA Continuous C# and F# IDE for the iPad

01:22 - Hopes and Wishes AltConf Instant Apps Google I/O 2016 Keynote Bots Amazon Echo SiriSDK Xcode, Playgrounds for iOS Pythonista Swift First Framework 16:18 - iOS 10, Swift 3.0 19:43 - Wearables 21:53 - Apple TV / tvOS 24:56 - The App Store 26:41 - CloudKit 28:46 - Firebase   Picks Curry Up Now (Jaim) Box Kitchen (Jaim) Southside Spirit House (Jaim) Local Edition Bar: San Francisco (Jaim) Cathode (Andrew) Woo (Andrew)

01:22 - Hopes and Wishes AltConf Instant Apps Google I/O 2016 Keynote Bots Amazon Echo SiriSDK Xcode, Playgrounds for iOS Pythonista Swift First Framework 16:18 - iOS 10, Swift 3.0 19:43 - Wearables 21:53 - Apple TV / tvOS 24:56 - The App Store 26:41 - CloudKit 28:46 - Firebase   Picks Curry Up Now (Jaim) Box Kitchen (Jaim) Southside Spirit House (Jaim) Local Edition Bar: San Francisco (Jaim) Cathode (Andrew) Woo (Andrew)

Vi värmer upp med nya tröjor, kylskåpskalla chokladkakor och nötallergier. Sedan följer fler tankar om styrplattor, smarta klockor och Steve Jobs-filmen, nu när Fredrik också tagit sig samman och sett den. Avsnittets huvudämne är den tyngsta av frågor: vem behöver en iPad? Vem är den för? Vad har vi dem till? Har den en framtid? Varför är Fredrik så förtjust i plattor och tanken på att de ska kunna bli mer än de är nu? Jocke är oroad för den uppväxande generationens datorvana och beskyller sig själv för sina yngre barns bristande datorvana. Som avslutning ett litet dopp i e-postkorgen, framför allt kring Mac mini-köpråd men även med ett inspel från självaste iTunes. Tusen tack till alla er som e-postar och hör av er på andra sätt! Vad tycker ni om Ipad och dess framtidsutsikter? Och har ni gyllene tips om att livesända poddradio? PS – på grund av vad som brukar kallas “tekniska problem” är ljudkvaliteten inte på topp i detta avsnitt. Vi ber om ursäkt för detta. Länkar Tröjorna! Sista chansen att köpa är fredag 26 februari 2016! Onedrive for business Sid Meier’s railroads! – förekom även i vårt spelavsnitt Iflicks och Handbreak – macprogram för att rippa och konvertera filmer från DVD, Bluray och annat Fez else Heart.Break() – eminent närproducerat spel Force touch Cortana – Microsofts röstassitent Windows hello Steve Jobs-filmen, även omtalad i förra avsnittet The social network A few good men heter På heder och samvete på svenska Life of Brian Karl Emil Nikka Wink wink, nudge nudge Fredrik är glad att han inte köpt en Apple watch Garmin Forerunner 225 Certina titanium DS pro Pebble Android wear – Android för smarta klockor Jawbone Split screen och slide over – två lägen nyare modeller av Ipad har för att låta en använda två appar mer eller mindre samtidigt SCSI Pythonista är en hel värld för programmeringsspråket Python på Ipad Pennfunktionerna som vi pratar om att Apple tagit bort i en beta har nu kommit tillbaka Ifixit – har bra guider för reparation och uppgradering av alla sorters macar (och mycket mer) Två nördar - en podcast. Fredrik Björeman och Joacim Melin diskuterar allt som gör livet värt att leva. Fullständig avsnittsinformation finns här: https://www.bjoremanmelin.se/podcast/avsnitt-17-ipad-kunde-blivit-framtiden.html.

Das liebe iOS kann ja mittlerweile von Haus aus einiges mehr dank Extension. Doch wie erleichtert ein Uber-Pilot sich das Leben abseits von Apples Bordmitteln? Dran bleiben, mehr erfahren. Auf Madame YouTube liegt übrigens ein Videomitschnitt dieser Folge… von Sven. Totalkrasch per QuickTime Sven-only… als Schmankerl hat Andreas aber Screencasts von seinen Workflows eingebunden… die Kollegen waren zu lahm. Lieber Fluggast, wenn dir das Gehörte gefällt oder dir Sorgenfalten auf die edle Stirn fabriziert, dann haben wir etwas für dich: iTunes Bewertungen. Überbleibsel TextExpander Update Auf dem Mac gibt es nun Version 5 als Upgrade zu erwerben und die iOS Version hat ebenfalls ein Update erhalten. Unter anderem neu mit an Bord: Javascript Snippets (die auch auf iOS funktionieren) – allerdings funktionieren die fill-ins leider, leider nicht mit der TextExpander Tastatur-Erweiterung. Menno. Der Hauptkritikpunkt seit Jahren schlechthin ist ebenfalls “gefixt”: Ihr könnt euch nun aussuchen in welchem Ordner in der Dropbox die Synchronisationsdatei reinkommt. Alleine das ist schon das 3-fache des Kaufpreises wert und manch einer hätte dafür gerne schon vor Jahren gezahlt. Eine simple standardkonforme App-Folder Synchronisation hätte es zwar auch getan, aber vielleicht gibt gute Gründe für den “Full Dropbox” Zugriff… vielleicht muss die Redaktion auch nur einmal die Blackbox resetten. Mehr Info von offizieller Seite gibt es auf der Smile Webseite und Beispiele zu den JavaScript Fill-ins finden sich im Smile Blog. Links für Lernwütige: Codecademy Khan Academy Hackr.io Ulysses-ses-ses Passagier Farid M. (34) aus P. hat uns einen detaillierten Erfahrungsbericht zukommen lassen was Ulysses (besprochen in Episode #028 angeht. Hier das Worst of Ulysses von Farid aka die Punkte die ihm Sauer aufstoßen und für Probleme sorgen: Arbeiten mit Tabellen Die Kapitelnummerierung bei Export nach HTML, PDF oder ePUB Nix mit Inhaltsverzeichnissen beim HTML und PDF Export Keine Integration von Quellennachweisen (z.B. Bibtex) als Mathemn -Ass vermisst man Unterstüzung für Formeln Für technische Dokumentationen ist Ulysses also wenig zu gebrauchen. Das Ulysses-Team hat dies bestätigt und will dieses Thema irgend wann mal angehen. Er verlässt sich daher auf die folgende App-Rezeptur: Texte schreiben mittels SubLime Text und sich dank SublimeTableEditor über eine tolle Tabellenformatierung freuen – ansonsten hilft im TextExpander bei der Markdown-Syntax. Die Vorschau erfolgt - wie sollte es anders sein - per Marked 2. Exportiert wird mittels Pandoc in was auch immer, zum Beispiel HTML, PDF oder ePub – wobei ihn eine make-Datei begleitet die Herr über die verschiedensten Parameter ist. Für solche Großprojekte nutzt Patrick übrigens ein abgemagertes Scrivener und den Referenz-Manager BibDesk, exportiert dann nach LaTeX wo er mittels LaTeX-Plus ein PDF raushaut. Pandoc wollte er auch einmal probieren… irgendwann… falls er weiterstudiert. Nochmals danke für’s Feedback aus der eigenen Schreibstube. Die Flugmeilen sind dir bereits auf deinem Frequent-Flyer Konto gutgeschrieben Farid. Überschallneuigkeiten Der nvALT Nachfolger kommt zu Weihnachten Na hoffentlich haut der Zeitplan hin Brett. Uns jucken die Finger und der Geldbeutel liegt bereit. I kind of want to make sweet, sweet love to @ttscoff after hearing about a commercial successor to nvALT successorhttps://t.co/HSC9js5AZR— Michael Schechter (@MSchechter) May 27, 2015 Dr. Robotnik vs. iOSnic Andreas hat ein passendes Webcomic zur Sendung ausgekramt und Patrick sagt “Ja” zu dem Comic und damit seiner Auskunft nach auch “Nein” zu zu viel iOS Automatisierung. Für seinen Teil haut er sich mittlerweile lieber eine App drauf, die das machen kann was er will – wenn möglich sollte diese aber mit einer nutzbaren Extension daherkommen. Das coole daran ist für ihn, dass Extensions somit ein eigenes Icon haben, die App im besten Falle genau das macht, was der Herr möchte und somit nicht die Workflow.app Liste unnötig verlängert wird. Das ist auch schon der erste Punkt worüber Andreas und er sich für geschätzte 50 Minuten uneinig sind. One-Thing-Well sein, oder nicht sein. “Automation” via xkcd Die alten Hasen - Teil 1: Launch Center Pro Auf die URL Enkodierung mit URL schemes kann Andreas gar nicht. Das bringt uns auch schon zum ersten Sargnagel der Stunde: Mit Launch Center Pro ist Patrick damals durchgestartet, hat verschachtelte Listen angelegt wie ein Messi und sich bemüht in der Kombination mit Pythonista sinnvolle Sachen zu machen. Bei Editorial ist er aber schon wieder aus dem Automationsboot ausgestiegen. Fazit: Keine Zeit Python zu lernen. Dazu hat er noch gemerkt, dass er zum bloggen nun doch nicht iOS nutzen möchte. Er ist kein Viticci, er hat seinen Mac noch lieb. Launch Center Pro nutzt Patrick trotzdem noch in seinem Dock (das Zweite Icon von Dreien) – heute allerdings eher als Launcher. Für ihn ist das reine Platzersparnis, da er dort 12 Icons von Apps unterbekommt anstatt nur 9 in einem iOS Ordner. Zudem ist dann auf dem Home Screen Platz für andere wichtige Apps. Wir halten fest: Andreas = lieber Workflows und Bookmarklets statt URL schemes oder zusätzliche Apps/Extensions Patrick = mehr Apps, mehr Extensions, leicht weniger Workflows Sven = simplicityisbliss = wenig Apps, lieber heimischen Riesling trinken statt die Nacht durchzuautomatiserien Vorteil: Man kann seine Actions auf dem Mac in einem Editor schreiben und Encodieren ( ← wichtig bei der App)… zum Beispiel in Sublime Text. Ansonsten ist Workflow wirklich komfortabler als reine iOS-touch-und-zieh-Lösung. Außerdem ist Workflow halt geiler und flexibler, weil es als Extension aufgerufen werden kann. Die alten Hasen - Teil 2: Pythonista Pythonista ist toll. Die Dokumentation ist toll. Auf iOS ist das toll. Da Patrick nie den gelben Gürtel in Python erworben hat, verlässt er sich lieber auf Bash-Skripte die in der Dropbox oder auf dem Uberspace Server liegen. Das ist für ihn vielseitiger und einfacher zu managen, z.B. beim Thema Bildbearbeitung (skalieren, optimieren) überlässt er lieber seinem Server die Arbeit, statt sich mit Python und den vorhandenen Modulen auseinanderzusetzen. Es gibt bestimmt tolle Python Module, aber Pythonista unterstützt ja nicht alle… und wenn man jetzt nicht der Python Gott ist, dann ist das Vertraute halt einfach praktischer. Pythonista war damals das Ding um Sachen von Launch Center Pro aus auf dem eigenen Server per SSH anzutippen (siehe Quickly Run Scripts In Your Remote Computer With Pythonista And Launch Center Pro — Moving Electrons). Den Todesstoß bekommt Patrick aber nicht durchgepaukt, da springen die lieben Kollegen vor den Zug und schützen die App… aber so tödlich war der Stoß ja auch nicht gemeint, oder? Vorteil: Wer Python spricht, der stellt hier die iOS Welt offen. Anbei noch der versprochene Auszug aus Patricks Pythonista Archiv. Mehr ist es nicht, bis auf ein paar ganz spezifische Sachen mit seinen Markdown-Listen und ein wenig SSH Magie die hier nicht reinmüssen. Die alten Hasen - Teil 3: Editorial Editorial ist die Eierlegende Text-Editoren-Wollmilchsau und Patricks nvALT Suchmaschine. Referenzen auffinden = am schnellsten in Editorial, da die Suche super ist. Außerdem ist die TaskPaper-Unterstützung der Hammer ( ← Teaser, momentan sind noch einige Features im Betastatus). Link zu Patricks Lieblings-Workflows: Recent Folders Custom Menu Und natürlich darf von Federico Viticcis 2 Euro Büchlein nicht fehlen. Klare Editorial-Leseempfehlung: „Writing On The iPad: Text Automation with Editorial“. Die neue Liga: Workflow Nun, wer sich mit den Apps da oben genaus kaputt-automatisiert hat wie so manch ein Pilot oder Roboter… … der kann bei Workflow aufatmen. Da ist nämlich nix mit URL Schemes de- und encodieren, sondern hier ist einfach nur Happy Hour angesagt. “Bookmarklets” ruft Andreas nach wie vor in Safari auf. Patrick fällt aus allen Wolken, da die Workflow Extension sich da ja förmlich anbiedert und einen lästiges rumgetouche erspart. Er hat sich ein paar davon angelegt, unter anderem für Huffduffer. Viele braucht es aber in der Tat nicht mehr, da iOS ja mittlerweile nutzbar geworden ist ohne und Instapaper, Pinboard und Co. ihre eigenen Pferde im Stall. Workflow ist auch für Pilot Sven die erste Wahl: Extrem zugänglich und man kennt das Prinzip von Automator (OS X) her. Auch Andreas stimmt ein, es ist sein Favorit auf iOS um Arbeitsabläufe anzulegen. Deshalb gibt es geradewegs vorab die Workflow Workflows von Andreas “Zettt” Zeitler schickt verschnürt in einem Blog Post. Patricks stimmt mit ein, Workflow ist sein Lieblingsroboter auf iOS. Coole Workflows die andere geschneidert haben: Da Patrick es verpasst hat zeitig alle seine Worflows fachgerecht für die Show Notes aufzubereiten. Gibt es an dieser Stelle nur den Hinweis RocketINK im Auge zu behalten. Als kleine Wiedergutmachung, gibt es dieses Sammelsurien von ihm hier: Best Workflows (@BestWorkflows) on Twitter Workflow Gallery Workflow-VCS.de und natürlich die offizielle Gallery in der App Andere Workflows die Patrick interessant findet sind: Annotate & Delete by Seth Clifford Get Images from Page Make PDF Convert to fnd​ io Add Text to Photo (Suchbegriff eingeben, Bild kopieren, Editieren, …) Get App Icon App Images Das Workflow jeder nutzen kann/soll erzählt euch Philipp Gruneich von One Tap Less. Für Filmfreunde ist dies hier noch ein Schmankerl: The new Workflow and the Movie Diary bzw. die Version für Fortgeschrittene “Tweaking the Movie Diary”. Open Twitter Open in Tweetbot View Google Cache The Photo Message Gun With Workflow.app for iOS YouTube to MP3 to Dropbox to Huffduffer oder YouTube To Huffduffer Home ETA Für Fotos: Time Machine Wayback a Dead URL Der Textvernascher: Drafts Svens App wird benutzt um OmniFocus zu befüttern und in Markdown schick formatierte Mails zu versenden. Mehr zu OmniFocus + Drafts + Meeting Minutes gibt es auf seinem Blog. Kurz: Alles was mit Text anfängt ist einen Draft(s) wert. Mitflieger Patrick nutzt Drafts auch für jeglichen Input. Bei ihm gestaltet sich das ganze ähnlich: Markdown im Hintergrund an Person X emailen, die Einkaufsliste eindiktieren und an Reminders schicken, ab und an wird noch Evernote mit Vokabeln oder harten harten Raps versorgt. Der gute Andreas nutzt vor allem gerne das Location Feature von Drafts, da das unschlagbar schnell ist im auslesen von Longitude und Latitude. Zack. Plain-Text kommt raus und kann in jede Maps Anwendung geworfen werden. Hier runterladen. “Open in + Share” um Plain-Text weiterzureichen, OmniFocus mit Notizen, seine Send Link to Dropbox Hazel Action und das Gewicht-Tagebuch. Launcher in der “Today View” Cromulent Labs hatte mit Launcher für iOS8 ja einen schweren Einstieg. Erst hatte Apple die Today View App verboten, dann doch noch nach Monaten zugelassen. Für Patrick ist die App ganz großen Tennis, da man hier praktische Clipboard Workflows direkt von überall aus aufrufen kann ohne extra die Anwendung zu wechseln. Die anderen beiden zucken nur mit den Schultern. Web-Automati: “Sie rung” mit sich wie wild Frau Zapier (AffiliZettLink – 100 mehr für dich und ihn) findet Andreas gut. Der neuste Meisterstreich zeigt wie man auf Trello postet kommt demnächst auf seinem Blog. Zapier ist ja wirklich umfangreich um es milde zu sagen und da wir genügsame Sparfüchse sind, wird auch direkt auf IFTTT umgeschwenkt. Zum Beispiel findet Patrick das Markdown-Pinboard Archiv von Andreas echt gut. Hier ist seine fast komplette aktuell genutzte Sammlung die dank iOS 8 recht kurz ausfällt. Wegfallen sind nun zum Glück Sachen wie per LCP über IFTTT Nachrichten oder Dateien senden, Pinboard nach OmniFocus per Maildrop, usw.. Abschließende Worte Vielen Dank noch einmal für die zugesandten Fragen an unsere Hörer. Dazu sei noch angemerkt, Heimautomatisierung ist nicht hinten runter gefallen, aber so weit sind wir einfach noch nicht. Die TextExpander Touch Tastatur ist hinten runtergefallen, aber hier nutzt sie nur Sven, Andreas mag sie nicht und Patrick braucht nur die Anbindung in ein, zwei Apps. Natürlich haben wir jetzt nicht jede App ausgekramt die toll Sachen automatisieren kann, wie z.B. TextTool. Aber… das da oben sind unsere Sieger der Herzen. Vielleicht kommt irgendwann mal ein Teil 2. Nebenbei… der Jailbreak Himmel steht dem geneigten Nutzer noch immer offen… man sollte es kaum glauben, aber hier mal zwei Links zur Inspiration: Advanced Workflow Launching for Jailbroken users. Send home button, sleep button, etc at the end of workflows using Activator. Und ganzzzettt wichtig am 9. Juni 2015 in Stuttgart präsentiert Andreas euchdir : Warum auch du ein CRM haben solltest. Ebenso wichtig: Das OmniFocus Bliss Webinar mit Sven. Unsere Picks Andreas: djay Pro Patrick: Showmaster Sven: FlipBoard In Spenderlaune? Wir haben Flattr und PayPal am Start und würden uns freuen.

Nationaal Archief Truth in Advertising Fussy coffee. Exemplar The move from crack to fine coffee roasting The inevitable slide towards coffee mediocrity Tonx Blue Bottle K-cups Coffee with DRM HP Ink coffee synergy Did someone ask for an avenging angel to be added to Boards of Directors? Board of Average People Drunk Modes Temper tantrums overhead Shell inception sudo Dagerous commands Gmail Goggles Breathalyzers Legally drunk PSA (with bonus callback) Hazel needs a drunk mode Python Guy College nicknames Pythonista Reasons to use Python Good science support Whitespace matters AppleScript is a dumb language Node.js and learning through problem solving Ruby why or why the lucky stiff (not unknown anymore) Nothing really disappears from the internet why’s (poignant) Guide to Ruby “Some jerk researched him”; Lots more Sad hipster Related, anonymous people on the internet are weird Seriously, Back to Python Resizing and cropping images for fun and profit Macdrifter Editorial workflow for images Workflow distorts images The fiddler Breaking iOS within the Rules Ruin your life with Pythonista Doxing oneself Peak scripting “Exhaustive” app research instead of scripting Kids ruin Daddy’s concentration Actually creating script on iOS “It’s all Ole”, i.e. genius Tasker as Android’s uglier utilty tool Scripting: The Nerd’s Song Inability to read documentation indicates a lack of seriousness “Big-boned phone” Forcing Apple Evolution Constraints foster creativity Android’s freedom and iOS’s artisanal app market CyanogenMod Android text editors are nothing special, however, ssh plus Vim is wonderous iOS-only as clickbait Quitting the internet as clickbait The misjudged Federico article Peak iPad Thumb-typing Rumors! 12” MacBook Air We want a small device with a built-in keyboard 13” MBPr vs. MBA Airline seats are getting smaller “And Leon is getting larger” iPad apps that should be on OS X Editorial Pinswift Mr. Reader Drafts Rosetta Android apps on Chrome OS Some officially The rest unofficially Webapps are fine (or awesome) Fastmail Feedbin Trello Slack Pocket Casts Styluses…Stylii?…Digital-Marker-thingies FiftyThree Wacom Bob’s Surface Pro 3 replacement Finger-painting The software is better even if the hardware isn’t Spider bites and Farewells Blizzards in Boston Tauntaun survival Trains in the snow One-handed keyboards