I wrote a markdown book on Programming and Digital Humanities. I learned how to use Rstudio and Rbookdown on the way, they made it super easy to write the book. So I ended up with an R Markdown file (.Rmd).
GitHub was the first choice to share it. It renders Markdown directly, but not .Rmd — Yuhui has a wonderful post on why .Rmd is not rendered as .md on GitHub. So I changed it to standard Markdown (.md). People can preview the book, something may get lost in translation, but having the stuff out was already cool.
My first attempt was all hand-made text editor “design”. A useful learning experience, but quite painful and inefficient. Can I do any better with further exposure to different tools?
We are going to:
We’ve been here before. Working in academia or knowledge production the “wouldn’t it be nice to have a website?” thought jumped in our mind more than once. Maybe it was for networking, for sharing our work or a project, for teaching, etc.
Then a deadline came or there was a talk to be prepared, an unexpected application to be written, yet another assignment passed semi-aggressively from your boss or, simply, we were resting for the first time in X years (hoping X != 10).
Long story short: the blogdown package is there to change this and help.
As academics we…
We are out there willing to start a journey into programming, data science, machine learning… you name it. Where do we start?
There are tons of resources available, a lot of math to learn/refresh, and more. And we want to have some shiny projects to build. We can brag about our project but, mostly, we can apply what we are learning and actually do the stuff.
The first idea is that of Fred Durst. We take a look…
I was watching this video on 5 Python Projects for Beginners and realized there’s something wrong with how I approach tutorials.
So here’s a little list of shared thoughts I wish I’ve read before getting into tutorial hell. (Which I reviewed after reading this hard procedure to get into hacking — comparing the twos is out of scope for now. If something resonates while you read the guide, go find you 10–50 lines script to play with, and please come back writing about your experience).
Sometimes I feel too respectful with tutorials. You browse a tutorial because probably there’s something…
Learning to program implies installing tools and setting things up. Often installing software and setting up is a boring task and something I am likely to forget — unless I write about it or have to do again (what a pain!) on a different laptop.
There’s quite a lot to read about getting started coding, comparing resources, etc. I’ve read quite less articles on all the things you may end up installing on the way. So I went down memory lane and did some review of my download folder. It was an instructing trip!
This is an attempt to wrap…
Ten years ago I met Lorenzo for what we can now call “a social media road trip” (it was 2010). Things evolved. Ten years after (and a recent website redesign) we looked like a good opportunity to catch up and talk business, social media agencies, data, and smart working during health emergencies.
(Lorenzo was kind enough to go through two rounds of Qs and provide the photos.)
“Ok, let’s start with the What’s your core Start-Up Activity? kind of question…”
Thanks first of all for this interview, not just for me but for the opportunity to speak about innovation and…
This is a short(ish) list of vocabulary pieces that pops out as you start coding but may not be 100% clear. Vocabulary is part of the things that may contribute to make Python look mysterious for beginners (others are here). Here I focus only on Acronyms only. Ok, you may google that, but I’ll save you that. An I’ll also divide them into areas, more or less.
In the book (p. xxxiii), Harry — yep, the tone is such that you feel friend with your TDD guide — says some like don’t use Anaconda (or if you want do it at your own risk) and leave your IDE for this book. Nonetheless, I am getting quite used to Anaconda, Python, Markdown and RStudio. …
Command Line Interfaces (CLI) are a primary tool to communicate with machines. Instead of pointing, clicking or touching (graphics stuff of a GUI) you simply write down what do you want your machine to do. Of course you need to agree on some language, which forces you to know what the machine is able to recognize.
If this sounds terrible old school or retro, you may be right. Neil Stephenson has a terribly good book called In the Begining was the Command Line (which you should read and, given it’s on the Cyberpunk library for free, you have to read)…