1月25日，据外国媒体报道，去年夏季，Mozilla推出了一款试验性的Firefox，能够支持基于网页的虚拟现实应用，这样的应用原本需要通过Oculus Rift来体验。但在本周初，支持网页版虚拟现实的应用也终于着陆Firefox ...
en meer »Google Nieuws
A bunch of us were in Toronto last week hacking on MozReview.
One of the cool things we did was deploy a bot for performing Python static analysis. If you submit some .py files to MozReview, the bot should leave a review. If it finds violations (it uses flake8 internally), it will open an issue for each violation. It also leaves a comment that should hopefully give enough detail on how to fix the problem.
While we haven't done much in the way of performance optimizations, the bot typically submits results less than 10 seconds after the review is posted! So, a human should never be reviewing Python that the bot hasn't seen. This means you can stop thinking about style nits and start thinking about what the code does.
This bot should be considered an alpha feature. The code for the bot isn't even checked in yet. We're running the bot against production to get a feel for how it behaves. If things don't go well, we'll turn it off until the problems are fixed.
I'd also like to eventually make it easier to locally run the same static analysis we run in MozReview. Addressing problems locally before pushing is a no-brainer since it avoids needless context switching from other people and is thus better for productivity. This will come in time.
Report issues in #mozreview or in the Developer Services :: MozReview Bugzilla component.
I've written an extensive testing framework for Mozilla's version control tools. Despite it being a little rough around the edges, I'm a bit proud of it.
When you run tests for MozReview, Mozilla's heavily modified Review Board code review tool, the following things happen:
- A MySQL server is started in a Docker container.
- A Bugzilla server (running the same code as bugzilla.mozilla.org) is started on an Apache httpd server with mod_perl inside a Docker container.
- A RabbitMQ server mimicking pulse.mozilla.org is started in a Docker container.
- A Review Board Django development server is started.
- A Mercurial HTTP server is started
In the future, we'll likely also need to add support for various other services to support MozReview and other components of version control tools:
- The Autoland HTTP service will be started in a Docker container, along with any other requirements it may have.
- An IRC server will be started in a Docker container.
- Zookeeper and Kafka will be started on multiple Docker containers
The entire setup is pretty cool. You have actual services running on your local machine. Mike Conley and Steven MacLeod even did some pair coding of MozReview while on a plane last week. I think it's pretty cool this is even possible.
There is very little mocking in the tests. If we need an external service, we try to spin up an instance inside a local container. This way, we can't have unexpected test successes or failures due to bugs in mocking. We have very high confidence that if something works against local containers, it will work in production.
I currently have each test file owning its own set of Docker containers and processes. This way, we get full test isolation and can run tests concurrently without race conditions. This drastically reduces overall test execution time and makes individual tests easier to reason about.
As cool as the test setup is, there's a bunch I wish were better.
Spinning up and shutting down all those containers and processes takes a lot of time. We're currently sitting around 8s startup time and 2s shutdown time. 10s overhead per test is unacceptable. When I make a one line change, I want the tests to be instantenous. 10s is too long for me to sit idly by. Unfortunately, I've already gone to great pains to make test overhead as short as possible. Fig wasn't good enough for me for various reasons. I've reimplemented my own orchestration directly on top of the docker-py package to achieve some significant performance wins. Using concurrent.futures to perform operations against multiple containers concurrently was a big win. Bootstrapping containers (running their first-run entrypoint scripts and committing the result to be used later by tests) was a bigger win (first run of Bugzilla is 20-25 seconds).
I'm at the point of optimizing startup where the longest pole is the initialization of the services inside Docker containers themselves. MySQL takes a few seconds to start accepting connections. Apache + Bugzilla has a semi-involved initialization process. RabbitMQ takes about 4 seconds to initialize. There are some cascading dependencies in there, so the majority of startup time is waiting for processes to finish their startup routine.
Another concern with running all these containers is memory usage. When you start running 6+ instances of MySQL + Apache, RabbitMQ, + ..., it becomes really easy to exhaust system memory, incur swapping, and have performance fall off a cliff. I've spent a non-trivial amount of time figuring out the minimal amount of memory I can make services consume while still not sacrificing too much performance.
It is quite an experience having the problem of trying to minimize resource usage and startup time for various applications. Searching the internet will happily give you recommended settings for applications. You can find out how to make a service start in 10s instead of 60s or consume 100 MB of RSS instead of 1 GB. But what the internet won't tell you is how to make the service start in 2s instead of 3s or consume as little memory as possible. I reckon I'm past the point of diminishing returns where most people don't care about any further performance wins. But, because of how I'm using containers for end-to-end testing and I have a surplus of short-lived containers, it is clearly I problem I need to solve.
I might be able to squeeze out a few more seconds of reduction by further optimizing startup and shutdown. But, I doubt I'll reduce things below 5s. If you ask me, that's still not good enough. I want no more than 2s overhead per test. And I don't think I'm going to get that unless I start utilizing containers across multiple tests. And I really don't want to do that because it sacrifices test purity. Engineering is full of trade-offs.
Another takeaway from implementing this test harness is that the pre-built Docker images available from the Docker Registry almost always become useless. I eventually make a customization that can't be shoehorned into the readily-available image and I find myself having to reinvent the wheel. I'm not a fan of the download and run a binary model, especially given Docker's less-than-stellar history on the security and cryptography fronts (I'll trust Linux distributions to get package distribution right, but I'm not going to be trusting the Docker Registry quite yet), so it's not a huge loss. I'm at the point where I've lost faith in Docker Registry images and my default position is to implement my own builder. Containers are supposed to do one thing, so it usually isn't that difficult to roll my own images.
There's a lot to love about Docker and containerized test execution. But I feel like I'm foraging into new territory and solving problems like startup time minimization that I shouldn't really have to be solving. I think I can justify it given the increased accuracy from the tests and the increased confidence that brings. I just wish the cost weren't so high. Hopefully as others start leaning on containers and Docker more for test execution, people start figuring out how to make some of these problems disappear.
I posted this following text as a comment 3 days ago on Mark Surman's blog on Transparency habits, but it is still in the moderation queue. So instead of taking the chance to lose it. I'm reposting that comment here. This might need to be develop by a followup post.
I encourage everyone at Mozilla to ask themselves: how can we all build up our transparency habits in 2015? If you already have good habits, how can you help others? If, like me, you’re a bit rusty, what small things can you do to make your work more open?
The mistake we often do with transparency is that we think it is obvious for most people. But working in a transparent way requires a lot of education and mentoring. It’s one thing we should try to improve at Mozilla when onboarding new employees. Teaching what it means to be transparent. I’m not even sure everyone has the same notion of what transparency means already.
For example, too many times, I receive emails in private. That’s unfortunate because it creates information silos and it becomes a lot harder to open up a conversation which started in private. Because I was kind of tired of this, I created a set of slides and explanation for learning how to work with emails. Available in French and English.
Some people are afraid of working in the open for many reasons. They may come from a company where secrecy was very strong, or they had a bad experience by being too open. It takes then time to re-learn the benefits of working in the open.
So because you asked an open question :) Some items.
- Each time you sent an email, it probably belongs to a project. Send the email to the person (To: field) and always add in copy the relevant mailing list (Cc: field). You’ll get an archive, URL pointer for the future, etc.
- Each time you are explaining something (such as a process, an howto, etc) to someone, make it a blog post, then send this URL to this someone. It will benefit more people on the long term.
- Each time, you’re having a meeting, choose one scribe and scribe down this meeting and publish the minutes of the meetings. There are many techniques associated to these. See for example the record of Web Compat team meeting on January 13, 2015 and the index of all meetings (I could explain how we manage that in a blog post).
- Each time you have a F2F meeting with someone or a group, take notes and publish these notes online to a stable URI. It will help other people to participate.
Let's learn together how to work in a transparent way or in the open.
Ghacks Technology News
Mozilla Wants To Bring Virtual Reality To The Browser
Last summer, Mozilla launched a very experimental version of Firefox with support for web-based virtual reality apps that could be experienced through the Oculus Rift. Earlier this week, support for WebVR also landed in Firefox's Nightly and Developer ...
Mozilla adds NPAPI plug-in sandbox to FirefoxGhacks Technology News
alle 2 nieuwsartikelen »
A recent conversation on a Mozilla mailing list about whether IRC channels should be archived or not shows what a commitment it is to remain open. It’s hard work and not always comfortable to work completely in the open.
Most of us in open source are used to “working in the open”. Everything we send to a mailing list is not only public, but archived and searchable via Google or Yahoo! forever. Five years later, you can go back and see how I did my job as Executive Director of GNOME. Not only did I blog about it, but many of the conversations I had were on open mailing lists and irc channels.
There are many benefits to being open.
Being open means that anybody can participate, so you get much more help and diversity.
Being open means that you are transparent and accountable.
Being open means you have history. You can also go back and see exactly why a decision was made, what the pros and cons were and see if any of the circumstances have changed.
But it’s not easy.
Being open means that when you have a disagreement, the world can follow along. We warn teenagers about not putting too much on social media, but can you imagine every disagreement you’ve ever had at work being visible to all your future employers. (And spouses!)
But those of us working in open source have made a commitment to be open and we try hard.
Many of us get used to working in the open, and we think it feels comfortable and we think we’re good at it. And then something will remind us that it is a lot of work and it’s not always comfortable. Like a conversation about whether irc conversations should be archived or not. IRC conversations are public but not always archived. So people treat them as a place where anyone can drop in but the conversation is bounded in time and limited to the people you can see in the room. The fact that these informal conversations might be archived and read by anyone and everyone later means that you now have to think a lot more about what you are saying. It’s less of a chat and more of a weighed conversation.
The fact that people steeped in open source are having a heated debate about whether Mozilla IRC channels should be archived or not shows that it’s not easy being open. It takes a lot of work and a lot of commitment.
This week I’ve been:
- Writing a post for the Webmaker blog on Building version 1.5 of Mozilla’s Web Literacy Map
- Visiting Guy Merchant, Cathy Burnett and Sue Beckingham at Sheffield Hallam University about our web literacy and Clubs work.
- Added ‘issues’ to improve the Web Literacy Map from last week’s call etherpad to GitHub.
- Discussing an upcoming Webmaker whitepaper on learning pathways with Carla Casilli and Karen Smith.
- Preparing for and leading this week’s Web Literacy Map community call. I wrote this up along with the audio here – and also wrote another inspired by the discussion entitled Ontology, mentorship and web literacy.
- Meeting with Chris Wilde to arrange date/time for our first Web Literacy Club.
- Composing learning objectives for Clubs activities that we’re testing (Kraken the Code and Ping Kong).
- Drafting a post for DMLcentral about learning pathways (tied to the whitepaper mentioned above). This should go live next week or the week after.
- Re-arranged issues part of Webmaker Curriculum repository on GitHub with labels and milestones.
- Replying to various people wanting feedback, me to review their work, or keynote their conference.
- Commenting on the Learning Networks roadmap.
- Writing some other stuff:
- Your questions answered about Dynamic Skillset, my upcoming consultancy
- Announcing TWO new e-books: #uppingyourgame v2.0 and an Essential Elements of Digital Literacies workbook<
- Seven places I find interesting, relevant and useful stuff in 2015
- Wednesday Wisdom #22: Have Double of Life’s Necessities
- Volcanoes and ambiguity
- How do you explain the web to your kids?
I wasn’t at BETT this week. It’s a great place to meet people I haven’t seen for a while and last year I even gave a couple of presentations and a masterclass. However, this time around, my son’s birthday and party gave me a convenient excuse to miss it.
Next week I’m working from home as usual. In fact, I don’t think I’m away again until our family holiday to Dubai in February half-term!
Image CC BY Dave Fayram
Ghacks Technology News
Mozilla adds NPAPI plug-in sandbox to Firefox
Ghacks Technology News
Sandboxing finally comes to the Firefox web browser. After enabling a (currently) non-restrictive content sandbox in Firefox Nightly last month, the organization enabled the upcoming NPAPI plug-in sandbox in Aurora and Nightly versions of the browser ...
en meer »
One of the main differences in how mercurial and git track files is that mercurial does rename and copy tracking and git doesn’t. So in the case of mercurial, users are expected to explicitly rename or copy the files through the mercurial command line so that mercurial knows what happened. Git simply doesn’t care, and will try to detect after the fact when you ask it to.
The consequence is that my git-remote-hg, being currently a limited prototype, doesn’t make the effort to inform mercurial of renames or copies.
It was a conscious choice on my part to make git-remote-hg public without rename/copies detection, because file renames/copies are not happening often, and can just as much not be registered by mercurial users.
In fact, they haven’t all been registered for as long as Mozilla has been using mercurial (see below, I didn’t actually know I was so spot on when I wrote this sentence), and people haven’t been pointed at for using broken tools (and I’ll skip the actual language that was used when talking about Ehsan’s push).
And since I’d rather not make unsubstantiated claims, I dug in all of mozilla-central and related repositories (inbound, b2g-inbound, fx-team, aurora, beta, release, esr*) and here is what I found, only accounting files that have been copied or renamed without being further modified (so, using git diff-tree -r -C100%, and eliminating empty files), and correlating with the mercurial rename/copy metadata:
- There have been 45069 file renames or copies in 1546 changesets.
- Mercurial doesn’t know 5482 (12.1%) of them, from 419 (27.1%) changesets.
- 72 of those changesets were backouts.
- 19 of those backouts were of changesets that didn’t have rename/copy information, so 53 of those backouts didn’t actually undo what mercurial knew of those backed out changesets.
- Those 419 changesets were from 144 distinct authors (assuming I didn’t miss some duplicates from people who changed email).
- Fun fact, the person with colorful language, and that doesn’t like git-remote-hg, is part of them. I am too, and that was with mercurial.
- The most recent occurrence of renames/copies unknown to mercurial is already not Ehsan’s anymore.
- The oldest occurrence is in the 19th (!) mercurial changeset.
And that’s not counting all the copies and renames with additional modifications.
Fun fact, this is what I found in the Mercurial mercurial repository:
- There have been 255 file renames or copies in 41 changesets.
- Mercurial doesn’t know about 38 (14.9%) of them, from 4 (9.7%) changesets.
- One of those changesets was from Matt Mackall himself (creator and lead developer of mercurial).
There are 1061 files in mercurial, versus 115845 in mozilla-central, so there is less occasion for renames/copies there, still, even they forget to use “hg move” and break their history as a result.
I think this shows how requiring explicit user input simply doesn’t pan out.
Meanwhile, I have prototype copy/rename detection for git-remote-hg working, but I need to tweak it a little bit more before publishing.
In this beta, as in beta 2, we have a bug fixes for MSE. We have also a few bugs found with the release of Firefox 35. As usual, beta 3 is a desktop only version.
- 43 changesets
- 118 files changed
- 1261 insertions
- 476 deletions
ExtensionOccurrences cpp17 js13 h7 ini6 html6 jsm3 xml1 webidl1 txt1 svg1 sjs1 py1 mpd1 list1
ModuleOccurrences dom20 browser18 toolkit6 dom4 dom4 testing3 gfx3 netwerk2 layout2 mobile1 media1 docshell1 build1
List of changesets:Steven MichaudBug 1118615 - Flash hangs in HiDPI mode on OS X running peopleroulette app. r=mstange a=sledru - 430bff48811d Mark GoodwinBug 1096197 - Ensure SSL Error reports work when there is no failed certificate chain. r=keeler, a=sledru - a7f164f7c32d Seth FowlerBug 1121802 - Only add #-moz-resolution to favicon URIs that end in ".ico". r=Unfocused, a=sledru - d00b4a85897c David MajorBug 1122367 - Null check the result of D2DFactory(). r=Bas, a=sledru - 57cb206153af Michael ComellaBug 1116910 - Add new share icons in the action bar for tablet. r=capella, a=sledru - f6b2623900f1 Jonathan WattBug 1122578 - Part 1: Make DrawTargetCG::StrokeRect stroke from the same corner and in the same direction as older OS X and other Moz2D backends. r=Bas, a=sledru - d3c92eebdf3e Jonathan WattBug 1122578 - Part 2: Test start point and direction of dashed stroking on SVG rect. r=longsonr, a=sledru - 7850d99485e6 Mats PalmgrenBug 1091709 - Make Transform() do calculations using gfxFloat (double) to avoid losing precision. r=mattwoodrow, a=sledru - 0b22d12d0736 Hiroyuki IkezoeBug 1118749 - Need promiseAsyncUpdates() before frecencyForUrl. r=mak, a=test-only - 4501fcac9e0b Jordan LundBug 1121599 - remove android-api-9-constrained and android-api-10 mozconfigs from all trees, r=rnewman a=npotb DONTBUILD - 787968dadb44 Tooru FujisawaBug 1115616 - Commit composition string forcibly when search suggestion list is clicked. r=gavin,adw a=sylvestre - 2d629038c57b Ryan VanderMeulenBug 1075573 - Disable test_videocontrols_standalone.html on Android 2.3 due to frequent failures. a=test-only - a666c5c8d0ba Ryan VanderMeulenBug 1078267 - Skip netwerk/test/mochitests/ on Android due to frequent failures. a=test-only - 0c36034999bb Christoph KerschbaumerBug 1121857 - CSP: document.baseURI should not get blocked if baseURI is null. r=sstamm, a=sledru - a9b183f77f8d Christoph KerschbaumerBug 1122445 - CSP: don't normalize path for CSP checks. r=sstamm, a=sledru - 7f32601dd394 Christoph KerschbaumerBug 1122445 - CSP: don't normalize path for CSP checks - test updates. r=sstamm, a=sledru - a41c84bee024 Karl TomlinsonBug 1085247 enable remaining mediasource-duration subtests a=sledru - d918f7ea93fe Sotaro IkedaBug 1121658 - Remove DestroyDecodedStream() from MediaDecoder::SetDormantIfNecessary() r=roc a=sledru - 731843c58e0d Jean-Yves AvenardBug 1123189: Use sourceended instead of loadeddata to check durationchanged count r=karlt a=sledru - 09df37258699 Karl TomlinsonBug 1123189 Queue "durationchange" instead of dispatching synchronously r=cpearce a=sledru - 677c75e4d519 Jean-Yves AvenardBug 1123269: Better fix for Bug 1121876 r=cpearce a=sledru - 56b7a3953db2 Jean-Yves AvenardBug 1123054: Don't check VDA reference count. r=rillian a=sledru - a48f8c55a98c Andreas PehrsonBug 1106963 - Resync media stream clock before destroying decoded stream. r=roc, a=sledru - cdffc642c9b9 Ben TurnerBug 1113340 - Make sure blob urls can load same-prcess PBackground blobs. r=khuey, a=sledru - c16ed656a43b Paul AdenotBug 1113925 - Don't return null in AudioContext.decodeAudioData. r=bz, a=sledru - 46ece3ef808e Masatoshi KimuraBug 1112399 - Treat NS_ERROR_NET_INTERRUPT and NS_ERROR_NET_RESET as SSL errors on https URLs. r=bz, a=sledru - ba67c22c1427 Hector ZhaoBug 1035400 - 'restart to update' button not working. r=rstrong, a=sledru - 8a2a86c11f7c Ryan VanderMeulenBacked out the code changes from changeset c16ed656a43b (Bug 1113340) since Bug 701634 didn't land on Gecko 36. - e8effa80da5b Ben TurnerBug 1120336 - Land the test-only changes on beta. r=khuey, a=test-only - a6e5dedbd0c0 Sami JaktholmBug 1001821 - Wait for eyedropper to be destroyed before ending tests and checking for leaks. r=pbrosset, a=test-only - 4036f72a0b10 Mark HammondBug 1117979 - Fix orange by not relying on DNS lookup failure in the 'error' test. r=gavin, a=test-only - e7d732bf6091 Honza BambasBug 1123732 - Null-check uri before trying to use it. r=mcmanus, a=sledru - 3096b7b44265 Florian QuèzeBug 1103692 - ReferenceError: bundle is not defined in webrtcUI.jsm. r=felipe, a=sledru - 9b565733c680 Bobby HolleyBug 1120266 - Factor some machinery out of test_BufferingWait into mediasource.js and make it Promise-friendly. r=jya, a=sledru - ff1b74ec9f19 Jean-Yves AvenardBug 1120266 - Add fragmented mp4 sample videos. r=cajbir, a=sledru - 53f55825252a Paul AdenotBug 698079 - When using the WASAPI backend, always output audio to the default audio device. r=kinetik, a=sledru - 20f7d44346da Paul AdenotBug 698079 - Synthetize the clock when using WASAPI to prevent A/V desynchronization issues when switching the default audio output device. r=kinetik, a=sledru - 0411d20465b4 Matthew NoorenbergheBug 1079554 - Ignore most UITour messages from pages that aren't visible. r=Unfocused, a=sledru - e35e98044772 Markus StangeBug 1106906 - Always return false from nsFocusManager::IsParentActivated in the parent process. r=smaug, a=sledru - 0d51214654ad Bobby HolleyBug 1121148 - Move constants that we should not be using directly into a namespace. r=cpearce, a=sledru - 1237ddff18be Bobby HolleyBug 1121148 - Make QUICK_BUFFERING_LOW_DATA_USECS a member variable and adjust it appropriately. r=cpearce, a=sledru - 62f7b8ea571f Chris AtLeeBug 1113606 - Use app-specific API keys. r=mshal, r=nalexander, a=gavin - b3836e49ae7f Ryan VanderMeulenBug 1121148 - Add missing detail:: to fix bustage. a=bustage - b3792d13df24
Mozilla's Lightbeam for Firefox add-on gets Tracking Protection feature
Ghacks Technology News
You find information about the Tracking Protection feature which Mozilla added recently to Firefox with a click on the link. Unlike full blockers, it is only blocking known tracking domains by default. Blocking those domains should not affect browsing ...
What I was reading this week:
- “Zac’s Haunted House” is a novel told in animated GIFs
- Fascinating read: Nokia saw the future, but couldn’t build it - Everything that Apple and Google are today, Nokia wanted to become
- Fantastic link list covering the history of Silicon Valley
- And yet another reason why you should have more women on your team: Why Some Teams Are Smarter Than Others
- So cool: Patagonia’s “20 Million and Change” internal VC Fund
- I disagree whole heartedly with this POV: The Startup Revolution Is About To Surge Again
- Salary Negotiations for Techies
- Pets Allowed - Why are so many animals now in places where they shouldn’t be?
- 25 Epic Graphic Design Tips for Non-Designers
- Erik Spiekermann on “Being obsessive about detail is being normal”
- Accelerators claim they are in it for the long haul — I call bullshit
- Rejection Therapy - By Making A Game Out Of Rejection, A Man Conquers Fear
- Kierkegaard on Boredom, Why Cat Listicles Fail to Answer the Soul’s Cry, and the Only True Cure for Existential Emptiness
- False Hustle: How Keeping Busy Is Making You Less Productive
- Tether is a very nice (and free) UI Design Toolkit
- Stefan Sagmeister on Storytelling. Hilarious.
- How much should I raise in my angel round? How should I spend it? Jason C’s view
Passwords are always going to be vulnerable to being cracked. Fortunately, there are solutions out there that are making it safer for users to interact with services on the web. The new standard in protecting users is Universal 2nd Factor (U2F) authentication which is already available in browsers like Google Chrome.
Mozilla currently has a bug open to start the work necessary to delivering U2F support to people around the globe and bring Firefox into parity with Chrome by offering this excellent new feature to users.
I recently reached out to the folks at Yubico who are very eager to see Universal 2nd Factor (U2F) support in Firefox. So much so that they have offered me the ability to give out up to two hundred Yubikeys with U2F support to testers and will ship them directly to Mozillians regardless of what country you live in so you can follow along with the bug we have open and begin testing U2F in Firefox the minute it becomes available in Firefox Nightly.
If you are a Firefox Nightly user and are interested in testing U2F, please use this form and apply for a code to receive one of these Yubikeys for testing. (This is only available to Mozillians who use Nightly and are willing to help report bugs and test the patch when it lands)
Thanks again to the folks at Yubico for supporting U2F in Firefox!
Mozilla Lightbeam 1.2 erhält Tracking-Schutz
Mozilla hat sein Add-on Lightbeam für Firefox in Version 1.2 veröffentlicht. Mit dem neusten Update kann der Nutzer nicht nur das Tracking von Webseiten visualisieren und einzelne Tracker blocken, sondern auch einen allgemeinen Tracking-Schutz ...
Once a month, web developers from across the Mozilla Project get together to trade and battle Pokémon. While we discover the power of friendship, we also find time to talk about our side projects and drink, an occurrence we like to call “Beer and Tell”.
Our first presenter, Osmose (that’s me!), shared a Gameboy emulator, written in Python, called gamegirl. The emulator itself is still very early in development and only has a few hundred CPU instructions implemented. It also includes a console-based debugger for inspecting the Gameboy state while executing instructions, powered by urwid.Luke Crouch: Automatic Deployment to Heroku using TravisCI and Github
Next, groovecoder shared some wisdom about his new favorite continuous deployment setup. The setup involves hosting your code on Github, running continuous integration using Travis CI, and hosting the site on Heroku. Travis supports deploying your app to Heroku after a successful build, and groovecoder uses this to deploy his master branch to a staging server.
Once the code is ready to go to production, you can make a pull request to a production branch on the repo. Travis can be configured to deploy to a different app for each branch, so once that pull request is merged, the site is deployed to production. In addition, the pull request view gives a good overview of what’s being deployed. Neat!
Friend of the blog peterbe showed off django-screencapper, a microservice that generates screencaps from video files using ffmpeg. Developed as a test to see if generating AirMozilla icons via an external service was viable, it queues incoming requests using Alligator and POSTs the screencaps to a callback URL once they’ve been generated.
A live example of the app is available at http://screencapper.peterbe.com/receiver/.tofumatt: i-dont-like-open-source AKA GitHub Contribution Hider
Motorcycle enthusiast tofumatt hates the Github contributor streak graph. To be specific, he hates the one on his own profile; it’s distracting and leads to bad behavior and imposter syndrome. To save himself and others from this terror, he created a Firefox add-on called the GitHub Contribution Hider that hides only the contribution graph on your own profile. You can install the addon by visiting it’s addons.mozilla.org page. Versions of the add-on for other browsers are in the works.
Fun fact: The power of friendship cannot, in fact, overcome type weaknesses.
If you’re interested in attending the next Beer and Tell, sign up for the email@example.com mailing list. An email is sent out a week beforehand with connection details. You could even add yourself to the wiki and show off your side-project!
See you next month!
Webmaker Demos January 23 2015
I managed to complete roughly five of my eleven goals for the week.
- Made progress on (but have not cracked) daily task management for the newly evolving systems
- Caught up on some email from time off, but still a chunk left to work through
- Spent more time writing code than expected
- Illness this week slowed me down
- These aren’t very good weeknotes, but perhaps better than none.
Nach Ende der Kooperation mit Mozilla: Google will Yahoo Nutzer abspenstig ... - Neue Zürcher Zeitung
Nach Ende der Kooperation mit Mozilla: Google will Yahoo Nutzer abspenstig ...
Neue Zürcher Zeitung
Und warum wirbt Google so offensiv um Nutzer? Im November wurde verkündet, dass Google und Mozilla nach zehn Jahren getrennte Wege gehen. Die Suchmaschine ist nicht mehr standardmässig in Firefox eingestellt. In den USA ist es Yahoo – mobil und ...
Nach Wechsel zu Yahoo: Google will Firefox-Nutzer zurückgewinnenGolem.de
Verlorene Marktanteile: Google will Firefox-Nutzer zurück gewinnenGoogleWatchBlog (Blog)
alle 4 nieuwsartikelen »
Google sofre com acordo entre Yahoo e Mozilla e sugere 'troca de buscador'
Usuários do Mozilla Firefox estão recebendo alertas do Google para trocarem seu mecanismo de buscas padrão no browser. As mensagens são exibidas ao acessar o site da gigante de buscas e são uma reação à adoção do Yahoo como sistema de busca ...
Google quer que usuários do Firefox voltem a usar motor de busca da empresaCanaltech
alle 5 nieuwsartikelen »Google Nieuws
The concept was for us to break apart the famed Shepard Fairey Mozilla dinosaur into quilt-like
Each member of the design team was assigned a tile or two and given a shape. This is the one I was assigned:
I turned that file into this:
We all met together in a video chat to upload our images on to the site.
Anticipation was building as we uploaded each shot one by one: But the final reveal made it worth all the effort!
Check out our new team page on dribbble. rawr!
Cassie also wrote about the exercise on her blog and discussed the opinion position for a designer to join the team.