Today, post PyCon conference, I spent the entire day immersed in an incredibly dynamic and educational workshop by Software Carpentry “Learn to Teach Programming“. I’m going to do a mix of dumping my notes in a play-by-play fashion with possible sidebars for commenting on what I experienced personally so that I have a record of this to look back on as I move forward with Ascend Project planning and execution.Meet Your Neighbours
The event started off, as they always do, with a go-round of people introducing themselves in short form. As we started taking turns our teacher, Greg Wilson, asked for the person who just spoke to tap the next person to speak before sitting down. This proved to be our first of many small applications of the science behind learning and how it can play out in real life. While it apparently takes a room of kindergarten children 3 reminders to do this extra step during intros, it took this room of ~25 adults 14 requests before we mostly started doing so without prompting from Greg. By the way, during the intros I learned about Dames Making Games which I can now add to my mental list of awesome women-in-tech groups and if you’re reading this and are in Toronto, check them out!Teaching Is Performance
It raises your adrenaline, brings out your nervousness, and it’s something you need to work at. A few quick tips from Greg on preparing for your ‘performance’ as teacher: always bring cough drops, and figure out what your ‘tell’ is. Like with poker, everyone has at least on thing they do when they are nervous. I suspect for me its likely that my ‘tell’ is talking fast and/or having trouble not smiling too much (at least in poker, it is). This was our first introduction to how we should be reflective about our teaching – even go so far as to record yourself if you can’t get honest feedback from people around you – so that you can spot these things about your manner and work on adjusting them to ‘perform’ teaching in a more confident and reliable manner.
Improv came up as a way to work on this where you can get feedback on how you perform and also learn to keep other people engaged. I used to do improv when I was an awkward teenager and didn’t feel like I was a superstar at it but I wonder what it could be like now that I have more confidence. I’ll be looking for classes in SF to try it out. What’s there to lose?Why Don’t We Teach In Teams?
Greg pointed out how teaching, unlike music and comedy, is such a solo activity. Musicians typically build up their experience and skills by playing with others. The best comedians by and large spent a significant amount of time in some sort of comedy troupe before striking out on their own as a stand-up or as major film stars. Teachers though? Often alone in their classrooms and if my partner is an example of the ‘norm’, definitely alone while grading and preparing lessons. This is something worth exploring: what could teaching be like for the teacher if there was team teaching? What could we do with more feedback, more often, and with someone helping us track measurable progress towards our goals as agents inspiring learning? Finland has an excellent system of teacher feedback and peer/mentoring for their educators. Teacher’s college is harder to get into there than medical school (not sure that’s a good thing, but it’s what Greg told us).Key Points About Teaching & Learning
- People have two kinds of memory layers – short and long term – and short term memory (which is what we are working with in classroom environments) can hold ~7 items +/- 2 so really we should aim for 5 in order to teach to our students’ capacity
- We have to balance on/off time – we lose some time switching between tasks or concepts in the teaching but working with memory limitations as mentioned above, we must let people take breaks to reset & refresh
- Avg person can take in info for about 45 minutes before their attention wanes from exhaustion. For me, this is more like 30 minutes. Hearing this from Greg reminds me that I want to propose that all meetings I’m involved with at work move the default length to 30 minutes and that we have a set of rules for how to deal with ‘overage’. Either email or mailing list post, etherpad, set up a follow-up meeting, or make a proposal and request feedback so that we are not taking an hour because we *have* an hour.
- Apparently the military has a lot of research and effective solutions for human performance. Greg mentioned being at a naval academy and the grad students he was lecturing to dropped into doing pushups when a bell sounded on the hour. This sounds like a great practice for anyone trying to learn and be engaged with others – get your blood pumping and change your position. Reminds me to get that automated rest-taking app running on my laptop again and to actually pay attention to it for a while instead of dismissing over and over.
- Continuous ‘flow’ – oh that elusive state for programmers. There was some sort of quote about coffee but I missed the first part, the gist was that when we are immersed in something and truly engaged we can override that 45 minute intake limitation from before but if we do more than pause (without switching contexts) we could end up breaking flow and it takes at least 5-10 minutes to get back into it. This is key for people who work in environments full of distractions and interruptions. I’ve been thinking a lot about this one lately as I’d like to work on breaking my very unproductive cycle of checking IRC and email in a loop as though I am event-driven. I need to make times to get into ‘flow’ and do bigger tasks with more focus.
- A sidebar of the distraction mention was the fact that, in programming, syntax can be the distraction. That is, errors in. When you get stuck trying to figure out where your semi-colon or indentation is off you break out of ‘flow’. In a language/framework like Scratch this is not possible as the blocks cannot be dragged and dropped into any order that creates errors except in ways that are related to logic and program flow – worth stopping to think about (and keeping you in your engagement ‘flow’)
- There are roughly three types of minds out there to work with in teaching: a) Novice b) Competent c) Expert. The Novice doesn’t know what they don’t know so the most important thing to do when trying to teach a Novice is to make sure their mental model of the concept you are teaching is correct. This is to become a lot of the focus in the rest of the day – methods of determining if our concept is getting across correctly. The Expert is such because they have more connections between all the facts they know about the concept/skill and so they can leap from point A to point J in one move where it takes a Competent mind all the dots in between – executed well, but with thought and intention – to complete them. It is *as hard* to get Novices to become Competent as it is to get Experts to see the concept they are trying to teach as a Competent person does. Think about something you might be and Expert at and see if you can tell what steps you assume other people will know.
- Another key point about the Expert is the idea of reflection. Being able to reflect on your skill is huge for honing it. An example would be how I went to a hockey skating workshop where they video taped us skating our fastest and when I saw that video, saw how knock-kneed I was and how my internal map that I was using wide leg strokes did not actually look like that in the tape I was a) horrified but also b) it’s a reminder of how far I have to go and how much more work I need to do in order to reach a higher level of expertise, such as that reflected to me by the instructors.
We spent some time talking about critique. In architecture, art, music, and many other disciplines there is a built-in system for critique. It helps the student to build up their sense of self, to know their strengths and weaknesses. We do not always have this in teaching. In our workshop, Greg had people write down one piece of positive and one negative feedback on two sticky notes (yellow for positive, pink for negative) and he asked us to put them on a piece of paper at the front of the room before we headed out on our first break (just over an hour of instruction had occurred). When we returned we discussed what the anonymous feedback had provided Greg with and what he could actually work on in the moment vs. what was useful for later. He mentioned doing this, and letting it be anonymous, was a great way to build trust with your students. Also we talked about how to get better at accepting feedback, working with it, not letting it paralyze you or derail your lesson.
One of the key takeaways for me here was the idea that the most senior leader/teacher should model this for others. Show that you can hear feedback, both good and negative (hopefully constructive), and be able to move forward without crumbling under the pressure. While I’m nervous about feedback, I will do my best to ‘fake it till I make it’ on this point because it’s definitely more important to correct course and create a better experience for students than to be proud and lose their interest and especially, trust.Concept Maps
Our next major concept was the concept map. This is a way to help yourself understand what you are trying to teach. It’s also a way to check yourself for the 7 items +/- 2 factor. If you have more than 5 main concepts in the concept map, it’s time to evaluate it for what can be put aside for now or what can become the next lesson. The concept map can also be shared with students as a way to make sure everyone is on the same page or at least starting with the same page. Greg recommended handing out a printout of the concept map so that students could doodle and expand it in ways he might not have thought of.
We learned how the concept map should never be used for grading. It’s mostly a tool for the teacher to know if they have managed to get across the mental model well enough for the novice to reflect back a matching map and feel comfortable moving on to the next concept. It’s also a way of preventing the “blank screen” where students can be frozen trying to come up with what to put down (in programming or in writing) and having a scaffolding there in the form of map, or hints, any form of guidance can basically jump start the student and hold their hand until they need less and less of it to self-start, self-direct, and truly *learn* autonomously.
We did an exercise where we drew up concept maps for how to teach a for loop. This was my first time doing a concept map and it was hard. Definitely will take practice and likely some more reading/looking at other concept maps to drive home the concept for myself.This is an attempt to map out the concepts required to understand a for loop – note we went over 5 items
Key points from Greg:
- Make your concept map look ‘cheap’ so that people aren’t afraid to give you honest feedback
- Write and share maps with each other – try this with your team at work on a project you’re starting – you might see that others have a *very* different sense of what is being attempted
- Try not to need things in your concept map that you will “explain later” – if you can’t explain it now you’re going to disrupt the ‘flow’ of maximizing the short term memory limits
- Transfer your map into a list of bullet points as it will help you put the most important concepts first
- Think of concept mapping like couples dances. You both want to be doing the same dance or there will be a lot of bruised shins
We used sticky notes at several points in this workshop. While we only had two colours today, Greg recommends three colours to be used as follows:
- Green: Students can put this up in a visible place when they have completed the exercise currently being done
- Yellow: Students can put this up when they have a question. Also this is a great tool for ensuring more participation in the classroom setting. Some people talk more than others, there are definitely certain types of people who take up more space, and the deal with the yellow stickies was: You get two, when you ask a question put one aside. Another question? Put the other aside. Now you have no more questions until EVERYONE in the class has used at least one of their yellow stickies.
- Red: Students can pop this up in a visible place when they need help on something. This is great for two reasons: 1) the student can keep *trying* instead of worrying about holding a hand up and waiting for eye contact with a teacher and 2) the student can request help without drawing too much attention to themselves. This is great for classes with people who might have learned it’s best not to speak up, ask questions, or draw attention to themselves out of fear and/or shame.
This probably shouldn’t have *blown my mind* but it did. It’s so obvious yet I’ve never once designed curriculum with this approach. You can bet that’s all changed now. Here’s the key point:
DESIGN YOUR LESSON BY WRITING THE ‘EXAM’ FIRST
Ya. It’s maybe obvious. You want to make sure the students leave knowing what you intended to teach them? Well, figure out how you’re going to measure that success *first*, then build your lesson up to that. “They understand the for loop” is not enough. Be specific. Have a multiple choice question that tests the output of a for loop and gives 3 plausible answers and one right answer. Use this to check if you are teaching well – their failure to choose the right question is your failure to teach the concept correctly. This doesn’t have to be for actual grading (unless you want to grade yourself). Think of this like Test Driven Development for curriculum. Teach to the goal. You will develop lessons faster and more efficiently. Your learners will appreciate it. They can tell when they are learning vs. having a lecturer do a brain dump on them that goes nowhere in particular. Backwards design works. Greg’s book plug related to this section: “Seeing Like a State“
Another tip? Create one or more user profiles for your lesson. In our workshop we created Dawn: 15 year old girl who is good at science and math, learning programming in a one-day workshop. Then we did an exercise in crafting a question that would confirm if we had successfully taught how functions work to her.
We learned about Allison Elliott Tew‘s work and about “Concept Inventory” which is a way to use common mistakes in mental modeling to create multiple choice questions where the incorrect answers can help you understand *how* someone has misunderstood the concept you are trying to teach. Multiple choice is great because it’s quick to get you an assessment (teacher grading time).Peer Instruction
Related to multiple-choice as test of understanding is Peer Instruction. This is a method that uses a multiple choice question in a really interesting, and engaging fashion.
Developed by Eric Mazur in the 1990′s this method expects students to have done some pre-work on the material before coming to class so that the entirety of the lesson can be used to compare and correct conceptual maps and understanding of the material. It goes like this (at least Greg’s interpretation – it differs in Wikipedia as to how Eric designed it):
- Provide a multiple choice question based on the pre-work content. Ensure 3 plausible answers and one correct
- Students select and *commit* to an answer (there is not yet software for this, though there are clickers) – you can also ask people to hold up the number of fingers for their choice and have classroom helpers count
- If everyone picks the right answer you can move on but otherwise you ask people to talk in groups with their neighbours to examine each other’s choices and what the correct answer might be and why. This is great for having people explain their mental model/map
- Vote again and have students commit to the answer
- Instruction reveals the answer as well as perhaps a single sentence explaining why
- Groups discuss again, this time they can explore their understanding with the correct answer alongside people who, likely, had the correct model
This teaching technique was proven in 1989 but is still widely unused (esp. in MOOCs). Greg told us that he can usually do about 10 of these types of questions in a 1 hour class. We did an example of one in the workshop to test out the method and it was a lively exercise. This was also an opportunity for Greg to help us notice how noise in the room helps a teacher determine when a good time is to check in, continue the lesson, or make sure people aren’t stuck. Active, engaged learning is boisterous and noticeably relaxed. Quiet can mean focus, and then as people complete the exercise you can hear some discussions start up as those who are done talk with each other about the exercise. I look forward to getting a bit of expertise at this level of listening and was impressed by Greg’s skills in classroom energy level reading.Fuck It, I’m Outta Here
I have several more pages of notes but it’s getting late and this is a long post. There’s one more part of the workshop that I’d like to write about: The moment when you decided you didn’t want to learn something anymore.
This is a really great piece of advice for teachers. Greg started by saying that he used to ask students what motivated them to learn, what great experience in learning they had so he could tap into that motivation as a teacher. Now? He asks people what DE-motivated them. You get a lot out of people this way. Ask someone (or think of your own experiences): “What was something you were curious about, working on, getting into, and what happened that made you say ‘fuck it’ and drop it? If you could go back in time what would you change?”.
For my example I spoke about returning to gym class at 12 years of age after recovering for many months from a very physically traumatic incident where I was hit by a car while on my bike (15 bones broken, 6 months in a wheelchair). Being immobilized *and* being a pre-teen caused me to put on a fair amount of weight and I was no longer very physically active or able. I also had yet-to-be-diagnosed asthma. Not only did I have to endure a gym class where those with natural talents were help up while the rest of us were discarded but I also continued to fail tremendously at getting more than a “Participation” certificate(! Every other result got a very nice badge) for the Canada Fitness Test.
My “Fuck it” moment was when I got so frustrated with never getting a badge that I stole someone’s gold badge when no one was watching. I also ended up eschewing all sports and athletic pursuits for many years if there was any hint of tryouts or actual talent needed. Years later, at 29, I taught myself how to run by using a couch-to-10K program that did repetitions of running and walking in order to build up endurance. Not only did I succeed at that but I learned to *love* running and feeling healthier in my body. If I could go back in time I would become a Physical Education teacher and make sure every kid in my class knew that it’s not about natural talent at anything. It’s about setting achievable goals for yourself and comparing your results against your OWN RESULTS. Never mind some test, and other kids. We’re all very different but no one should be denied a sense of accomplishment. It’s what keeps you coming back to learn & build on what you’ve learned.The coveted badges.
Now Go Read More: Keep Learning How to Teach
It was an amazing day. I have more notes to transcribe for myself but I think I’ve managed to capture the major concepts I learned today that will all be invaluable in my work on Ascend and beyond. Greg is an experienced, passionate, driven teacher and his enthusiasm for *knowing* what works in education is contagious. I want to be a better scientist and educator too. The Software Carpentry movement is picking up momentum. Look for workshops, blog posts, and opportunities to participate in a town near you. See their site for up to date information and also check out their materials page for additional resources. I’ve got a few new books to read on the plane home tomorrow.
This is one of the most inspired moments in the history of athletics: Roger Bannister crossing the finish line on 6 May 1954 during a meet between British AAA and Oxford University at Iffley Road Track in Oxford, United Kingdom, where he became the first human to run the mile in less than four minutes. An extraordinary achievement which was, at the time, considered impossible. Seeing the picture of Roger crossing the line gives me goose bumps. Each and every time. This picture evokes so many emotions in me - in a lot of ways it’s the perfect capture of the perfect moment.
But we are getting ahead of ourselves. For now - keep Roger in mind, we will meet him again later.
“Reaching the finish line, never walking, enjoying the race. These three, in this order, are my goals.” — Haruki Murakami
This presentation is a story about running, running a business and running through life at large. And how all these things can be treated the same. A story about lessons learned. A story about failures, perseverance, winning and the sheer joy of accomplishment - large and small. And it is a story why we should never walk in life.
Let’s get ready… toe to the starting line.Part 2 - A True Story
“We embrace pain. Pain is the purifier.” — Runner’s Proverb
In 2008 I found myself with pretty severe depression. A condition and feeling which I never experienced before. I felt helpless. I didn’t know what to do. And I didn’t know how to get out of it.
Over the course of some months I first talked with friends and family and tried to fix it myself. Thought I could figure out what it was, mend it and move on. But it didn’t work.
Eventually, I knew that I needed help. So I searched for help. And found a fantastic therapist. She worked with me through a lot of issues in my past - but more importantly she asked me why I stopped doing sports years ago, having spent most of my youth engaging in one sport or another. I didn’t know the answer. Life just got in the way.
My therapist asked me which sport I enjoyed most. The answer was immediately clear to me - running. Running is primal. It’s hardwired into our brains. Humans are born to run.
So I started running again. I ran for life. For my life.
About 10,000 miles later, after endless hours on the roads and trails in every place I lived & visited ever since, running with and without company - I learned something. I learned that the fundamental lessons which running taught me, hold true for running a startup. And running through your life.
They are the essential rules for any entrepreneur. They are the essence of living life. At least if you want to do the impossible - and break your own four minute mile.Three - Ten Principles
“Somebody may beat me, but they are going to have to bleed to do it.” — Steve Prefontaine
Train hard. There is no way around it. It’s the foundation. Everything else will depend on it.
When I built my first startup, fresh out of university, I didn’t know anything. I had a huge ego and thought that I knew everything there is to know about building and running a startup. But I didn’t. I went into the race without training. It was ugly. I learned on the fly - which is fine. But I had people rely on me. And they suffered from my level of unpreparedness.
Train hard. If you want to race, you need to pour your heart and soul into the preparation. This is where races are lost and won.
Make sacrifices. Emil Zapotek is one of the greatest runners of all times. Emil wasn’t terribly talented or genetically gifted to run. But he made sacrifices. More than anyone else. And he won.
Building a startup requires huge sacrifices. I slept on the floor in my company when I worked through the night. I blew up a long-term relationship. I lost friends as I didn’t have the time to see them anymore. My first startup was a financial disaster. It was a sacrifice which, in the end, made me a better entrepreneur. And my following ventures so much better.
Make positive choices. Your life will be full of decision making points. Make sure you choose wisely. Choose the ones which will have a positive impact on you.
I made a choice in my startup which I paid dearly for - against my gut I chose the investor with the better term sheet. I wanted the money. When the company went downhill, it turned ugly. I didn’t make a positive choice - and paid dearly.
Seek your potential. I recently read that, unless you are an ultra-elite runner, you always have the ability to run faster. Always. I believe this is true for everything we do. Only very few people tap their whole potential.
Seek out your potential. Figure out what you’re good at and get better at it. Don’t waste time getting mediocre at something you’re bad at. It’s not worth it. I learned so much about myself doing startups, working at big, fast-growing companies and helping other entrepreneurs. I think I know my strengths now - and I am sure I haven’t reached the limits of my potential. Keep pushing. Become Muhammed Ali.
Set high goals. Remember Roger? When Roger set out to break the four-minute mile, people believed that the human body will never be able to run that fast. Doctors were of the opinion that the heart will explode if you run that fast. And despite all this, Roger knew that it was possible - he set his goal that high. And only weeks after he broke the four-minute mark, a handful of other runners broke the same barrier. The barrier was was only in their heads.
You can’t change the world if you don’t set out to do so. Be bold. Dream big. Who would have thought that we can put a man on the moon? Or that a little social network for Stanford students can become the largest website on the planet?
Relax under pressure. Look closely at Shalane Flanagan’s facial expression on this photo. Shalane is the world-record holder for the 3000m. And she is completely relaxed and in the zone while racing.
You can’t perform to the best of your abilities if you are tense. You will annoy the people around you. I know - I was tense when I did my first company. I yelled at people. It wasn’t nice - and it didn’t help. Learn to relax under pressure. Breathe deep - it will help you.
Attack pain. Pain is inevitable. You will feel pain. You can choose to let it dominate you or choose to attack it, ignore it, grind through it. At the end pain is just a neuro-signal. You can will your way through it. Pain is the purifier. Be Arnold.
I can’t count the amount of times I came to a point where I just wanted to stop. Wanted to give in to the pain. Or just take a break. Both in running, life and running my businesses. Ignore the feeling. Grind through. It’s just a neuro-signal. If its worth it - push on.
Push the pace. Go out and don’t hold back. Don’t be the guy who races in the shadow of others and tries to sneak by on the last few meters. Keep on pushing the pace. Steve Prefontaine to this day is the most courageous of runners in the world. He kept pushing the pace. Always.
You chose to start a company. Now do it properly - with every fibre of your body, continuously pushing the pace. Be bold. It’s the only way to succeed as a true leader.
Work as a team. Running looks from the onset like a very solitary sport. It is not. Roger had two good friends pace him through the first two and the third round of his four-round record run. Your team is everything. Without them you are nothing.
Embrace the spirit of the team in your organization. There is no room for anything else - you have to work as one, for a common goal. Even the brilliant Steve Jobs couldn’t make things happen without his team.
Run to win. History has it that Pheidippides died after reporting the Greek victory over Persia in the Battle of Marathon to Athens. Treat the marathon with respect. Run to win. Every time.
Don’t get into business if you aren’t in it for the win. And do what it takes to win. Honor Pheidippides. And run like Usain Bolt.Encore - Two More
“I’m going to work so that it’s a pure guts race at the end, and if it is, I am the only one who can win it.” — Steve Prefontaine
Defeat the wall. When you run a marathon you will hit the wall. After 21 miles of running your body simply runs out of glycogen and wants to shut down. This is the point where your will is tested most. You push through it. You force carbohydrates into your body although your stomach started cramping up at mile 15. But deep down you always knew - it is possible. So you persevered and set one foot in front of the other. Repeat. And repeat.
In every venture, I hit the wall. There always was the day when I didn’t want to get out of bed. Where I just wanted to throw it all down the drain and give up. Persevere. Get dressed, get to work, get going. Force yourself through it. It won’t last. You can defeat the wall.
Relentless Focus & Boring Consistency. Running is all about spending hours and hours doing the same thing - running. You need to have laser-sharp focus and be consistent. There is no way around.
In your company there is nothing more important than making the main thing the main thing and then executing on it. It’s not flashy & glamorous - but it is how you will get to your goal. I ignored this piece of advice in my first company. I kept chasing the next new thing. And failed.Again
- Train Hard
- Make Sacrifices
- Make Positive Choices
- Seek Your Potential
- Set High Goals
- Relax Under Pressure
- Attack Pain
- Push The Pace
- Work As A Team
- Run To Win
- Defeat The Wall
- Relentless Focus & Boring Consistency
“The man who can drive himself further once the effort gets painful is the man who will win.” — Roger Bannister
The first rule is actually the first and second rule of everything you do.
If you don’t have a big, fat grin on your face when you run, don’t do it. Have fun while you’re out there. It is your race.Remember
“Nach dem Spiel ist vor dem Spiel. – After the game is before the game.” — Sepp Herberger
“The only good race pace is suicide pace, and today looks like a good day to die.” — Steve Prefontaine
On Friday we rolled out a big change to split up our browser-chrome tests. It started out as a great idea to split the devtools out into their own suite, then after testing, we ended up chunking the remaining browser chrome tests into 3 chunks.
No more 200 minute wait times, in fact we probably are running too many chunks. A lot of heavy lifting took place, a lot of it in releng from Armen and Ben, and much work from Gavin and RyanVM who pushed hard and proposed great ideas to see this through.
What is next?
There are a few more test cases to fix and to get all these changes on Aurora. We have more work we want to do (lower priority) on running the tests differently to help isolate issues where one test affects another test.
In the next few weeks I want to put together a list of projects and bugs that we can work on to make our tests more useful and reliable. Stay tuned!
Mozilla ontwikkelt veilige testmethode voor Heartbleed-bug
Mozilla heeft een testmethode voor de Heartbleed-bug in OpenSSL ontwikkeld waarmee ontwikkelaars servers op een veilige manier kunnen testen. Via de Heartbleed-bug is het mogelijk om het geheugen van servers uit te lezen en zo gevoelige gegevens ...
en meer »
Mozilla's CMO Moonlights As An iPhone Model
While Mozilla is recovering from the resignation of its co-founder and CEO Brendan Eich after the controversy over his support of Proposition 8, here is a bizarre twist to the PR knife: Mozilla's CMO Pete Scanlon appears in photographs on Apple's ...
I know that strictly speaking I'm posting this to Planet Mozilla, and it's about Chrome/Chromium, but someone here will be able to point me in the right direction.
I'm having odd trouble with Chrome establishing an SSL connection to my webserver. Not only does it not connect, it cuts off any communication to the server for 5 minutes.
Steps to reproduce:
- Ping darktrojan.net. It resolves to 188.8.131.52 and responds as you'd expect.
- Visit https://www.darktrojan.net/ in Chrome. It gives a cert error in Firefox, but in Chrome will fail to connect.
- Ping darktrojan.net again. No response.
This issue has appeared in the last few days - right when I need it to be working most - which suggests it's a (recently released) Chrome 34 problem, except that I can reproduce it in Chromium 33. I don't use either on a regular basis so I don't know if that has anything to do with anything. I also wonder if it's something to do with Heartbleed but my webhost have said the site was never vulnerable so I assume nothing's changed there.
Mozilla ontwikkelt veilige testmethode voor Heartbleed-bug
Mozilla heeft een testmethode voor de Heartbleed-bug in OpenSSL ontwikkeld waarmee ontwikkelaars servers op een veilige manier kunnen testen. Via de Heartbleed-bug is het mogelijk om het geheugen van servers uit te lezen en zo gevoelige gegevens ...
en meer »
3 things we know from Mozilla CEO's ouster
3 things we know from Mozilla CEO's ouster. Phil Boas: Gay activists who drove Mozilla CEO Brendan Eich from his job revealed things about themselves. Loading… Post to Facebook. 3 things we know from Mozilla CEO's ouster on azcentral.com: ...
Stop Crying over Mozilla and Start Fighting Back!American Thinker
Mozilla CEO had the right to be wrongDaytona Beach News-Journal
Did Mozilla CEO Brendan Eich Deserve To Be Removed From His Position?Forbes
Tech Times -NewsBusters (blog) -Huffington Post
alle 57 nieuwsartikelen »
Mozilla CEO should not be fired for opposing gay marriage: PennLive letters
I am writing to express my consternation at the recent firing of Mozilla's CEO because he gave a donation of $1,000 to an organization that wants marriage to be between a man and a woman in the year of 2008. President Obama had the same stand in the ...
Last week I was in Denver for a three day conference put on by User Interface Engineering. I met lots of great people, and the workshops and talks were fantastic. Would highly recommend to anyone looking for a good UX conference to attend.
- Future Friendly
- http://www.webpagetest.org – test the perf of your websites
- http://www.modernizr.com – tweak sites based on browser capability
- http://icoMoon.io – roll your own icon fonts
- http://patternlab.io – could be a useful tool for our visual unification efforts
- Break down design elements into reusable components of a system:
More details on Atomic Design here: http://bradfrostweb.com/blog/post/atomic-web-design/
- Style comparisons – Pinterest is a great tool for this simple direction setting tactic
- Style tiles
- Style prototype
Use tools you are comfortable with to establish the aesthetic
Part 2: Solve the Problem
- Static design tools (photoshop, etc)
- Responsive design tools
You best solve problems using tools you are fluent with
Part 3: Refine the Solution
- Static tools
- Instead of static design hand-offs, consider design pairing: one engineer, one designer, working together side by side.
Efficiency is key with refining a design solution
The fact is, there is no one way to design for screens. Every project is different. Every team is different. It’s interesting to look at it as a form of group improvisation, where everyone is contributing in the way that makes this particular project work.“Group improvisation is a challenge. Aside from the weighty technical problem of collective coherent thinking, there is the very human, even social need for sympathy from all members to bend for the common result.”
Group Improvisation requires individuals on a team to be…
Ben’s Theory on Web Process
Create guidelines instead of rigid processes. “The amount of process required is inversely proportional to the skill, humility, and empathy of your team.”
More details on Dissecting Design here: http://seesparkbox.com/foundry/dissecting_design
Mobile shopping in US
- 2011: 14%
- 2012: 30%
- 2013: 50%
Paypal mobile payments
- 2010: $750M
- 2011: $4B
- 2012: $14B
- 2013: $27B
- Yelp: 40%
- Facebook: 53%
- Twitter: 75%
- Test showed that a button that reads “MENU” was selected 20% more than when a hamburger menu was used
- Interesting Polar Mobile case study, where hiding content under a menu vs using a segmented control showed an instant and major drop off in usage as soon as they changed it
- Measure measure measure
- Airport wifi login – 23 steps on mobile to pay money to get online
- Designers talked to Luke about how they cut it down to 19.
- Luke’s response – I have an idea that uses *4* inputs.
- Hotel Tonight — Using a signature gesture to solve the baby booking the hotel room problem. So good.
- Booking a hotel happens in 3 taps and a swipe, giving them a competitive advantage
- Release – As quick as you can
- Refine – by observing real use
- Repeat – design is never done
They were watching the user logs, and when they saw bugs they fixed them before users complained, and then reached out to let them know they had fixed something. User feedback was 100% positive. Brilliant.
Designing DesignersJob interview test
- Present candidate with a messy sketch of a web form
- A good designer cleans it up
- A better designer simplifies
- An even better ask why do we need this info
Side comment about unintentional design: What happens when you spend time working with everything in the system *except* the user’s experienceThe need for design talent is growing, massively. How do we staff it?
IBM is investing 100M to expand design business. 1000+ UX designers are going to IBM. This means all the big corporations are going to start hiring UX like crazy. How do we as the design community even staff that? Especially since today, all design unicorns are self taught.How to become a design unicorn <3
- Train yourself
- Practice your skills
- Deconstruct as many designs as you can
- Seek out feedback (and listen to it)
- Teach others
It doesn’t happen like this in school, though.
- Schools have too many constraints
- Out of date (3yr accreditation process)
- There aren’t enough schools to keep up with the new jobs in demand
- Schools don’t go deep enough
- The semester / class based school system can’t support the kind of learning designers need to do to develop their skills
Tying the education problem back to Unintentional Design. We focused so much on the system that we forgot what we were actually trying to do.Changes to education system?
What if design school were more like Medical Education (combines theory and craft). This idea of pre-med, medical school, internships, residences, and finally fellowships.Changes to our workplace?
- We are the future managers of this next wave. What can we do?
- Building a culture of learning
- Integrating *practice* into our routines (critiques, sketching, what else?)
- Apply our design skills to design learning
JQuery Mobile Prototyping Workshop“If a picture is worth a thousand words, how many meetings is a prototype worth?”
- Workshop page
- jQuery Mobile Main Page
- jQuery Mobile Docs and Demos
- ThemeRoller – jQuery Mobile
- jQuery Mobile Resources
- jQuery Mobile API Docu
- jQuery main page
- jQuery Learning Center
- jQuery API Page
Mozilla firing lesson: We're far too intolerant
In 2008, when President Barack Obama and Mozilla executive Brendan Eich expressed opposition to gay marriage, national polls emphatically underscored their shared view. According to the Pew Research Center, just 39 percent of Americans supported a ...
American Thinker (blog)
Caution Warranted on a Mozilla Boycott
American Thinker (blog)
After the recent resignation of former Mozilla CEO Brendan Eich, many high-profile conservative commentators (such as Charles Krauthammer and Dennis Prager) have called for a boycott of Mozilla products, especially the Firefox browser. Twitter also has ...
en meer »Google Nieuws
Why Condoleezza Rice joining Dropbox board isn't a Mozilla moment
The Wall Street Journal says Dropbox has run afoul of Silicon Valley orthodoxy and references Mozilla, where the firm's chief executive resigned over a donation to an anti-gay marriage proposition. In a column, I argued that Brendan Eich, the chief ...
Dropbox, Condoleezza Rice controversy: More proof liberals are the new ...Fox News
Dropbox Unswayed By Anti-Condi #DropDropbox CampaignForbes
Dropbox defends appointing Condoleezza Rice to boardZDNet
alle 140 nieuwsartikelen »Google Nieuws
What does the fox (Firefox OS) say in Chile?
Since its beginning I liked Persona (also known as BrowserID), because it:
- technically supports a more decentralised Internet
- makes authentication easier for users
Shame on me, only just a few weeks ago I found time to play with this. As a proof of concept, I prepared an Express application that connects to MySQL so I could have a better understanding about how this authentication system actually works in practice (from a developer point of view).
You can find the code here: Express Persona MySQL Example.
The application is essentially based on Express Persona authentication module, but it separates the client part from the server side and adds a MySQL layer. So, instead of NodeJS Express for the server side, we could also use any other language, let's say Perl Mojolicious, but at the same time continuing to use the same code for the client webapp.
An example MySQL dump and an Apache virtual host configuration is provided as well (the latter for proxying requests from the client to the server and for ensuring 'same origin policy' is respected). We must not forget that Persona takes care only about authentication, so account creation must be handled apart.
One thing that can help when designing an application/service is knowing that custom Persona URLs can also be used. For instance, in the client code: /login/persona/verify is forwarded to http://localhost:4646/persona/verify (via Apache proxy) and this latter URL can also be further customised thanks to the Express-persona module (verifyPath optional parameter).
On the other hand, as a reference, the magic at the client side is done by navigator.id.watch.
In the slides below Alina details a bit more (in Spanish) about Persona and how to deploy the code I comment:
My friend and colleague Jannis (aka jezdez) Leidel saved my bacon today where I had gotten completely stuck.
So, I have this python2.6 virtualenv and whenever I ran python setup.py sdist upload it would upload a really nasty tarball to PyPI. What would happen is that when people do pip install premailer it would file horribly and look something like this:... IOError: [Errno 2] No such file or directory: '/path/to/virtual-env/build/premailer/setup.py'
What?!?! If you download the tarball and unpack it you'll see that there definitely is a setup.py file in there.
Anyway. What happens, which I didn't realize was that within the .tar.gz file there were these strange copies of files. For example for every file.py there was a ._file.py etc.
Here's what the file looked like after a tarball had been created:(premailer26)peterbe@mpb:~/dev/PYTHON/premailer (master)$ tar -zvtf dist/premailer-2.0.2.tar.gz -rwxr-xr-x 0 peterbe staff 311 Apr 11 15:51 ./._premailer-2.0.2 drwxr-xr-x 0 peterbe staff 0 Apr 11 15:51 premailer-2.0.2/ -rw-r--r-- 0 peterbe staff 280 Mar 28 10:13 premailer-2.0.2/._LICENSE -rw-r--r-- 0 peterbe staff 1517 Mar 28 10:13 premailer-2.0.2/LICENSE -rw-r--r-- 0 peterbe staff 280 Apr 9 21:10 premailer-2.0.2/._MANIFEST.in -rw-r--r-- 0 peterbe staff 34 Apr 9 21:10 premailer-2.0.2/MANIFEST.in -rw-r--r-- 0 peterbe staff 280 Apr 11 15:51 premailer-2.0.2/._PKG-INFO -rw-r--r-- 0 peterbe staff 7226 Apr 11 15:51 premailer-2.0.2/PKG-INFO -rwxr-xr-x 0 peterbe staff 311 Apr 11 15:51 premailer-2.0.2/._premailer drwxr-xr-x 0 peterbe staff 0 Apr 11 15:51 premailer-2.0.2/premailer/ -rwxr-xr-x 0 peterbe staff 311 Apr 11 15:51 premailer-2.0.2/._premailer.egg-info drwxr-xr-x 0 peterbe staff 0 Apr 11 15:51 premailer-2.0.2/premailer.egg-info/ -rw-r--r-- 0 peterbe staff 280 Mar 28 10:13 premailer-2.0.2/._README.md -rw-r--r-- 0 peterbe staff 5185 Mar 28 10:13 premailer-2.0.2/README.md -rw-r--r-- 0 peterbe staff 280 Apr 11 15:51 premailer-2.0.2/._setup.cfg -rw-r--r-- 0 peterbe staff 59 Apr 11 15:51 premailer-2.0.2/setup.cfg -rw-r--r-- 0 peterbe staff 280 Apr 9 21:09 premailer-2.0.2/._setup.py -rw-r--r-- 0 peterbe staff 2079 Apr 9 21:09 premailer-2.0.2/setup.py -rw-r--r-- 0 peterbe staff 280 Apr 11 15:51 premailer-2.0.2/premailer.egg-info/._dependency_links.txt -rw-r--r-- 0 peterbe staff 1 Apr 11 15:51 premailer-2.0.2/premailer.egg-info/dependency_links.txt -rw-r--r-- 0 peterbe staff 280 Apr 9 21:04 premailer-2.0.2/premailer.egg-info/._not-zip-safe -rw-r--r-- 0 peterbe staff 1 Apr 9 21:04 premailer-2.0.2/premailer.egg-info/not-zip-safe -rw-r--r-- 0 peterbe staff 280 Apr 11 15:51 premailer-2.0.2/premailer.egg-info/._PKG-INFO -rw-r--r-- 0 peterbe staff 7226 Apr 11 15:51 premailer-2.0.2/premailer.egg-info/PKG-INFO -rw-r--r-- 0 peterbe staff 280 Apr 11 15:51 premailer-2.0.2/premailer.egg-info/._requires.txt -rw-r--r-- 0 peterbe staff 23 Apr 11 15:51 premailer-2.0.2/premailer.egg-info/requires.txt -rw-r--r-- 0 peterbe staff 280 Apr 11 15:51 premailer-2.0.2/premailer.egg-info/._SOURCES.txt -rw-r--r-- 0 peterbe staff 329 Apr 11 15:51 premailer-2.0.2/premailer.egg-info/SOURCES.txt -rw-r--r-- 0 peterbe staff 280 Apr 11 15:51 premailer-2.0.2/premailer.egg-info/._top_level.txt -rw-r--r-- 0 peterbe staff 10 Apr 11 15:51 premailer-2.0.2/premailer.egg-info/top_level.txt -rw-r--r-- 0 peterbe staff 280 Apr 9 21:21 premailer-2.0.2/premailer/.___init__.py -rw-r--r-- 0 peterbe staff 66 Apr 9 21:21 premailer-2.0.2/premailer/__init__.py -rw-r--r-- 0 peterbe staff 280 Apr 9 09:23 premailer-2.0.2/premailer/.___main__.py -rw-r--r-- 0 peterbe staff 3315 Apr 9 09:23 premailer-2.0.2/premailer/__main__.py -rw-r--r-- 0 peterbe staff 280 Apr 8 16:22 premailer-2.0.2/premailer/._premailer.py -rw-r--r-- 0 peterbe staff 15368 Apr 8 16:22 premailer-2.0.2/premailer/premailer.py -rw-r--r-- 0 peterbe staff 280 Apr 8 16:22 premailer-2.0.2/premailer/._test_premailer.py -rw-r--r-- 0 peterbe staff 37184 Apr 8 16:22 premailer-2.0.2/premailer/test_premailer.py
Strangly, this only happened in a Python 2.6 environment. The problem went away when I created a brand new Python 2.7 enviroment with the latest setuptools.
So basically, the fault lies with OSX and a strange interaction between OSX and tar.
This superuser.com answer does a much better job explaining this "flaw".
So, the solution to the problem is to create the distribution like this instead:$ COPYFILE_DISABLE=true python setup.py sdist
If you do that, you get a healthy lookin tarball that actually works to pip install. Thanks jezdez for pointing that out!
I’m writing today to present the bug statistics for Firefox 27. My apologies for the tardiness of this blog post; too many things have got in my way recently. I try to get these posts out at the end of life of the respective Firefox version as that allows me to present the statistics across the entire life-cycle of a Firefox version. For Firefox 27, this should have coincided with Firefox 28′s release a few weeks ago. Again, my apologies for getting this out later than usual.
The first story I want to tell is about the high-level breakdown of all tracked bug in this release. As you can see below there was a marked drop in the total bug volume in Firefox 27. Perhaps unsurprisingly this allowed us to focus a bit more which resulted in a smaller amount of unresolved and unconfirmed bugs being shipped in this release. The numbers are still much higher than we would like but it is a small victory for the overall quality of Firefox if these numbers continue to trend downward.
The second story I want to tell is about the percentage of incoming bugs confirmed. This is typically an indication of the effectiveness of our incoming bug triage practices. As the volume of incoming bugs decreases we like to see the number of confirmed bugs increase. Unfortunately we have been trending the opposite direction for some time. Previously I had attributed this to the ever increasing volume of bugs but I can no longer rely on this excuse. Looking forward to Firefox 28 I can say that we’ve made remarkable improvement in this area in an effort to reverse this trend. I’ll share more on that in a few weeks.
The third story I’d like to share is that of when fixes landed for Firefox 27. The following chart I’ve plotted the average time-line for the past few releases along with Firefox 27′s time-line. In general we expect to see an ever increasing curve toward through the Nightly cycle, trailing off as we proceed through Aurora and Beta, with spikes in the first half of these cycles.
Firefox 27 appeared to be trending higher than average as we approached the end of each cycle. While these numbers are not completely out of control it does put a bit of extra strain on QA. After all, the later a fix lands, the less time we have to test it. Ultimately this creates risk to the quality of the product we ship, but as long as we recognize that we can try to plan for it accordingly.
The fourth story I want to tell is about the number of bugs reopened. We typically reopen a bug when something is fundamentally flawed with the initial implementation and/or if a patch needs to be backed out. Even in cases where a regression is found, we tend to leave the bug closed and deal with the regression in its own bug report. As such, a high volume of bugs being reopened is usually indicative of a release that saw much churn and may point to quality issues in release.
Unfortunately Firefox 27 continues the story of many of the version before it and represents a marginal increase in the number of bugs reopened. Of course, the other side of this story may be that testing was more effective. It’s hard to say concretely just looking at the bug numbers.
The fifth story I want to tell is one of stability. The following chart shows the number of topcrash bugs reported against Firefox 27 as compared to previous releases. For those unaware, a topcrash bug are those crashes which show up most frequently in the wild and present the greatest risk to quality and security for our users. The unfortunate story for Firefox 27 is that we’ve seen an end to the downward trend that we saw started with Firefox 25 and continued with Firefox 26. The volume of topcrashes puts Firefox 27 in the same ballpark as the rash of point-releases we saw in Firefox’s teens.
Of course there’s two sides to every story. The other side of this may very well be that we got better at reporting stability issues and that resulted in a higher volume of known bugs. It’s hard to say for sure.
The final story I want to tell today is about the percentage of regressions reported post-release. As we hone our processes, bring on more engineers, and get assistance from more contributors, we’ve been getting better at finding and fixing regressions. It’s inevitable that the more code landing in a release increases the potential for regression. Naturally this leads to an increase in the total number of regressions reported. Firefox 27 was no different so I thought I’d look at regressions a little differently this time around.
The following chart shows the ratio of regressions reported before release to regressions reported after release. A release with a high-volume of post-release regressions is a failure from a QA perspective because it means many bugs slipping through our fingers. I wouldn’t expect the number of post-release regressions to ever be 0 but we need to strive to always be better.
Firefox 27 represents a huge victory on this front. We saw a huge drop in the number of Firefox 27 regressions reported post-release. For months we’ve sought to improve our triage processes, engage more with developers, and work harder to involve volunteers in our day to day efforts. It’s nice to see these efforts finally paying off.
That’s Firefox 27, in a nutshell, from a QA perspective. I think it’s useful to be able to reflect on the bug numbers and see what kind of an impact our efforts are having on the product. I really do enjoy visualizing the data and talking about our “victories”, but it’s just as interesting seeing what the data is telling us about where we may have failed. I believe that learning from failures has far more impact than building on successes and acts as a great motivator. What we want to avoid is those crippling failures. I think Firefox 27 is a nice iterative step forward.
A while ago I blogged about the troubles of hosting a pre-built distribution of vtt.js for Bower. The issue was that there is a build step we have to do to get a distributable file that Bower can use. So we couldn't just point Bower at our repo and be done with it as we weren't currently checking in the builds. I decided on hosting these builds in a separate repo instead of checking the builds into the main repo. However, this got troublesome after a while (as you might be able to imagine) since I was building and commiting the Bower updates manually instead of making a script like I should have. It might be a good thing that I didn't end up automating it with a script since we decided to switch to hosting the builds in the same repo as the source code.
The way I ended up solving this was to build a grunt task that utilizes a number of other tasks to build and commit the files while bumping our library version. This way we're not checking in new dist files with every little change to the code. Dist files which won't even be available through Bower or node because they're not attached to a particular version. We only need to build and check in the dist files when we're ready to make a new release.
I've also separated out builds into dev builds and dist builds. This way in the normal course of development we don't build dist files which are tracked by git and have to worry about not commiting those changes. Which would be the case because our test suite needs to build the library in order to test it.grunt.registerTask( "build", [ "uglify:dist", "concat:dist" ] ); grunt.registerTask( "dev-build", [ "uglify:dev", "concat:dev" ]) grunt.registerTask( "default", [ "jshint", "dev-build" ]);
Then when we're ready to make a new release with a new dist we would just run.grunt release:patch // Or major or minor if we want too.
We’re shipping a new “explore” page for Webmaker. The goal: help users get their feet wet, quickly grokking what they can do on Webmaker.org. Plus: make it easy to browse through the list of skills in the Web Literacy Standard, finding resources and teaching kits for each.
It’s like an interactive text book for teaching web literacy.
The main writing challenge: what should the top panel say? The main headline and two blurbs that follow.
In my mind, this section should try do three things:
- State what this is. And why you care.
- Tell a story about the list of skills at left. When you hit this page, you see a list of rainbow-coloured words that can be confusing or random if you’re here for the first time. “Sharing. Collaborating. Community Participation…. Hmmm…. what does that all actually mean?”
- Focus on what users can do here. What does exploring those things do for you? What’s the action or value?
Here a start:Teach the web with Webmaker
Explore creative ways to teach
through fun making and sharing, backed by the
global Mozilla community’s Web Literacy Standard.
Each skill has free resources and teaching kits anyone can use to teach others –
to help create a more web literate world.
- Armen and Bill McCloskey got an initial set of tests running with e10s enabled, which is a big step towards stabilizing it.
- Hal helped run the shortest tree closure window to date (less than 2 hours!).
- Massimo switched over some of our EC2 machines to SSD instance storage, which has improved Linux build times on try.
- Aki attended the first TRIBE session.
- Armen talked about some of our cost cutting measure in an air.mozilla.org presentation.
Completed work (resolution is ‘FIXED’):
- Balrog: Backend
- Please add t-mavericks-r5-002 and t-mavericks-r5-003 to graphserver
- Reconfig bustage – temporary fix for “exceptions.KeyError: ‘tst-linux64-ec2-300′”
- Reimage remaining win64-rev1 machines as win64-rev2
- Testpool connection issues
- General Automation
- Provide native js shell to tarako b2g builds
- Cloning of hg.mozilla.org/build/tools and hg.mozilla.org/integration/gaia-central often times out, as does downloading/unzipping test zips
- add missing pandas/tegras to buildbot configs
- b2g build improvements
- generate “FxOS Simulator” builds for B2G
- Run additional hidden 3 debug mochitest-browser-chrome chunks and b2g reftests
- prioritize l10n nightlies below everything, regardless of branch
- Enable all mozharness desktop build linux variants on Cedar
- Run desktop C++ unit tests from test package
- Increase maxtime for browser-chrome-2. Again.
- Perma-fail on Linux64 slaves – test_hosted.xul,test_packaged.xul,test_packaged_launch.xul | Error during test: [Exception... "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIFileOutputStream.init]” nsresult: “0×80520012
- Increase maxtime for browser-chrome-1
- Get e10s tests running on inbound, central, and try
- [tarako][build]create “tarako” build
- post_upload.py should use hardlinks where possible
- disable confusing double runs of mochitest-bc for linux debug
- Enable updates for tarako on 1.3t branch
- Run jit-tests from test package
- Kill spot vs on-demand retry logic
- logrotate aws_watch_pending.py
- Loan Requests
- please loan jmaher an ec2 machine equal to a linux32-spot instance
- Need a win32 unittest slave for debugging packaged tests
- Loan an ami-3ac4aa0a instance to Tim Abraldes
- Need a win32 slave to debug Lightning pymake issues
- please loan jmaher an ec2 machine equal to a linux32-spot instance
- Please loan dminor t-xp32-ix- instance
- Use mozmake for some windows builds
- stage NFS volume about to run out of space
- Add dev-master1:8951 master to slavealloc
- Platform Support
- Release Automation
- Minor documentation improvements on the ship-it form
- Add documentation about the beta release of Fennec
- Strip the firefox locale string
- deploy ship it patches from a few bugs
- Documentation about release-kickoff
- release repacks needs to submit data to balrog
- Releases: Custom Builds
- Repos and Hooks
In progress work (unresolved and not assigned to nobody):
- Balrog: Backend
- Balrog: Frontend
- General Automation
- Port TryBuildFactory to Mozharness for fx desktop builds
- Add ssltunnel to xre.zip bundle used for b2g tests
- Disable mochitest-metro on Cedar
- m-c b2g version should be 2.0, not 1.5
- Add configs for debug B2G Mac OS X desktop builds & enable on mozilla-central and mozilla-aurora
- Bengali in 1.3t builds
- fx desktop builds in mozharness
- Spot instances don’t have security group set properly
- Add the build step or else process name to buildbot’s generic command timed out failure strings
- Need Tarako 1.3t FOTA updates for testing purposes
- Don’t do Thunderbird builds on comm-* branches for non-Thunderbird pushes
- [Flame]figure out how to create “Flame” builds manually
- Move Android 2.3 reftests to ix slaves (ash only)
- Turn off Fedora b2g reftests on trunk branches
- Please add non-unified builds to mozilla-central
- point [xxx] repository at new bm-remote webserver cluster to ensure parity in talos numbers
- remove machines that don’t exist from buildbot-configs
- Make it possible to run gaia try jobs *without* doing a build
- Updates not properly signed on the nightly-ux branch: Certificate did not match issuer or name.
- Decommission the ionmonkey tree
- Configure the MLS key for pvt builds
- Split up mochitest-bc on desktop into ~30minute chunks
- Loan Requests
- Slave loan request for a VS2013 build machine
- Loan an ami-6a395a5a instance to Aaron Klotz
- Please loan tst-linux64- instance to dminor
- borrow a linux ix multinode host to test CentOS-6.5
- Need a bld-lion-r5 to test build times with SSD
- Request Loan Machine for tst-linux64-spot
- Figure where to put sccache config for ceph
- Deprecate tinderbox-builds/old directories for desktop & mobile
- Platform Support
- Release Automation
- Releases: Custom Builds
- Repos and Hooks
- find RFO for git.m.o OOM condition in bug 985864
- Request for a new git repository: “fuzz-tools” (public)
- Update SlaveAPI sphynx docs to reflect recent changes
- New tooltool deployment
- Set up auto publish of doc index per Boston workweek agreement
- Using slaveapi to reboot a machine on the slave health page results in “list index out of range” under ‘output’
- tool to compare different sources of slave and master data
- slaveapi’s shutdown_buildslave action doesn’t cope well with a machine that isn’t connected to buildbot
- Add Windows support to aws_stop_idle.py
- db-based mapper on web cluster
- Create a Comprehensive Slave Loan tool
- SlaveAPI should be more precise on request TS
- vcs-sync needs to populate mapper db once it’s live