Center for Brains Minds and Machines on GitHub
-
Masters Students & Undergrads, join the CBMM Engineering Intelligence Team!
July 21, 2016 by Greg HaleInterested in Deep Learning? AlphaGo? TensorFlow? Adversarial networks, and ‘inceptionism’?
What about software engineering? Curious about web development, functional programming, or the way teams of engineers automate testing and deployment?
The Center for Brains Minds and Machines is starting a new experiment. We’re bringing together small teams of students interested in research, engineering and design; to develop projects in a style more like a small company than the typical research lab. We won’t have customers and investors, but we will have synergies between people interested in design, research, and engineering. We will have individual ownership over components, engineering discipline, and practical short-term goals.
Because CBMM is NSF funded, all of our work will be open source, and we will develop portfolios we can be proud of for the next steps in our careers.
To learn more about our research, look at the CBMM website. For more about the CBMM Corps projects, look through what we have here on CBMM @ GitHub. See what Specialist Teams and Projects we have in mind.
If this sounds like something you want to be involved in then please send your resume or github handle to Qianli Liao with a brief (one or two paragraphs) description of your learning goals. If you have access to the MIT UROP office, please apply to our UROP ad.
-
Processing video for web experiments
March 16, 2016 by Greg HaleSo you want to put video clips online for your experiment. In this article I’ll introduce you to some tools for processing video files for use in experiments. In another I’ll describe acquiring data from subjects watching videos.
I’m here to help with this kind of thing. Please get in touch if needed! If you want to learn to do it for yourself, that’s also fantastic, and I hope this guide helps. If you discover a problem with the instructions, please let me know on our issue tracker.
Where to start? There are three phases to think about:
- Creation
- Storage & Addressing
- Delivery
-
Artbitrary
February 16, 2016 by Greg HaleWhile setting up a test suite for CBaaS, I needed to produce random images. An
Arbitrary
instance for JuicyPixel’sDynamicImage
type is the way to do this in Haskell. While producing a list of randomPixel
s at different colors would have been enough to make the tests work, the output wouldn’t be very interesting to look at - it would just be colorful white noise.What if we use QuickCheck’s ability to produce arbitrary functions, and pass an arbitrary
(Int, Int) -> Pixel
function intogenerateImage
? Instead of fully random pixels, we would get random functions that determine a Pixel’s color from its location (it may seem like the difference between random Pixels and random functions producing Pixels are one and the same - but the random pixels case is actually an extremely specific function).How does QuickCheck produce random functions? What would I expect the output to look like? I have no idea, although I’d to look into it. In the meantime, here are some examples.
-
Opening up your research to the web - Day 4
January 14, 2016 by Greg HaleLast time, we discussed some austere topics around blocking and asynchronous execution, and we may have started to feel like insurmountable piles of jargon stand between us and a working site, while our page still consists of just ugly input boxes and 90’s-looking text labels. Today we’ll let our right brain have some more fun.
We can start with paper and pencil. Dry-erase boards are great too, because we have some colored markers to work with, and the thick lines are nicer to look at.
Imagine your page, and take your time to draw what you see. Like writing1, drawing a draft forces a level of concreteness to your idea that can’t be gotten through imagination alone2. This isn’t just about the design - it’s also about discovering features.
-
Opening your research up to the web - Day 3
January 13, 2016 by Greg HaleIn our last lecture we set up a server to call one of several shell commands depending the URL. I wouldn’t recommend just rereading those posts in order to start web programming - instead you should refer to the very good documentation released with a web framework like Snap or Flask. When you get some familiarity with the languages used (Haskell and Python respectively), then the details in our code samples will begin to make more sense.
Direct library calls vs. shell commands
The servers we built were language agnostic. They can call any program you have installed on your system, passing arguments through the command line. Sometimes we can trade away language agnosticism for convenience and code quality. For example, if the scientific application is written in Python, and our server is written in Python, then instead of using a
process
library to call out to the shell, we can invoke our scientific function directly from the Flask handler. -
Opening your research up to the web - Day 2
January 12, 2016 by Greg HaleIAP can giveth, and IAP can taketh away. My bustling class of five has dropped by three and picked up one new student, then lost another. But hope is not lost. We may have a real project to work on. Our student from chemistry works on a very active Python codebase called the Reaction Mechanism Generator.
Useful as it is, installing the dependencies has apparently been hard enough to limit adoption, so we want to expose some of its functionality through a web interface. Just what I had in mind for our class! We’ll dedicate our three remaining sessions to this, hope that it benefits the Reaction Mechanism Generator project, and then see if the skills we learn spill over into other projects.
Servers
On Day 1 we talked about static assets like
.html
files,.css
files,.js
scripts, and images. When the all we need to do is deliver these files to a user, we don’t have to handle writing any code to serve the files; we can just find a static hosting services like GitHub Pages or Amazon S3.But that was a whole day ago, and today we want more.
-
Opening your research up to the web - Day 1
January 11, 2016 by Greg HaleDay 1 of Opening your Research was a big hit! Five people showed up. Three of them are young grad students. One is an MIT alum from the class of ’77, who took Patrick Winston’s (my dear boss) first Intro to Artificial Intelligence class. And finally there was an MIT alum in his 40’s who holds some of the early wind-energy patents. Great group! I’m disappointed that the ’77 alum won’t be sticking around, but the remainder sound like they will be here for the week. That’s enough time for us to get some things done.
Let’s take a look at the goals I write down earlier today and see if we met them.
- Start collaborative relationships with at least a few students interested in giving their research an online presence.
- Give everyone enough confidence to continue learning and implement their own data/tool-sharing when they’re ready
-
Opening up your research class - Day 0
January 11, 2016 by Greg HaleGoals
- Start collaborative relationships with at least a few students interested in giving their research an online presence.
- Give everyone enough confidence to continue learning and implement their own data/tool-sharing when they’re ready
Ideas
- Datasets on S3 with descriptions on github-pages
- Contributing to reffit and reffit-like projects (peer review reform)
- Stand-alone servers running algorithm demos
- Programmatic figure generation, interactive graphics
- Helpful lab-widget webapps (calculators, timers, etc.)
- Publishing negative results as a blog post
Predictions
-
Teaching Git & Github
January 8, 2016 by Greg HaleToday was the last of three one-day sessions on git and GitHub (here is the course description). Next week I’ll lead a one-week course called Opening up your research to the web.
We had 18 students in total, most coming for just a single 1.5 hour session. Students’ ages were anywhere from 17 to 60, with the elder ones tending to be there to listen. The average reason for attending was more or less:
-
Hakyll setup
January 7, 2016 by Greg HaleHere is the first post on the CBMM @ Github website. As explained on the About page, we wanted a space to organize the open-source activity going on at the CBMM, beyond just the wall of repositories on our github org page.
The design decisions reflect the broader universe of the CBMM software situation. The developer staff is small, and there are far more projects to do than people to do them. At the same time we want the site to be reliable to maintain and simple to edit with the same workflow that we use for developing software. We also want the development process to be totally open. So, GitHub pages is an extremely good fit for hosting. We don’t have to do any maintenance or worry at all about backups. And the site content is generated mainly from markdown via the fantastic document converter pandoc and static site generator Hakyll.