Have you wanted to get started with a conference speaking career but don’t know how? It’s a lot easier than it appears on the outside!
Own Your Expertise. We are all experts of our own experience. Sharing our path, passion, and knowledge inspires others. We don’t need to know everything about a topic to have something valuable to say!
I was inspired by three different sources to give a talk at Barcamp this past Saturday.
First, I attended the inaugural Write/Speak/Code conference last year. During the Write day, we learned how to own our expertise and write op ed columns (something that’s on my short term goal list). The Speak day was all about the mechanics of drafting and submitting talks. (Pam Selle and I spoke on the Code day about feminist models for open source participation).
I gave a workshop today at Barcamp Philly that heavily drew from Julie Pagano’s workshop and slides. I reorganized the time frame (her workshop is a whole day and walks you through many more steps of conference presenting) and made it fit in a 45 minute time frame.
Have a short deadline? Boss breathing down your neck?
Don’t start prowling github just yet! Work through the following steps first.
1. Determine what you need.
Sounds simple, but so often we skip this basic step.
When Women Stopped Coding is a (mostly) non-depressing look at what was happening in the 80’s and 90’s to contribute to the plummeting number of women in computer science. In particular, I hadn’t thought deeply about the emergence of computing have and have nots.
My parents didn’t buy a computer for the home. Luckily I had access to computers at my friend’s homes and was on the Internet pretty darn early via Tallahassee Freenet & BBSes in 1995. I went to nicer middle and high schools that had technology classes (though not programming, just typing). I often frequented the library to get online. I loved finally having 24-hour access to the computer lab in my dorm during my first year of college (1998).
Frustrated by fragments? Intrigued by dependency injection? It may be tempting to switch approaches to solve your current pain.
Don’t throw away that code just yet! Think through the following questions first.
1. What problem am I solving?
Square has come out against fragments, and if this r/AndroidDev thread is any indication, plenty of developers are ready to jump ship. Let’s take a step back from the hype and think through their proposed solution.
A recent question got me thinking about how I use logging in my development/debug process.
First, remember that it’s easy to lie to yourself with logs. I can’t tell you how many times I have made incorrect assumptions about what is going wrong with my code based on the truth presented by the logs. Eventually after exhausting all the other options you finally start tracking down the real problem.
Second, I generally use logs when I’m trying to understand the control flow of my program. It’s completely up to you when you want to use them. I often add log statements to the lifecycle methods (e.g.
onResume()) and important functions that I create to do the work. I like to add the value of the the item I’m inspecting or handling in that function.
When reading the reviews on one of the Android books I recommend, I came across this question:
I read the chapter on UI and the section on fragments. I followed the given example step by step and got it to work. So far so good. I then attempted to build my own solution of dynamically adding fragments to a layout. I’m none the wiser as to how to reference the views within each dynamically added fragment. The 3 things I really want to know about any control: (1) how to add statically, (2) how to add dynamically, (3) how to reference any view I place into the UI.
Fragments can be a tricky subject! I’ll break down the difference between static and dynamic fragments in this post to give you a better idea of how they work.