Call for Speakers: March

[billyroh]

We're looking for speakers for our meetup!

How do I submit a talk?
You can either comment on this issue or send us an email at talks@wafflejs.com.

When and where will it be?
When: Wednesday, March 7 from 7 to 10 PM.
Where: Soma StrEat Food Park

What should I talk about?
We don’t have a strict formula, but this is the balance we try to strike every month:

• 2x Creative Talks: Creative applications of programming. Past examples are generating lego murals out of static images, and building an in-browser RPG.
• 1x Passion Talk: Something you’re excited about outside of work. Past examples are starting and maintaining an open source project, and using meditation and programming side by side.
• 1x Technical Talk: A deep dive on a technical topic. Past examples are optimizing your code for the V8 JavaScript engine, and using functional programming for developing UI.

Do I need to be an expert to talk?
Nope. This meetup is supposed to be fun and casual, so we want everyone to participate. We especially encourage people of underrepresented groups to apply.

How long should my talk be?
Ten minutes. There won't be any formal Q&A.

What should be in my talk submission?
We don’t have a strict formula for this either, but past successful submissions have included the following:

• What the audience should take away from the talk
• Why you’re excited about the subject
• A general outline of your talk (bullet points are good)

If you only have a rough idea, we’re also happy to workshop your idea with you in the #wafflejs channel on the BoroJS Slack team.

What's the A/V situation?
We'll have a projector and a mic for you to use. Let us know if you need any fancy adapters (we'll have some Apple ones).

Can I submit a talk for a thing I made, for either myself or my employer?
Generally, no. We've found that when people give talks about a thing they made, it comes off as self-promotional. We'll make exceptions for this though, especially when it's less about the thing, but rather lessons learned by making the thing.

[bengotow]

Name: Ben Gotow
Twitter: @bengotow
Talk Title: Re-visiting Cocoa, Apple's forgotten kids programming environment

Talk Description:
Did you know Apple was teaching kids to code before it was cool? In this talk I'll revisit Cocoa, the "internet programming" environment that Apple built for kids in the late 90s. I'll fire up a Mac OS 7 emulator and show what made Cocoa so groundbreaking. I'll explain how "programming by demonstration" and "actor-based" educational environments lower the barrier to entry in computer science and establish mental models that make it easier for kids to write great JavaScript later. tldr: Don't teach kids to write for loops, teach them to think about state machines and scopes!

Aside: This could be a talk about a thing I've made—I'm working to re-write Cocoa in Javascript / React to make it accessible to a new generation of kids, but I'd probably just put that on a slide at the end.

More about me:
I lead a small team building software at Foundry 376 and maintain the Mailspring email client (formerly Nylas Mail). I got my masters in human-computer interaction with an emphasis on K-4th grade learning environments.

Thanks!

[danisyellis]

Name: Dani Gellis
Talk Title: How to Navigate Large Codebases When You're Used To Simple Projects
(I'm open to changing this name if anyone has something better :-)
Topic: Basically, this talk would be for intermediate level coders who have mostly been working on their own small projects. They'll get tips for how to start understanding a large codebase and then how to write code in it.

Outline:

1. How do I even start looking at the ginormous codebase?

• Start by getting a general overview of the architecture of the app
  • draw a diagram with each piece. Start with front-end, back-end, and the connecting piece
    • then, fill them in with the tech stack and microservices (ex. front-end React and Redux)
  • using the diagram, look through the folders and try to find the folder that’s used for each different tech and each microservice
    -get something like hyperclick (in Atom) that allows you to command-click on a function call to see the function declaration. Also, use your editor’s full-project search feature to see what file is calling a certain function.
  • once you have a general overview, if you have access to someone who knows the codebase, ask them:
    -what’s unique about this codebase?
    -what are the gotchas/ what won’t be obvious?

2. How do I start working on my feature/bug?
   • You can start even if you’re not sure how everything works yet!
   • Start by writing an implementation plan
   Which technologies will you be using and when? Which files do you need to use to change things for those technologies?
   - get as detailed as you can
   - this will a) be useful when you’re writing code and b) tell you what you don’t yet understand
   - once it’s written, get someone to check it and tell you what you're missing
   • Start coding!

   • just start somewhere. Try to start at one end and go from front to back or vice-versa.
     • if you don’t understand enough to do that yet,, just start at the easiest thing that you think you understand
       • start with something that already has some similar code you can copy
       • don’t be afraid to comment out code or add code and see what happens (name a branch play and play around)
       • be ok with not understanding everything at once. but if you stick to your work-plan you’ll be going step by step and eventually get it all and I promise by the end of that you’ll understand how everything fits together much, much better.
     • as you’re working, make notes in your implementation plan. This can be a living document. I write down questions to check on, things to remember to go back and do, etc.
       • by writing this down, I take a layer of complexity out of my head.
       • Also, by making myself write out the question, I often get more clarity on why I’m confused. Often, by the time I’m done with the things I know how to do, I can answer my question.
       • Whenever I don’t know what to do, I look at the list!
     • As you’re working, draw more diagrams for things that are complex.
     • As you’re working, ask yourself ‘which pieces can I ignore right now?’. We all want to understand everything but that’s impossible in a large codebase. Trust the abstractions.
       • ex.: if a function is called getCommentsForPost, you know what that does
     • when you have lots of files open, put them in order
       • I do the order each file is hit by the app
         • within that, files that you’re comparing can go side by side
     • Before you leave for the day, make a note in the work-plan of what you’re working on (and the next step and the next) and clear off any to-do's
       • commit what you have as a WIP - start fresh tomorrow
         • commit -p to chunk commits

3. How do I keep from pissing off the other people working on this codebase

   • Be thorough. Don’t leave work for anyone else cleaning up what you did.
     • Run the tests
     • make sure things are still named correctly, etc.
   • Make sure you know how the project maintainers want to handle things like pull requests

In conclusion:
Big codebases can be a joy. When you’re like ‘how do I even do this?’ there’s usually an example :-)

[MaxBittker]

Name: Max Bittker
Twitter: @MaxBittker

"require('WebGL-magic') with glslify"

Description:

WebGL: Really cool, both for the obvious immediately visual grab, and for the opportunity to explore a new programming paradigm that will expand your horizons!

Problem: It's hard to learn, because:

A) The api and tooling is obtuse and raw
B) The primitives/ assumptions are different and weird if you're used to programming CPUs
C) There's some math (which is often taken for granted by learning resources)

In this talk, I'll break down and present some of the key interesting concepts, as well as introduce a tool that's helped me to learn and build cool things: glslify! (analogous to npm/bower/browserify, but for webgl shaders!)

My thesis is that being able to leverage an ecosystem of friendly micro libraries gives you not just the power to build things faster and enjoy yourself, but also acts as a guided tour through different concepts in a way that's more discoverable and approachable than writing all the primitives from scratch.

Some goals here are to make the talk interesting to newcomers who just want to build a mental model of what GL is and how it works, and also give people on the fence an impetus and framework for giving it a shot! I also want to use it as an allegory for why an easy to leverage package ecosystem is so important for a language's user experience and success.

(I do have more detailed notes written out, so let me know if you're interested to read those)

I'm speaking from the perspective of being a hobbyist who's benefited from the glslify ecosystem to build pretty things and learn about gl, but thinks it should be easier to learn!

Thank you!

[billyroh]

Thanks for submitting, everyone! @chromakode should have gotten back to you all by now. Here's the CFP for May 👉 #313