Seif Lotfy: Globaleaks 0.2 Alpha
Globaleaks 0.2 Alpha is out.
Globaleaks is an open source project aimed at creating a worldwide, anonymous, censorship-resistant, distributed whistle-blowing platform. It enables organizations interested in running whistle-blowing initiatives to setup their own safe zone, where whistle-blowers and recipients can exchange data.
2 Years ago I helped out with the development of Globaleaks 0.1. And although I am not active anymore, I really support the initiative behind it. Now with the HERMES Center for Transparency and Digital Human Rights backing it up, it has grown a lot and shaped up to be a very organized and thought through project.
TL;DR:
- Full rewrite
- More flexible and extensible
- Linux ready-made system and network hardened installation
- Written in python using twisted
- New Frontend
Try it out:
Try out the demo. It is pretty straight forward.
Help out:
As young project, Globaleaks can use some help fixing bugs. Just head to the wiki and read through it. It is pretty straight forward, and explains the modules, security concepts and set up instructions.
Globaleaks already has Debian and Ubuntu ready packages. An easy way to help out is to set up a PPA for us on Launchpad.
Get in touch:
You can contact the Globaleaks team at info () globaleaks org or on IRC on #globaleaks at irc.oftc.net
Here are some screenshots of the new frontend
Congratulations you are using Tor
Receiver selection page
The submission receipt
Configuring a receiver
Configuring a context
Mozilla Prolongs Default Cookie Blocker In Firefox 22 - Pulse2 - Pulse 2.0
Mozilla Prolongs Default Cookie Blocker In Firefox 22 - Pulse2
Pulse 2.0
Mozilla recently launched Firefox 22 in beta mode. One of the most controversial features that was supposed to be built into the browser was a default third-party cookie blocking software. This feature was aimed at preventing cross-website tracking of ...
Amir Aharoni: Always define the language and the direction of your HTML documents, part 02: Backwards English
In part 01 of these series, I showed why is it important to always define the language and the direction of all HTML content and not rely on the defaults: The content may get embedded in a document with different direction and be displayed incorrectly.
This issue is laughably easy to avoid: If you are writing the content, you are supposed to know in what language it is written, so if it’s English, just write <html lang=”en” dir=”ltr”> even though these seem to be the defaults. Nineteen or so characters that ensure your content is readable and not displayed backwards. Please do it always and tell all your friends to do it.
The problem is that you don’t only have to explicitly set the language and the direction, but, as silly as it sounds, you have to set them correctly, too. A more subtle, but nevertheless quite frequent and disruptive bug is displaying presumably, but not actually, translated content in a different direction. This happens quite frequently when a website supports the browser language detection feature, known as Accept-Language:
- The web server sees that the browser requests content in Hebrew.
- The web server sends a response with <html lang=”he” dir=”rtl”>, but because the website is not actually translated, the text is shown in the fallback language, which is usually English.
- The user sees the content just like this numbered list, which I intentionally set to dir=”rtl”: with the numbers and the punctuation on the wrong side, and possibly invisible, because English is not a right-to-left language.
Of course, it can go even worse. Arrows can point the wrong way and buttons and images can overlap and hide each other, rendering the page not just hard to read, but totally unusable.
This bug is also an example of the Software Localization Paradox: It manifests itself when Accept-Language is not English, but most developers install English operating systems and don’t bother to change the preferred language settings in the browser, so they never see how this bug manifests itself. The site developers don’t bother to test for it either.
The solution, of course, is to set a different language and direction only if the site is actually translated, and not to pretend that it is if it’s not translated.
Here are two examples of such brokenness. Both sites are important and useful, but hard to use for people whose Accept-Language is Hebrew, Persian or Arabic.
Here’s how the Mozilla Developer Network website looks in fake Hebrew:
Mozilla Developer Network website, in English, but right-to-left
Notice how the full stops are on the left end and how the text overlaps the images in the tiles on the right-hand side. This is how it is supposed to look, more or less:
Mozilla Developer Network home page in English, left-to-right
I manually changed dir=”rtl” to dir=”ltr” using the element inspector from Firefox’s developer tools and I also had to tweak a CSS class to move the “mozilla” tab at the top.
The above troubles are reported as bug 816443 – lang and dir attributes must be used only if the page is actually translated.
After showing an example of a web development bug from a site for, ahem, web developers, here is an even funnier example: The home page Unicode’s CLDR. That’s right: Unicode’s own website shows text with incorrect direction:
The Unicode CLDR website, in English but right-to-left
The only words translated here are “Contents” (????) and “Search this site” (????? ???? ??), which is not so useful. The rest is shown in English, and the direction is broken: Notice the strange alignment of the content and the schedule table. A few months ago that table was so broken that its content wasn’t visible at all, but that was probably patched.
Here’s how it is supposed to look:
The CLDR home page in English, appropriately left-to-right
I tried reporting the CLDR home page direction bug, but it was closed as “out-of-scope”: The CLDR developers say that the Google Sites infrastructure is to blame. This is frustrating, because as far as I know Google Sites doesn’t have a proper bug reporting system and all I can do is write a question about that direction problem in the Google Sites forum and hope that somebody notices it or poke my Googler friends.
One thing that I will not do is switch my Accept-Language to English. Whenever I can, I don’t just want to see the website correctly, but to try to help my neighbor: see the possible problems that can affect other users who use different language. Somebody has to break the Software Localization Paradox.
Filed under: Firefox, Free Software, localization
Will Kahn-Greene: Proposal: LDAP password resets as a unit of measure
Every 3 months, we at Mozilla have to reset our LDAP passwords. The system helpfully sends the first reminder 2 weeks before your password expires, then the second reminder 1 week before your password expires and the last reminder 2 days before your password expires.
Sometimes time passes by faster than you know and you end up with a Locked out of LDAP account.
The 3 month LDAP password reset is such a large part of our lives that I propose it become a standard unit of measure for elapsed time.
UsageUsed in casual conversation:
Pat: Hi!
Jordan: Hi!
Pat: I haven't seen you before. How long have you been at Mozilla?
Jordan: I've been here for 6 LDAP password resets.
Pat: Oh, weird. I've been here for 7. Good to meet you! Would you like a banana?
Jordan: Would I ever!
Used in casual conversation on IRC:
<patbot> anyone use less? <corycory> i only use sass. it's the best. * riledupriley has quit (Quit: riledupriley) <patbot> :( <hugbot> (patbot) * r1cky has joined #casualconversationexample <r1cky> morning! <nigelb> r1cky: hai! <nigelb> Ah, it's nearly mfbt. <mtjordan> sure. been using it for 3 ldap password resets. <mtjordan> patbot: why do you ask?Used in Bugzilla comments:
Jordan [:jordan] 1 day ago Comment 0 [reply] [-] Readonly mode causes the site to ISE. Pat [:pat] 1 day ago Comment 1 [reply] [-] I looked into it. Turns out we haven't used readonly mode in at least 4 LDAP password resets. I think we just need to add a fake authentication module. Easy peasy.Used when joining a new group:
From: Pat To: some-group@mozilla.org Subject: Welcome Jordan to some-group! Hi all! I'd like to welcome Jordan to some-group! Jordan brings expertise that is invaluable. I'm excited! Yay! Jordan: Tell us about yourself! Pat From: Jordan To: some-group@mozilla.org Subject: Re: Welcome Jordan to some-group! Hi! I'm excited to join some-group! Hopefully I bring something useful to the table. I've been at Mozilla for 7 LDAP password resets, I like top-posting and I make a mean cold brew coffee. Looking forward to my first meeting! Jordan On Blah blah blah at blah blah blah, Pat wrote: > Hi all! > > I'd like to welcome Jordan to some-group! Jordan brings > expertise that is invaluable. I'm excited! Yay! > > Jordan: Tell us about yourself! > > PatUsed in an email to everyone@ about departing:
Dear everyone! It is with sadness that I tell you I'm leaving as of next Friday. As you know, I've been with Mozilla for 32 LDAP password resets and frankly, I'm totally out of usable Sherlock Holmes story titles, so I'm off to new challenges. I will miss you all.[Comments]
Tantek Çelik: #UX: "Learn more" Links in Warning Boxes Should Go To A Page With These Three Things
Sometimes web pages display brief warning boxes at the top with "learn more" links. The learn more link in a specific warning box should go to a page specifically about that warning with, in rough order:
- screenshot of warning box
- quoted full text of the warning (for searchability / search engine discovery)
- detailed text answering:
- how could have the issue occurred?
- what should the user do to resolve the issue?
- how can the user avoid the issue in the future?
E.g. the "Learn more ›" link in the yellow warning box in this screenshot:
links to: https://support.twitter.com/articles/82050-i-m-having-trouble-confirming-my-email which:
- Neither has screenshot nor text of warning
- Covers several topics unrelated to the warning
- Does not answer the above questions
And could be improved by linking to a specific page about this particular warning, containing the above points 1-3, and answering all three questions in point 3.
Related: Scary Twitter warning: "... removed the email address from your account...
Mozilla delays blocking advertisers' cookies in Firefox - The Verge
ExtremeTech
Mozilla delays blocking advertisers' cookies in Firefox
The Verge
After announcing that it would soon start blocking cookies from third-party advertisers by default in Firefox, Mozilla has walked back on its plans while it continues to test the system. In a blog post, Mozilla's Brendan Eich said that the patch needed ...
Mozilla drags its feet on blocking third-party tracking cookiesExtremeTech
Mozilla Firefox delays patch to block third-party cookiesWashington Post
Mozilla Delays Firefox 22 Cookie Blocker, Says More Work Is NeededThe Next Web
InfoWorld -PC Magazine -Ars Technica
alle 32 nieuwsartikelen »
Mozilla drags its feet on blocking third-party tracking cookies - ExtremeTech
ExtremeTech
Mozilla drags its feet on blocking third-party tracking cookies
ExtremeTech
Mozilla has been courting controversy with its move toward blocking some third-party cookies by default in Firefox. While preventing unvisited websites from setting cookies (i.e. tracking cookies) is good for most consumers, advertisers are none too ...
Mozilla Firefox delays patch to block third-party cookiesWashington Post
Mozilla delays blocking advertisers' cookies in FirefoxThe Verge
Mozilla Delays Firefox 22 Cookie Blocker, Says More Work Is NeededThe Next Web
InfoWorld -Ars Technica -PC Magazine
alle 31 nieuwsartikelen »
Mozilla L10n Blog: Teach yourself L20n at L20n.org
Language can be very difficult to capture within software localization. Each natural language in the world evolves at its own pace and in its own unique way, creating vibrant and rich means of expression. Sadly, simple static string translation is often ill-equipped to properly accommodate gender, conjugation, plural, or case changes required within the language by changing string variables and other run-time string composition issues. This is why we created L20n.
We’re super happy to announce that we’ve released an amazing tool to help localizers, engineers, and localization tool developers learn and practice L20n themselves! l20n.org contains a real-time text editor that allows you to edit L20n code and visually see how it impacts localization. The real-time editor is part of the “Learn” section of l20n.org dedicated to walk you through what L20n has to offer, feature by feature, and give you a chance to try these features out in real-time.
L20n is a localization framework (comprised of a pseudo-programming language) meant to transfer the ability to localize software using the fullness of any language from the developer to the localizer. L20n empowers localizers to be more independent of source language developers and have more control and flexibility in localizing software according to their native language’s demands.
l20n.org is live and running now! Go give it a try! Not only is it live, but its hosted on github for you to fork and contribute to. Enjoy testing out L20n!
J. Paul Reed: Eulogy for a Founding Father, revisited
In response to my post earlier this week on Tinderbox’s end-of-life, reader Carsten Mattner asked:
Reading [your post], I couldn’t figure out what replaced Tinderbox for the Mozilla builds. What feeds tbpl? Does Mozilla not use Tinderbox to build continuously?
When I left Mozilla in 2007, there was a Release Engineering project in progress to actively replace Tinderbox (Client) with buildbot. So in short, no, Mozilla does not use Tinderbox Client to drive its continuous integration builds, and hasn’t for some time.
Do they still use buildbot today?
I didn’t know the answer to that question, so I tracked down Coop on IRC, who graciously gave me a few minutes of his time to answer exactly that.
He said:
- Mozilla currently uses “95% buildbot, with 5% Jenkins for random small projects”
- There are multiple buildbot masters that drive the buildbot clients
- Unlike the out-of-the-box buildbot master setup, the masters query a job scheduling database instead of monitoring source control for changes themselves; they then report their results to a database, which tbpl (and other services) use to generate their reports/dashboards; the buildbot master waterfall pages aren’t accessible to the external world (which makes sense, because they include unsecured administrative functionality1)
- There are about 60 masters right now, but Coop said “number keeps growing though, so we need to rethink the whole solution”
So there’s your answer, Carsten!
_______________
1 A long standing criticism of mine, among others?
Selena Deckelmann: Migrations with Alembic: a lightspeed tour
I’ve got a Beer & Tell to give about alembic. Alembic is a migration tool that works with SQLAlchemy. I’m using it for database migrations with PostgreSQL.
So, here’s what I want to say today:
- Written by SQLAlchemy wiz Mike Bayer
- Here’s the tutorial. Socorro is now using alembic in production with SQLAlchemy 0.6.x. I’m hoping to get us upgraded to 0.8.x soon.
- Here’s what running an upgrade in production for Socorro looks like. Awesome right?
- Here’s what a migration looks like.
- Here’s a configuration file.
- Generating a migration from the command line might look something like:
alembic revision -m "bug XXXXXX Add a new table" --autogenerate
The most difficult thing to deal with so far are the many User Defined Functions that we use in Socorro. This isn’t something that any migration tools I tested deal well with.
Happy to answer questions! And I’ll see about making a longer talk about this transition soon.
Matt Thompson: Using Bugzilla for Webmaker
cross-posted from the Webmaker blog
We use Bugzilla to work open and get stuff doneWebmaker, like many Mozilla projects, uses an issue tracker called Bugzilla for filing tickets and getting stuff done. These two new pages provide tips and tricks for filing bugs, and for getting the most out of Bugzilla:
- Bugzilla for Webmaker — the best place to start. How to file a Webmaker bug, plus simple tweaks for making Bugzilla easier to use.
- Bugzilla for Webmaker: PRO TIPS – for digging deeper. How to make it easier for users to file tickets, tagging, searching and tracking bugs, Frequently Asked Questions and more.
We work open. Webmaker is an open source, non-profit project powered by a global community of friendly humans like you. Anyone can create a ticket, comment on a ticket, and contribute. Just because it’s called a “bug” doesn’t necessarily mean there’s something wrong. It could just be a to-do, or a suggestion. All your tickets are welcome — don’t worry if you’re doing it right. We’re a friendly community, and we want your ideas!
Lawrence Mandel: May Open Web Open Mic Toronto: Call for Presenters
What: Mozilla Open Web Open Mic
When: May 22, 6-9pm ET.
Where: Mozilla Toronto, 366 Adelaide St. W, 5th Floor
Mozilla Open Web Open Mic (OWOM) is back for May. Put on by the Mozilla Toronto community, OWOM features a science share exploration and lightening talks (5 min). April’s event had a great turnout (50-60 people) and included a variety of content from WEBVTT, to MakerFaire, to my talk Building for Mobile Web Compatibility.
The call is currently open for science share participants and speakers. Sign up at
https://mozillianstoronto.etherpad.mozilla.org/owom-may-2013
Interested in attending? Sign up now at
http://owommay2013.eventbrite.ca/#
Tagged: mozilla, mozilla community, toronto
David Ascher: You are more than your job title
In grad school, I remember a conversation across the campus green with an visiting psychologist from Harvard. I don’t remember much about the conversation except that he introduced me to Isaiah Berlin’s notion of the Hedgehog and the Fox, and correctly pegged me as a Fox. I think I was a bit offended at the simplification, but time has proven him right. I’m certainly no hedgehog.
I got into a silly argument on twitter last night, about whether my looking to hire someone who I labeled (as job descriptions make us do) a “Coding Designer” was not just foolish (I’d seen the Unicorn references in my tweetstream already) but apparently a bad idea, because, so the ultra-simplified argument goes, you somehow can’t be both. And so I’ll use the energy to rant a bit about what seem to be prevailing attitudes around titleism and narrow definitions of “professionalism”.
We all need to define ourselves to others. It helps us be understood, and hopefully valued. Labels can be useful for that. We also, even more, like to label others. It helps us simplify our approach to them. If I can find a label for you, then I can rely on a prioris about how people with that label tend to think and behave, and I don’t need to actually get to know you too much. The more people we interact with, the more important these shortcuts are. Some roles are particularly subject to that (Recruiters, VCs, politicians, etc. — people who routinely talk to dozens if not hundreds of people a day). And the best at these roles are those who use a different labeling system than their peers. Recruiters who see the latent ambition or genius in a shy candidate; VCs who see the determination behind a stutter, or, conversely, the lack of self-confidence behind the bravado, etc.
Labels are useful and practical in the short term. And I don’t know how one could run a large HR department without them. But we should be careful to not take them too seriously, as in the long term, they can hurt. They hurt because people, especially interesting, worth-getting-to-know people, are much more subtle, complicated, confusing and hard to categorize creatures. Whether you take the label too seriously when thinking about others (e.g., refuse to see the valid opinion about a design expressed by a non-Designer) or about yourself (and limit your impact on the world because “oh, that’s not something that a mere ____ like me could say/do”), you’re not getting the most out of anyone involved.
As I write this, I realize that I feel quite strongly about this topic. Part of it is probably because I grew up in an educational system, which at least then believed way too much in labeling people and determining their fate based on that label. Much waste ensued. Part of it is probably because I can’t for the life of me figure out what my label should be, and if I can’t, then that must be bad. I’ve had a range of professional labels, from scientist to engineer, architect, team lead, vice president, CTO, CEO, blah blah blah. I’ve been called a designer, strategist, entrepreneur, boss, blah blah blah. None of those words will, I hope, be in my epitaph. And so I get cranky on twitter at night, because if there are people who strive to be both excellent at design and at coding, then by golly we should encourage them.
Titles are a poor approximation of a professional ideal, and a profession is a poor approximation of a human’s breadth, contributions, and talents. Embrace your inner fox, and if you happen to have both design and coding skills, can see a problem, conjure up a solution, prototype it, welcome challenges to your idea from peers, data, and users, apply.
You are more than your job title
In grad school, I remember a conversation across the campus green with an visiting psychologist from Harvard. I don’t remember much about the conversation except that he introduced me to Isaiah Berlin’s notion of the Hedgehog and the Fox, and correctly pegged me as a Fox. I think I was a bit offended at the simplification, but time has proven him right. I’m certainly no hedgehog.
I got into a silly argument on twitter last night, about whether my looking to hire someone who I labeled (as job descriptions make us do) a “Coding Designer” was not just foolish (I’d seen the Unicorn references in my tweetstream already) but apparently a bad idea, because, so the ultra-simplified argument goes, you somehow can’t be both. And so I’ll use the energy to rant a bit about what seem to be prevailing attitudes around titleism and narrow definitions of “professionalism”.
We all need to define ourselves to others. It helps us be understood, and hopefully valued. Labels can be useful for that. We also, even more, like to label others. It helps us simplify our approach to them. If I can find a label for you, then I can rely on a prioris about how people with that label tend to think and behave, and I don’t need to actually get to know you too much. The more people we interact with, the more important these shortcuts are. Some roles are particularly subject to that (Recruiters, VCs, politicians, etc. — people who routinely talk to dozens if not hundreds of people a day). And the best at these roles are those who use a different labeling system than their peers. Recruiters who see the latent ambition or genius in a shy candidate; VCs who see the determination behind a stutter, or, conversely, the lack of self-confidence behind the bravado, etc.
Labels are useful and practical in the short term. And I don’t know how one could run a large HR department without them. But we should be careful to not take them too seriously, as in the long term, they can hurt. They hurt because people, especially interesting, worth-getting-to-know people, are much more subtle, complicated, confusing and hard to categorize creatures. Whether you take the label too seriously when thinking about others (e.g., refuse to see the valid opinion about a design expressed by a non-Designer) or about yourself (and limit your impact on the world because “oh, that’s not something that a mere ____ like me could say/do”), you’re not getting the most out of anyone involved.
As I write this, I realize that I feel quite strongly about this topic. Part of it is probably because I grew up in an educational system, which at least then believed way too much in labeling people and determining their fate based on that label. Much waste ensued. Part of it is probably because I can’t for the life of me figure out what my label should be, and if I can’t, then that must be bad. I’ve had a range of professional labels, from scientist to engineer, architect, team lead, vice president, CTO, CEO, blah blah blah. I’ve been called a designer, strategist, entrepreneur, boss, blah blah blah. None of those words will, I hope, be in my epitaph. And so I get cranky on twitter at night, because if there are people who strive to be both excellent at design and at coding, then by golly we should encourage them.
Titles are a poor approximation of a professional ideal, and a profession is a poor approximation of a human’s breadth, contributions, and talents. Embrace your inner fox, and if you happen to have both design and coding skills, can see a problem, conjure up a solution, prototype it, welcome challenges to your idea from peers, data, and users, apply.
David Ascher: You are more than your job title
In grad school, I remember a conversation across the campus green with an visiting psychologist from Harvard. I don’t remember much about the conversation except that he introduced me to Isaiah Berlin’s notion of the Hedgehog and the Fox, and correctly pegged me as a Fox. I think I was a bit offended at the simplification, but time has proven him right. I’m certainly no hedgehog.
I got into a silly argument on twitter last night, about whether my looking to hire someone who I labeled (as job descriptions make us do) a “Coding Designer” was not just foolish (I’d seen the Unicorn references in my tweetstream already) but apparently a bad idea, because, so the ultra-simplified argument goes, you somehow can’t be both. And so I’ll use the energy to rant a bit about what seem to be prevailing attitudes around titleism and narrow definitions of “professionalism”.
We all need to define ourselves to others. It helps us be understood, and hopefully valued. Labels can be useful for that. We also, even more, like to label others. It helps us simplify our approach to them. If I can find a label for you, then I can rely on a prioris about how people with that label tend to think and behave, and I don’t need to actually get to know you too much. The more people we interact with, the more important these shortcuts are. Some roles are particularly subject to that (Recruiters, VCs, politicians, etc. — people who routinely talk to dozens if not hundreds of people a day). And the best at these roles are those who use a different labeling system than their peers. Recruiters who see the latent ambition or genius in a shy candidate; VCs who see the determination behind a stutter, or, conversely, the lack of self-confidence behind the bravado, etc.
Labels are useful and practical in the short term. And I don’t know how one could run a large HR department without them. But we should be careful to not take them too seriously, as in the long term, they can hurt. They hurt because people, especially interesting, worth-getting-to-know people, are much more subtle, complicated, confusing and hard to categorize creatures. Whether you take the label too seriously when thinking about others (e.g., refuse to see the valid opinion about a design expressed by a non-Designer) or about yourself (and limit your impact on the world because “oh, that’s not something that a mere ____ like me could say/do”), you’re not getting the most out of anyone involved.
As I write this, I realize that I feel quite strongly about this topic. Part of it is probably because I grew up in an educational system, which at least then believed way too much in labeling people and determining their fate based on that label. Much waste ensued. Part of it is probably because I can’t for the life of me figure out what my label should be, and if I can’t, then that must be bad. I’ve had a range of professional labels, from scientist to engineer, architect, team lead, vice president, CTO, CEO, blah blah blah. I’ve been called a designer, strategist, entrepreneur, boss, blah blah blah. None of those words will, I hope, be in my epitaph. And so I get cranky on twitter at night, because if there are people who strive to be both excellent at design and at coding, then by golly we should encourage them.
Titles are a poor approximation of a professional ideal, and a profession is a poor approximation of a human’s breadth, contributions, and talents. Embrace your inner fox, and if you happen to have both design and coding skills, can see a problem, conjure up a solution, prototype it, welcome challenges to your idea from peers, data, and users, apply.
Mozilla Has Decided Not To Block Cookies In Firefox Just Yet - WebProNews
Mozilla Has Decided Not To Block Cookies In Firefox Just Yet
WebProNews
Online advertisers have been nervous the past few weeks as Mozilla moved forward with its plans to block third-party cookies by default in its Firefox browser. Some advertiser groups have even claimed that Mozilla's policy will “undermine American ...
Michelle Thorne: Webmaker Train the Trainer
Back in March, we kicked off the first in hopefully a series of train-the-trainer (TTT) events for webmaking.
The idea is to run events that train people who go on to train others how to teach the web. We focused on practicing an open and participatory ethos, adapting lesson plans, and facilitating events.
This is a post to share what we did and encourage people in designing their own train-the-trainer events.
How to run a Webmaker Train the TrainerOur prototype, the Reps Training Days, ran for four days in Athens, Greece with 40 Reps from around the world. The agenda was based on Laura Hilliger’s research and insights on successful TTT program and on Allen Gunn’s participatory event methodology. It was made possible by the amazing Mozilla Greek community.
Our participants were Mozilla Reps, a fantastic ambassador program with some of the most active and thoughtful Mozillians. Reps have been early adopters and innovators with Webmaker. They organized nearly 50 events during last year’s Summer Code Party and are leading the way in developing tools, tutorials, and localization for Webmaker. It seemed like a natural fit to run our first TTT with them.
1. Participate in a Webmaker eventThe first day of Training Days was spent observing and participating in a Hive Pop-Up, organized by Hive Athens. This was an opportunity for the participants to experience a webmaker event firsthand, to see the tools and activities in action, to learn about the logistics, and to understand the vibe.
We then circled up to discuss what we saw. Participants shared their reflections on what worked well at the pop-up and what they would change if they did their own.
2. Build the training agendaThen we opened up the training days properly. While we had topics in mind we wanted to hack on together, it was more important that everyone in the room thought about what they want to learn or discuss. So we had an agenda brainstorm.
To do this: we split into groups for 3 people. On post-it notes, we wrote down topics. 1 topic per post-it and the encouragement to write it as concretely as possible.
Then everyone pasted the notes on the wall. We read them all and then clustered them by themes. This collaborative board formed both critical event documentation as well as agenda fodder for the coming days.
3. Teach someone somethingTo warm up to the idea of teaching, we then got into pairs. The task: teach someone something in 5 minutes.
One person would go and then switch. Even if you knew what was being taught, you were encouraged to play a good learner, asking good questions and prompting the teacher.
After this exercise, we circled up and discussed what we observed from this experience. For many, it was a great way to think about how to explain something clearly, using metaphors and knowledge building blocks. It helped bring people into a teaching mindset.
4. Make a learner profileNow that we’ve been thinking about teachers and learners, we made small groups and hacked together a learner’s profile.
This goal of this activity was to think about who our learners are. We used Webmaker tools to make these profiles, which was also a fun, maker-y way to be introduced to these tools. Participants were encouraged to think about real people they want to teach.
5. Hack an event invitationAfter we’ve made our learner profiles, we thought about the kind of event we wanted to run. Most of the participants have already organized Webmaker events in the past, so there was already some familiarity with the format.
Nevertheless, it was helpful to hack together an event invitation. The idea was to think about your target learner and to make an invitation that would speak to them. Again, we used Webmaker tools to quickly pull these invitations together on the web.
6. Deep dive into lesson plansWith a learner profile, an event invitation and some familiarity with Webmaker tools, we then introduced the hackable kits. These are remixable lesson plans that help mentors, trainers, etc. to teach the web. The idea is that they are adaptable to different contexts and that people can share new ways of teaching in a shared format.
Participants poked around in the kits and asked questions. We also did some fun icebreakers so they could see the activities in action and get some energy going.
7. Playtest lesson plansNow came the fun part. We had to plan for a real live event the next day. So participants got into groups of five with one group facilitator.
They had to design a four-hour agenda for local youth. Using three recommended activities from the kits, they adapted the lesson plans. Then they walked through a script for the next day, including having people role-play as learners. It was a lot of fun to see and a great way to prepare for the big day.
8. Put training to practice at a live eventSo with some nervousness, we got ready for the live event. About a hundred youth were coming. We split into different rooms, each group of five trainers getting about 20 learners.
While there were the inevitable challenges (the internet is down! one kid won’t listen!), the Reps did a terrific job. They rolled with their scripts, adapting them as they saw what was working. They also taught well in smaller pairs with their learners, sometimes adding new challenges or tools to fit their needs.
It was a beautiful and fun thing to see. All the training the days before paid off: the youth had a lot of fun and so did we.
9. Reflect on event, lessons learned and where from hereWe ended the event with a closing circle. We talked about what we saw that day, what worked well, what didn’t. We each shared one thing we appreciated about the experience, and what we’re excited about doing next.
With that, we headed out into the city to enjoy the day and the rest of our time together.
10. Go forth and teach!Each participant left the Training Days with a local plan. It was a short list of possible collaborators in their hometown, a date for a small team huddle to bring those people together, and then a date for a larger Webmaker event to organize with their new collaborators.
We also started interest groups in topics like localization and offline tools. And now, a few months later, the participants from Training Days are now “Webmaker Super Mentors”, mentoring people in an online course to learn how to teach the web.
In the coming months, we hope to keep remixing and improving these agendas, as well as work with people who are interested in TTT in their own cities or communities.
Let us know if you’d like to get involved! #teachtheweb
Jan Odvarko: New Firebug feature: Use in Command Line
Firebug 1.12 alpha 6 introduces one new feature called simply: Use in Command Line
This feature allows referring various page objects (HTML elements, JS objects, network requests, cookies, etc.) from within Firebug Command Line.
The user can also use object's properties in JS expressions.
See issue 6422 for more details.
This post explains the feature in detail and also asks for feedback.
How it worksAs depicted on the previous screenshot the feature is represented by a new context menu item called Use in Command Line. This item is available for various objects (in various panels).
The action is simple: an expression $p is inserted into the Command Line if you execute the command. It's a variable that refers to the clicked object. You can also use the variable to access any property of the object.
What happens on the screenshot:
- The DOM panel shows an object person implemented on the page.
- The user clicks on the person's value (the green right hand part) and executes Use in Command Line.
- Command Line popup is opened within the DOM panel (so, the user doesn't have to leave the DOM panel).
- $p expression is inserted into the Command Line (and the command line automatically gets focus).
- The user presses the Enter key to evaluate the expression.
Note that the person object implemented on the page looks as follows:
var person = {name: "Bob",
age: 38
}
If you want to access properties of an object just use dot notation. You can do following in our example.
$p.name
See, even the auto-completion works as expected!
Supported ObjectsThe feature is implemented for various objects across all Firebug panels. Here is a list of those objects.
- Any JS object (even functions etc.)
- HTML elements
- CSS rules and properties
- Cookies
- Network requests
All objects accessible through the $p variable are coming from the page content except of network requests and cookies.
We are actually logging nsIHttpChannel for network requests and nsICookie for cookies. So, the object comes from chrome (privileged scope) and isn't accessible in the page content. This way, the user has more info, but it could be confusing since the user could expect that the data are actually accessible from the page content (and Firebug is for page content debugging).
Possible options:
- Do not implement the feature for network requests and cookies
- Implement the feature only for XHRs (and show the real XMLHttpRequest instance) and cookie (coming from document.cookie)
- Keep it as it is
- Anything else?
What do you think?
Also, would you like to refer more objects at the same time? Something like having more variables (a history) available: $p0, $p1, $p2, ...
How would you expect it to be working?
Thanks for any feedback!
Firefox 22 Won't Block Third-Party Tracking Cookies: Why Mozilla Delayed ... - iDesignTimes.com
Firefox 22 Won't Block Third-Party Tracking Cookies: Why Mozilla Delayed ...
iDesignTimes.com
After all the fuss we've heard about Mozilla Firefox update 22 including a controversial third-party cookie tracking blocker, it seems that it might have been a little too good to be true as Mozilla announced this week it will delay blocking third ...
Mozilla Firefox delays patch to block third-party cookies - Washington Post
ExtremeTech
Mozilla Firefox delays patch to block third-party cookies
Washington Post
Mozilla, the non-profit group that makes the Firefox browser, says that it will delay its plans for rolling out a version of its browser that would increase restrictions on cookies — pieces of code that allow companies to monitor how people use the Web.
Mozilla drags its feet on blocking third-party tracking cookiesExtremeTech
Mozilla delays blocking advertisers' cookies in FirefoxThe Verge
Mozilla Delays Firefox 22 Cookie Blocker, Says More Work Is NeededThe Next Web
Ars Technica -InfoWorld -PC Magazine
alle 35 nieuwsartikelen »