mirror of
https://repo.dactyloidae.xyz/Dactyloidae/UXP.git
synced 2026-08-24 21:33:09 +09:00
13 lines
No EOL
122 KiB
XML
13 lines
No EOL
122 KiB
XML
<?xml version='1.0' encoding='UTF-8'?><?xml-stylesheet href="http://www.blogger.com/styles/atom.css" type="text/css"?><feed xmlns='http://www.w3.org/2005/Atom' xmlns:openSearch='http://a9.com/-/spec/opensearchrss/1.0/' xmlns:blogger='http://schemas.google.com/blogger/2008' xmlns:georss='http://www.georss.org/georss' xmlns:gd="http://schemas.google.com/g/2005" xmlns:thr='http://purl.org/syndication/thread/1.0'><id>tag:blogger.com,1999:blog-18929277</id><updated>2016-02-18T09:07:17.583-08:00</updated><category term="jetpack"/><title type='text'>mykzilla</title><subtitle type='html'></subtitle><link rel='http://schemas.google.com/g/2005#feed' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/posts/default'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/'/><link rel='hub' href='http://pubsubhubbub.appspot.com/'/><link rel='next' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default?start-index=26&max-results=25'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><generator version='7.00' uri='http://www.blogger.com'>Blogger</generator><openSearch:totalResults>114</openSearch:totalResults><openSearch:startIndex>1</openSearch:startIndex><openSearch:itemsPerPage>25</openSearch:itemsPerPage><entry><id>tag:blogger.com,1999:blog-18929277.post-3538029308224239292</id><published>2016-01-11T08:57:00.001-08:00</published><updated>2016-01-11T08:57:31.366-08:00</updated><title type='text'>URL Has Been Changed</title><content type='html'><dl><dd>The URL you have reached, <a href="http://mykzilla.blogspot.com/">http://mykzilla.blogspot.com/</a>, has been changed. The new URL is <a href="https://mykzilla.org/">https://mykzilla.org/</a>. Please make a note of it.</dd></dl></content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/3538029308224239292/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=3538029308224239292' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/3538029308224239292'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/3538029308224239292'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2016/01/url-has-been-changed.html' title='URL Has Been Changed'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/08518329693863067865</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-7658939959003799797</id><published>2015-06-23T16:05:00.000-07:00</published><updated>2015-06-23T16:07:06.667-07:00</updated><title type='text'>Introducing PluotSorbet</title><content type='html'><a href="https://github.com/mozilla/pluotsorbet">PluotSorbet</a> is a <a href="https://en.wikipedia.org/wiki/Java_Platform,_Micro_Edition">J2ME</a>-compatible virtual machine written in JavaScript. Its goal is to enable users you run J2ME apps (i.e. <a href="https://en.wikipedia.org/wiki/MIDlet">MIDlets</a>) in web apps without a native plugin. It does this by interpreting Java bytecode and compiling it to JavaScript code. It also provides a virtual filesystem (via <a href="https://developer.mozilla.org/en-US/docs/Web/API/IndexedDB_API">IndexedDB</a>), network sockets (through the <a href="https://developer.mozilla.org/en-US/docs/Web/API/TCPSocket">TCPSocket API</a>), and other common J2ME APIs, like <a href="https://developer.mozilla.org/en-US/docs/Web/API/Contacts_API">Contacts</a>.<br /><br />The project reuses as much existing code as possible, to minimize its surface area and maximize its compatibility with other J2ME implementations. It incorporates the <a href="https://java.net/projects/phoneme">PhoneME</a> reference implementation, numerous tests from <a href="https://www.sourceware.org/mauve/">Mauve</a>, and a variety of JavaScript libraries (including <a href="http://www-cs-students.stanford.edu/%7Etjw/jsbn/">jsbn</a>, <a href="https://github.com/digitalbazaar/forge">Forge</a>, and <a href="https://github.com/eligrey/FileSaver.js">FileSaver.js</a>). The virtual machine is originally based on <a href="https://github.com/YaroslavGaponov/node-jvm">node-jvm</a>.<br /><br />PluotSorbet makes it possible to bring J2ME apps to Firefox OS. J2ME may be a moribund platform, but it still has <a href="http://netmarketshare.com/operating-system-market-share.aspx?qprid=9&amp;qpcustom=Java+ME&amp;qpcustomb=1">non-negligible market share</a>, not to mention a number of useful apps. So it retains residual value, which PluotSorbet can extend to Firefox OS devices.<br /><br />PluotSorbet is also still under development, with a variety of issues to address. To learn more about PluotSorbet, check out its <a href="https://github.com/mozilla/pluotsorbet/blob/master/README.md">README</a>, clone its <a href="https://github.com/mozilla/pluotsorbet">Git repository</a>, peruse its <a href="https://github.com/mozilla/pluotsorbet/issues">issue tracker</a>, and say hello to its developers in <a href="irc://irc.mozilla.org/pluotsorbet">irc.mozilla.org#pluotsorbet</a>!<br /><br /></content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/7658939959003799797/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=7658939959003799797' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/7658939959003799797'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/7658939959003799797'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2015/06/introducing-pluotsorbet.html' title='Introducing PluotSorbet'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/08518329693863067865</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-2146007198307190404</id><published>2014-03-28T16:58:00.002-07:00</published><updated>2014-03-28T16:58:42.947-07:00</updated><title type='text'>simplify asynchronous method declarations with Task.async()</title><content type='html'>In Mozilla code, <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">Task.spawn()</span> is becoming a common way to implement asynchronous operations, especially methods like the <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">greet</span> method in this <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">greeter</span> object:<br /><br /><div style="background: #202020; border-width: .1em .1em .1em .8em; border: solid gray; overflow: auto; padding: .2em .6em; width: auto;"><pre style="line-height: 125%; margin: 0;"><span style="color: #6ab825; font-weight: bold;">let</span> <span style="color: #d0d0d0;">greeter</span> <span style="color: #d0d0d0;">=</span> <span style="color: #d0d0d0;">{</span><br /> <span style="color: #d0d0d0;">message:</span> <span style="color: #ed9d13;">"Hello, NAME!"</span><span style="color: #d0d0d0;">,</span><br /> <span style="color: #d0d0d0;">greet:</span> <span style="color: #6ab825; font-weight: bold;">function</span><span style="color: #d0d0d0;">(name)</span> <span style="color: #d0d0d0;">{</span><br /> <span style="color: #6ab825; font-weight: bold;">return</span> <span style="color: #d0d0d0;">Task.spawn((</span><span style="color: #6ab825; font-weight: bold;">function</span><span style="color: #d0d0d0;">*()</span> <span style="color: #d0d0d0;">{</span><br /> <span style="color: #6ab825; font-weight: bold;">return</span> <span style="color: #d0d0d0;">yield</span> <span style="color: #d0d0d0;">sendGreeting(</span><span style="color: #6ab825; font-weight: bold;">this</span><span style="color: #d0d0d0;">.message.replace(</span><span style="color: #ed9d13;">/NAME/</span><span style="color: #d0d0d0;">,</span> <span style="color: #d0d0d0;">name));</span><br /> <span style="color: #d0d0d0;">}).bind(</span><span style="color: #6ab825; font-weight: bold;">this</span><span style="color: #d0d0d0;">);</span><br /> <span style="color: #d0d0d0;">})</span><br /><span style="color: #d0d0d0;">};</span><br /></pre></div><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">Task.spawn()</span> makes the operation logic simple, but the wrapper function and <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">bind()</span> call required to start the task on method invocation and bind its <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">this</span> reference make the overall implementation complex.<br /><br />Enter <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">Task.async()</span>.<br /><br />Like <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">Task.spawn()</span>, it creates a task, but it doesn't immediately start it. Instead, it returns an "async function" whose invocation starts the task, and the async function binds the task to its own <span style="font-family: &quot;Courier New&quot;,Courier,monospace;">this</span> reference at invocation time. That makes it simpler to declare the method:<br /><br /><!-- HTML generated using hilite.me --> <div style="background: #202020; border-width: .1em .1em .1em .8em; border: solid gray; overflow: auto; padding: .2em .6em; width: auto;"><pre style="line-height: 125%; margin: 0;"><span style="color: #6ab825; font-weight: bold;">let</span> <span style="color: #d0d0d0;">greeter</span> <span style="color: #d0d0d0;">=</span> <span style="color: #d0d0d0;">{</span><br /> <span style="color: #d0d0d0;">message:</span> <span style="color: #ed9d13;">"Hello, NAME!"</span><span style="color: #d0d0d0;">,</span><br /> <span style="color: #d0d0d0;">greet:</span> <span style="color: #d0d0d0;">Task.async(</span><span style="color: #6ab825; font-weight: bold;">function</span><span style="color: #d0d0d0;">*(name)</span> <span style="color: #d0d0d0;">{</span><br /> <span style="color: #6ab825; font-weight: bold;">return</span> <span style="color: #d0d0d0;">yield</span> <span style="color: #d0d0d0;">sendGreeting(</span><span style="color: #6ab825; font-weight: bold;">this</span><span style="color: #d0d0d0;">.message.replace(</span><span style="color: #ed9d13;">/NAME/</span><span style="color: #d0d0d0;">,</span> <span style="color: #d0d0d0;">name));</span><br /> <span style="color: #d0d0d0;">})</span><br /><span style="color: #d0d0d0;">};</span><br /></pre></div><br />With identical semantics:<br /><br /><div style="background: #202020; border-width: .1em .1em .1em .8em; border: solid gray; overflow: auto; padding: .2em .6em; width: auto;"><pre style="line-height: 125%; margin: 0;"><span style="color: #d0d0d0;">greeter.greet(</span><span style="color: #ed9d13;">"Mitchell"</span><span style="color: #d0d0d0;">).then((reply)</span> <span style="color: #d0d0d0;">=&gt;</span> <span style="color: #d0d0d0;">{</span> <span style="color: #d0d0d0;">...</span> <span style="color: #d0d0d0;">});</span> <span style="color: #999999; font-style: italic;">// behaves the same</span><br /></pre></div><br />(And it avoids a couple anti-patterns in the process.)<br /><br /><span style="font-family: &quot;Courier New&quot;,Courier,monospace;">Task.async()</span> is inspired by ECMAScript's <a href="http://wiki.ecmascript.org/doku.php?id=strawman:async_functions">Async Functions strawman proposal</a> and <a href="http://msdn.microsoft.com/en-us/library/hh191443.aspx">C#'s Async modifier</a> and was implemented in <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=966182">bug 966182</a>. It isn't limited to use in method declarations, although it's particularly helpful for them.<br /><br />Use it to implement your next asynchronous operation!<br /><br /></content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/2146007198307190404/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=2146007198307190404' title='2 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/2146007198307190404'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/2146007198307190404'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2014/03/simplify-asynchronous-method.html' title='simplify asynchronous method declarations with Task.async()'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/08518329693863067865</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>2</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-7603765594353319606</id><published>2014-03-27T13:14:00.000-07:00</published><updated>2014-03-27T13:14:20.326-07:00</updated><title type='text'>qualifications for leadership</title><content type='html'>I've been surprised by the negative reaction to Brendan's promotion by some of my fellow supporters of marriage equality. Perhaps I take it too much for granted that Mozillians recognize the diversity of their community in every possible respect, including politically and religiously, and that the <span style="font-style: italic;">only</span> thing we share in common is our commitment to Mozilla's mission and the principles for participation.<br /><br />Those principles are reflected in our <a href="http://www.mozilla.org/en-US/about/governance/policies/participation/">Community Participation Agreement</a>, to which Brendan has always shown fealty (since long before it was formalized, in my 15-year experience with him), and which could not possibly be clearer about the welcoming nature of Mozilla to all constructive contributors.<br /> <br />I know that marriage equality has been a long, difficult, and painful battle, the kind that rubs nerves raw and makes it challenging to show any charity to its opponents. But they aren't all bigots, and I take Brendan at his <a href="https://brendaneich.com/2014/03/inclusiveness-at-mozilla/">word and deed</a> that he's as committed as I am to the community's inclusive ideals (and the organization's employment policies).<br /> <br />As Andrew Sullivan eloquently states in his recent blog post on <a href="http://dish.andrewsullivan.com/2014/03/24/religious-belief-and-bigotry/">Religious Belief and Bigotry</a>:<br /><br /><div style="margin-left: 40px;">"Twenty years ago, I was confidently told by my leftist gay friends that Americans were all anti-gay bigots and would never, ever back marriage rights so I should stop trying to reason them out of their opposition. My friends were wrong. Americans are not all bigots. Not even close. They can be persuaded rather than attacked. And if we behave magnanimously and give maximal space for those who sincerely oppose us, then eventual persuasion will be more likely. And our victory more moral and more enduring." </div><br />I'm chastened to admit that I substantially shared his friends' opinion twenty years ago. But I'm happy to realize I was wrong. And perhaps Brendan will one day do the same. Either way, he qualifies to be a leader at any level in the Mozilla community (and organization), as do the many other Mozilla leaders whose beliefs undoubtedly differ sharply from my own.<br /><br /></content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/7603765594353319606/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=7603765594353319606' title='21 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/7603765594353319606'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/7603765594353319606'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2014/03/qualifications-for-leadership.html' title='qualifications for leadership'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/08518329693863067865</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='16' height='16' src='http://img2.blogblog.com/img/b16-rounded.gif'/></author><thr:total>21</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-4907835732389141704</id><published>2013-10-15T17:05:00.003-07:00</published><updated>2013-10-15T17:05:53.226-07:00</updated><title type='text'>from Webapp SDK to r2d2b2g, Firefox OS Simulator, and the App Manager</title><content type='html'>A little over a year ago, on August 31, 2012, I brainstormed the outline of a "Webapp SDK":<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://2.bp.blogspot.com/-qFEN48-NFBI/Ul2-QToFUkI/AAAAAAAAAEY/Pah7FtanWfo/s1600/2012-08-31+10.57.00.jpg" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" height="300" src="http://2.bp.blogspot.com/-qFEN48-NFBI/Ul2-QToFUkI/AAAAAAAAAEY/Pah7FtanWfo/s400/2012-08-31+10.57.00.jpg" width="400" /></a></div><br />That outline was the genesis for the <a href="https://hacks.mozilla.org/2012/10/r2d2b2g-an-experimental-prototype-firefox-os-test-environment/">r2d2b2g experiment</a>, which built the <a href="http://www.blueskyonmars.com/2012/11/08/r2d2b2g-is-becoming-the-firefox-os-simulator/">Firefox OS Simulator</a>, whose initial version hit the web on September 14, 2012 and which has gone through numerous iterations since then as we evaluated various features to enhance app development.<br /><br />And that experiment spurred Mozilla's <a href="https://wiki.mozilla.org/DevTools">Developer Tools group</a>, particularly its nascent <a href="https://wiki.mozilla.org/DevTools/AppTools">App Tools team</a>, to build Firefox's new App Manager, which landed last month and was <a href="https://hacks.mozilla.org/2013/10/introducing-the-firefox-os-app-manager/">introduced today on Hacks</a>!<br /><br />Despite the twisty passage from experiment to product, that initial outline bears a surprising resemblance to the App Manager feature set. The Manager checks off three of the four features on the outline's primary list—"start Gaia in B2G," "package app," and "test app in Gaia/B2G"—plus a few on its secondary list, like "debug from Firefox" and "test on mobile device," with "edit manifest in GUI" well underway over in <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=912912">bug 912912</a>. And the Simulator continues to provide B2G/Gaia via an easy-to-install addon that integrates with the Manager.<br /><br />Like any good product of a successful experiment, however, the Manager's reach has exceeded its progenitor's grasp! So it also gives you access to pre-installed apps, lets you take screenshots of device/Simulator screens, and will doubtless continue to sprout handy features to make app development great.<br /><br />So kudos to the folks who built it, and long live the App Manager!<br /><br /></content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/4907835732389141704/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=4907835732389141704' title='3 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/4907835732389141704'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/4907835732389141704'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2013/10/from-webapp-sdk-to-r2d2b2g-firefox-os.html' title='from Webapp SDK to r2d2b2g, Firefox OS Simulator, and the App Manager'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><media:thumbnail xmlns:media="http://search.yahoo.com/mrss/" url="http://2.bp.blogspot.com/-qFEN48-NFBI/Ul2-QToFUkI/AAAAAAAAAEY/Pah7FtanWfo/s72-c/2012-08-31+10.57.00.jpg" height="72" width="72"/><thr:total>3</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-4775473125409851813</id><published>2013-08-23T10:55:00.001-07:00</published><updated>2013-08-23T10:55:06.641-07:00</updated><title type='text'>fixing this morning's mach OS X psutil bustage</title><content type='html'>If mach is broken in your mozilla-central clone on Mac OS X this morning:<br> <blockquote><tt>08-23 10:20 &gt; ./mach build</tt><br> <tt>Error running mach:</tt><br> <br> <tt>&nbsp;&nbsp;&nbsp; ['build']</tt><br> <br> <tt>The error occurred in code that was called by the mach command. This is either</tt><br> <tt>a bug in the called code itself or in the way that mach is calling it.</tt><br> <br> <tt>You should consider filing a bug for this issue.</tt><br> <br> <tt>If filing a bug, please include the full output of mach, including this error</tt><br> <tt>message.</tt><br> <br> <tt>The details of the failure are as follows:</tt><br> <br> <tt>AttributeError: 'module' object has no attribute 'TCPS_ESTABLISHED'</tt><br> <br> <tt>&nbsp; File "/Users/myk/Mozilla/central/python/mozbuild/mozbuild/mach_commands.py", line 293, in build</tt><br> <tt>&nbsp;&nbsp;&nbsp; from mozbuild.controller.building import BuildMonitor</tt><br> <tt>&nbsp; File "/Users/myk/Mozilla/central/python/mozbuild/mozbuild/controller/building.py", line 22, in &lt;module&gt;</tt><br> <tt>&nbsp;&nbsp;&nbsp; import psutil</tt><br> <tt>&nbsp; File "/Users/myk/Mozilla/central/python/psutil/psutil/__init__.py", line 95, in &lt;module&gt;</tt><br> <tt>&nbsp;&nbsp;&nbsp; import psutil._psosx as _psplatform</tt><br> <tt>&nbsp; File "/Users/myk/Mozilla/central/python/psutil/psutil/_psosx.py", line 48, in &lt;module&gt;</tt><br> <tt>&nbsp;&nbsp;&nbsp; _TCP_STATES_TABLE = {_psutil_osx.TCPS_ESTABLISHED : CONN_ESTABLISHED,</tt><br> </blockquote> <br> Then you've been bit by the fix for <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=908296">bug 908296</a>. To resolve the bustage, run this command in your Hg clone:<br> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <blockquote>hg status -in python/psutil | xargs rm<br> </blockquote> <br> Or, if you've cloned the <a href="https://github.com/mozilla/mozilla-central">Git mirror</a>, run this instead:<br> <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> <blockquote>git clean -xf python/psutil<br> </blockquote> <br> </content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/4775473125409851813/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=4775473125409851813' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/4775473125409851813'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/4775473125409851813'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2013/08/fixing-this-mornings-mach-os-x-psutil.html' title='fixing this morning's mach OS X psutil bustage'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-7658176042227879683</id><published>2013-06-07T16:04:00.000-07:00</published><updated>2013-06-07T16:04:04.952-07:00</updated><title type='text'>64-bit Linux ADB for Simulator</title><content type='html'>Thanks to the efforts of new Mozilla intern <a href="https://github.com/bkase">Brandon Kase</a>, the <a href="https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/r2d2b2g-linux.xpi">latest preview build of Firefox OS Simulator for Linux</a> includes a 64-bit version of ADB, so you can push an app to an FxOS device from 64-bit Linux installations without any extra packages!<br /> <br /> Building it was tricky, because the Android SDK build scripts don't support that target. Brandon first tried simply specifying the target, which worked on an older version of ADB (1.0.24). But it failed on the latest version (1.0.31), which links with a bundled copy of libcrypto that includes 32-bit assembly.<br /> <br /> Ubuntu 13.04 (Raring) ships a 64-bit <a href="http://packages.ubuntu.com/raring/android-tools-adb">android-tools-adb package</a>, though, so we knew it could be done. And its <a href="http://packages.ubuntu.com/source/raring/android-tools">source package</a>'s build system is much simpler than the SDK's. We just needed a binary that works on distributions with older versions of glibc than Raring's 2.17. And one that doesn't depend on a specific version of libcrypto, which varies around the Linux world; whereas Raring's ADB executable appears to need the specific version that comes with that distribution.<br /> <br /> So Brandon modified the source package's Makefile to link libcrypto statically (note the absolute path to libcrypto.a, which may vary):<br /><blockquote class="tr_bq"> <tt>--- debian/makefiles/adb.mk&nbsp;&nbsp;&nbsp; 2013-03-26 14:15:41.000000000 -0700</tt><br /><tt> </tt><tt>+++ adb-static-crypto.mk&nbsp;&nbsp;&nbsp; 2013-06-06 16:51:52.794521267 -0700</tt><br /><tt> </tt><tt>@@ -40,15 +40,16 @@</tt><br /><tt> </tt><tt>&nbsp;CPPFLAGS+= -I.</tt><br /><tt> </tt><tt>&nbsp;CPPFLAGS+= -I../include</tt><br /><tt> </tt><tt>&nbsp;CPPFLAGS+= -I../../../external/zlib</tt><br /><tt> </tt><tt>+CPPFLAGS+= -I/usr/include/openssl</tt><br /><tt> </tt><tt>&nbsp;</tt><br /><tt> </tt><tt>-LIBS+= -lc -lpthread -lz -lcrypto</tt><br /><tt> </tt><tt>+LIBS+= -lc -lpthread -lz -ldl</tt><br /><tt> </tt><tt>&nbsp;</tt><br /><tt> </tt><tt>&nbsp;OBJS= $(SRCS:.c=.o)</tt><br /><tt> </tt><tt>&nbsp;</tt><br /><tt> </tt><tt>&nbsp;all: adb</tt><br /><tt> </tt><tt>&nbsp;</tt><br /><tt> </tt><tt>&nbsp;adb: $(OBJS)</tt><br /><tt> </tt><tt>-&nbsp;&nbsp;&nbsp; $(CC) -o $@ $(LDFLAGS) $(OBJS) $(LIBS)</tt><br /><tt> </tt><tt>+&nbsp;&nbsp;&nbsp; $(CC) -o $@ $(LDFLAGS) $(OBJS) /usr/lib/x86_64-linux-gnu/libcrypto.a $(LIBS)</tt><br /><tt> </tt><tt>&nbsp;</tt><br /><tt> </tt><tt>&nbsp;clean:</tt><br /><tt> </tt><tt>&nbsp;&nbsp;&nbsp;&nbsp; rm -rf $(OBJS) adb</tt></blockquote><br /> Then I copied the source package to my CentOS 16 build machine (which has glibc 2.12) and built it there. After which the resultant executable worked on all the distributions we tested: Ubuntu 13.04, Ubuntu 10.04, CentOS 16, and Arch Linux (kernel 3.9.3-1-ARCH).<br /> <br /> Presumably it will work on others too. But if it still doesn't work for you, <a href="https://github.com/mozilla/r2d2b2g/issues">let us know</a>!<br /> <br /> And if you just want the ADB executable, sans Simulator, <a href="https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/adb-1.0.31-linux64.zip">here it is</a>.<br /><br /></content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/7658176042227879683/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=7658176042227879683' title='2 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/7658176042227879683'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/7658176042227879683'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2013/06/64-bit-linux-adb-for-simulator.html' title='64-bit Linux ADB for Simulator'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>2</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-2950140535922521480</id><published>2012-10-02T12:08:00.001-07:00</published><updated>2012-10-02T12:13:24.657-07:00</updated><title type='text'>r2d2b2g implementation details</title><content type='html'>Over at Mozilla Hacks, I just <a href="https://hacks.mozilla.org/2012/10/r2d2b2g-an-experimental-prototype-firefox-os-test-environment/">blogged about r2d2b2g</a> (ratta-datta-batta-ga), an experimental prototype test environment for Firefox OS that makes it drop-dead simple to test your app in <a href="https://developer.mozilla.org/en-US/docs/Mozilla/Boot_to_Gecko/Using_the_B2G_desktop_client">B2G Desktop</a>.<br /><br />r2d2b2g is an addon, but it bundles <a href="https://ftp.mozilla.org/pub/mozilla.org/b2g/nightly/latest-mozilla-central/">B2G Desktop nightly builds</a>, which are native executables, and thus the addon is platform-specific, with packages available for <a href="https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/r2d2b2g-mac.xpi">Mac</a>, <a href="https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/r2d2b2g-linux.xpi">Linux 32-bit</a>, and <a href="https://ftp.mozilla.org/pub/mozilla.org/labs/r2d2b2g/r2d2b2g-windows.xpi">Windows</a> (caveat: B2G Desktop for Windows currently crashes on startup due to bug <strike><a href="https://bugzilla.mozilla.org/show_bug.cgi?id=794662">794662</a></strike> <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=795484">795484</a>).<br /><br />The packages are large, 50-60MB each, partly because of the executables, but mostly because they also bundle <a href="https://wiki.mozilla.org/Gaia">Gaia</a> profiles, including all default apps. (It's probably worth bundling a few of these, for demonstration purposes, but we could make the packages much smaller by removing the rest.)<br /><br />r2d2b2g uses the <a href="https://addons.mozilla.org/en-US/developers/builder">Add-on SDK</a> as its addon framework and relies on several third-party addon modules (<a href="https://github.com/ochameau/jetpack-subprocess">subprocess</a>, <a href="https://github.com/voldsoftware/menuitems-jplib">menuitems</a>) along with some Python utilities (<a href="https://github.com/mozilla/mozdownload">mozdownload</a>, <a href="https://github.com/mozilla/mozbase">mozbase</a>) to download and unpack B2G Desktop builds. Plus Gaia, although recent work to bundle Gaia profiles with B2G Desktop builds may break that dependency.<br /><br />I've demoed the project to a variety of folks over the last couple weeks, and I've received a bunch of positive feedback about it. B2G Desktop combines approachability with phoneliness and is the best existing test environment for Firefox OS. But its configuration is a challenge, and it provides no obvious affordances for installing and testing your own app. r2d2b2g shows that these problems are tractable (even if it doesn't yet solve them all) and demonstrates a promising product path.<br /><br />After seeing r2d2b2g, Kevin Dangoor drafted a <a href="https://docs.google.com/document/d/1OptOCWO4b_b1aa4Gtwr82_q-mW5ybteoWNpPAJUIFNk/edit">PRD for a Firefox OS Simulator</a> that I'll use to guide further development. Interested in participating? Clone the code from its <a href="https://github.com/mozilla/r2d2b2g">GitHub repository</a> and contribute your improvements!<br /><br /></content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/2950140535922521480/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=2950140535922521480' title='5 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/2950140535922521480'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/2950140535922521480'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2012/10/r2d2b2g-implementation-details.html' title='r2d2b2g implementation details'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>5</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-704490864096897779</id><published>2012-03-07T18:04:00.001-08:00</published><updated>2012-03-07T18:04:16.546-08:00</updated><title type='text'>Next/Previous Tab on Mac Consistent At Last</title><content type='html'>After blogging about the <a href="http://mykzilla.blogspot.com/2011/09/nextprevious-tab-keyboard-shortcuts-on.html">inconsistency of keyboard shortcuts for Next/Previous Tab on Mac</a> last year, I found out that Firefox, Thunderbird, and Komodo also support Command + Option + LeftArrow|RightArrow, and Adium has a General &gt; "Switch tabs with" pref that I can set to the same chord.<br> <br> (Later, I switched IM clients from Adium to InstantBird, which also supports that combination.)<br> <br> That left Terminal, which I couldn't figure out how to configure to support the same shortcut. Until now.<br> <br> I'm not sure if it's because I have since upgraded to Mac OS X 10.7 (Lion). I could've sworn I tried something like this back when I wrote that previous blog post, and it didn't work.<br> <ol> <li>Go to System Preferences &gt; Keyboard &gt; Keyboard Shortcuts &gt; Application Shortcuts.</li> <li>Press the + (plus) button.</li> <li>Select "Other..." from the Application menu and select Utilities &gt; Terminal from the file picker dialog.</li> <li>Enter "Select Next Tab" (without the quotes) into the Menu Title field.</li> <li>Focus the Keyboard Shortcut field and press Command + Option + RightArrow to set the keyboard shortcut, which will appear as <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> &#8997;&#8984;&#8594;.</li> <li>Press the Add button.</li> </ol> <p>Repeat steps 4-6 with "Select Previous Tab" and Command + Option + LeftArrow, which will appear as <meta http-equiv="content-type" content="text/html; charset=ISO-8859-1"> &#8997;&#8984;&#8592;.<br> </p> <p>Those shortcuts should now work in Terminal.<br> </p> <p>With this change, all five of my current primary productivity applications on Mac (Firefox, Thunderbird, Instantbird, Komodo, and Terminal) support a consistent pair of keyboard shortcuts for Next/Previous Tab, which are two of the most common commands I issue in all of those apps.<br> </p> <p>Woot!<br> <br> </p> </content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/704490864096897779/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=704490864096897779' title='2 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/704490864096897779'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/704490864096897779'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2012/03/nextprevious-tab-on-mac-consistent-at.html' title='Next/Previous Tab on Mac Consistent At Last'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>2</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-4717272844287397408</id><published>2012-03-07T13:46:00.001-08:00</published><updated>2012-03-07T13:46:45.454-08:00</updated><title type='text'>generating a fingerprint for an SSH key</title><content type='html'>After recently <a href="https://github.com/blog/1068-public-key-security-vulnerability-and-mitigation">discovering a security vulnerability</a> that allows an attacker to add an SSH key to a GitHub user account, GitHub is requiring all users to audit their SSH keys. Its <a href="https://github.com/settings/ssh/audit">audit page</a> lists one's keys by type and fingerprint, but it doesn't say how it generated the fingerprint or how to generate one for your local copy of a key to compare it with. Nor does it let you see the whole key.<br> <br> And since I don't generate such fingerprints very often, I didn't know how to do it. So I tried <tt>cksum</tt>, <tt>md5</tt>, and <tt>shasum</tt> on my Mac, but none of their checksums matched. Turns out the tool to use is <tt>ssh-keygen</tt>:<br> <br> <tt> &nbsp;&nbsp;&nbsp; ssh-keygen -l -f path/to/keyfile</tt><br> <br> </content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/4717272844287397408/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=4717272844287397408' title='2 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/4717272844287397408'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/4717272844287397408'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2012/03/generating-fingerprint-for-ssh-key.html' title='generating a fingerprint for an SSH key'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>2</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-3538011216013400890</id><published>2011-10-17T10:38:00.001-07:00</published><updated>2011-10-17T10:38:52.345-07:00</updated><title type='text'>Mozilla Status Board Text is Markdown</title><content type='html'>It isn't documented anywhere that I can find, but Benjamin Smedberg's handy <a href="http://benjamin.smedbergs.us/weekly-updates.fcgi/">Mozilla Status Board</a> tool parses status text as <a href="http://daringfireball.net/projects/markdown/">Markdown</a>, which is how I added a <b>Didn't</b> header to the <b>Done</b> section of my <a href="http://benjamin.smedbergs.us/weekly-updates.fcgi/user/mykmelez">status update</a> with all the things I planned to do last week but didn't make happen. (The <b>Done</b>, <b>Next</b>, and <b>Coordination</b> headers are all <b>H4</b>s, so I prepended four hash marks to <tt>#### <b>Didn't</b></tt> to make it the same size).<br> <br> (Note that <tt>[<a href="http://daringfireball.net/projects/markdown/basics">Markdown-style links</a>](<a class="moz-txt-link-freetext" href="http://daringfireball.net/projects/markdown/basics">http://daringfireball.net/projects/markdown/basics</a>)</tt> don't work and cause the entire section in which they appear to remain unparsed. However angle-bracketed URLs, as recommended by <tt><a href="http://labs.apache.org/webarch/uri/rfc/rfc3986.html#delimiting">RFC 3986</a> <a class="moz-txt-link-rfc2396E" href="http://labs.apache.org/webarch/uri/rfc/rfc3986.html#delimiting">&lt;http://labs.apache.org/webarch/uri/rfc/rfc3986.html#delimiting&gt;</a></tt>, work when added to the ends of lines. And "<tt>bug ###</tt>" references are auto-linkified.)<br> <br> </content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/3538011216013400890/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=3538011216013400890' title='1 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/3538011216013400890'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/3538011216013400890'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2011/10/mozilla-status-board-text-is-markdown.html' title='Mozilla Status Board Text is Markdown'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>1</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-3002229182794927051</id><published>2011-09-16T08:32:00.001-07:00</published><updated>2011-09-16T08:32:13.528-07:00</updated><title type='text'>to all the bugs I've filed before</title><content type='html'>The <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=20142">first bug I filed</a> was marked as <i>duplicate</i>; the <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=20187">second</a> was <i>worksforme</i> (although Chris Petersen could reproduce it before he couldn't anymore); and the <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=24840">third</a> was <i>invalid</i> (it was the spec, not the code, that was errant). The <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=25082">fourth</a> is the first that was <i>fixed</i>.<br> <br> </content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/3002229182794927051/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=3002229182794927051' title='2 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/3002229182794927051'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/3002229182794927051'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2011/09/to-all-bugs-ive-filed-before.html' title='to all the bugs I've filed before'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>2</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-2481752447493541518</id><published>2011-09-09T17:01:00.000-07:00</published><updated>2011-09-09T17:00:36.580-07:00</updated><title type='text'>"Next/Previous Tab" Keyboard Shortcuts on Windows</title><content type='html'>On my Windows laptop, I use the following four programs with tabbed interfaces on a regular basis:<br> <ul> <li>Firefox</li> <li>Thunderbird</li> <li>Instantbird</li> <li>Komodo IDE</li> </ul> (I'd love to have tabs in my Windows terminal app of choice, <a href="http://code.google.com/p/mintty/">Mintty</a>, but its developer <a href="http://code.google.com/p/mintty/issues/detail?id=8">thinks tabs should be implemented at the window manager level</a>.)<br> <br> Unlike <a href="http://mykzilla.blogspot.com/2011/09/nextprevious-tab-keyboard-shortcuts-on.html">on my Mac</a>, all those programs implement the same keyboard shortcut for switching to the previous/next tab, and it's a simple one with just a two-key chord: Control + PageUp / PageDown.<br> <br> Ha!<br> <br> </content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/2481752447493541518/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=2481752447493541518' title='8 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/2481752447493541518'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/2481752447493541518'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2011/09/nextprevious-tab-keyboard-shortcuts-on_09.html' title='"Next/Previous Tab" Keyboard Shortcuts on Windows'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>8</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-1639696569383368856</id><published>2011-09-08T17:03:00.001-07:00</published><updated>2011-09-08T17:03:31.723-07:00</updated><title type='text'>"Next/Previous Tab" Keyboard Shortcuts on Mac</title><content type='html'>On my Mac, I use the following five programs with tabbed interfaces on a regular basis:<br> <ul> <li>Firefox</li> <li>Thunderbird</li> <li>Adium</li> <li>Terminal</li> <li>Komodo IDE</li> </ul> <br> And those programs implement the following five different keyboard shortcuts for switching to the previous/next tab:<br> <ul> <li>Control + PageUp / PageDown (Firefox, Thunderbird)<br> </li> <li>Command + LeftArrow / RightArrow (Adium)</li> <li>Command + PageUp / PageDown (Komodo IDE)</li> <li>Command + Shift + [ / ] (Terminal)</li> <li>Command + Shift + LeftArrow / RightArrow (Terminal)</li> </ul> Hrm.<br> <br> </content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/1639696569383368856/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=1639696569383368856' title='6 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/1639696569383368856'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/1639696569383368856'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2011/09/nextprevious-tab-keyboard-shortcuts-on.html' title='"Next/Previous Tab" Keyboard Shortcuts on Mac'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>6</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-4435398397928021957</id><published>2011-09-07T14:25:00.000-07:00</published><updated>2011-09-20T11:37:47.397-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="jetpack"/><title type='text'>gitflow vs. the SDK</title><content type='html'><a href="http://nvie.com/posts/a-successful-git-branching-model/">gitflow</a> is a model for developing and shipping software using <a href="http://git-scm.com/">Git</a>. <a href="https://addons.mozilla.org/en-US/developers/builder">Add-on SDK</a> uses Git, and <a href="https://wiki.mozilla.org/Jetpack/Development_Process">it too has a model</a>, which is similar to gitflow in some ways and different in others. Here's a comparison of the two and some thoughts on why they vary.<br /><br />First, some similarities: both models use multiple branches, including an ongoing branch for general development and another ongoing branch that is always ready for release (their names vary, but that's a trivial difference). Both also permit development on temporary feature (topic) branches and utilize a branch for stabilization of the codebase leading up to a release. And both accommodate the occasional hotfix release in similar ways.<br /><br />(Aside: gitflow appears to encourage feature branches, but I tend to agree with <a href="http://martinfowler.com/bliki/FeatureBranch.html">Martin Fowler</a> through <a href="http://pauljulius.com/blog/2009/09/03/feature-branches-are-poor-mans-modular-architecture/">Paul Julius</a> that continuously integrating with a central development branch is preferable.)<br /><br />Second, some differences: the SDK uses a single ongoing stabilization branch, while gitflow uses multiple short-lived stabilization branches, one per release. And in the SDK, stabilization fixes land on the development branch and then get cherry-picked to the stabilization branch; whereas in gitflow, stabilization fixes land on the stabilization branch and then get merged to the development branch.<br /><br />(Also, the SDK releases on a regular time/quality-driven "train" schedule similar to <a href="http://mozilla.github.com/process-releases/draft/development_overview/">Firefox's</a>, while gitflow may anticipate an irregular feature/quality-driven release schedule, although it can be applied to projects with train schedules, like <a href="http://lloyd.io/applying-gitflow">BrowserID</a>.)<br /><br />A benefit of gitflow's approach to stabilization is that its change graph includes only distinct changes, whereas cherry-picking adds duplicate, semi-associated changes to the SDK's graph. However, a downside of gitflow's approach is that developers must attend to where they land changes, whereas SDK developers always land changes on its development branch, and its release manager takes on the chore of getting those changes onto the stabilization branch.<br /><br />(It isn't clear what happens in gitflow if a change lands on the development branch while a release is being stabilized and afterward is identified as being wanted for the release. Perhaps it gets cherry-picked?)<br /><br />Overall, these models seem fairly similar, and it wouldn't be too hard to make the SDK's be essentially gitflow. We would just need to stipulate that developers land stabilization fixes on the stabilization branch, and the release manager's job would then be to merge that branch back to the development branch periodically instead of cherry-picking in the other direction.<br /><br />However, it isn't clear to me that such a change would be preferable. What do you think?</content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/4435398397928021957/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=4435398397928021957' title='5 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/4435398397928021957'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/4435398397928021957'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2011/09/gitflow-vs-sdk.html' title='gitflow vs. the SDK'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>5</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-8020854027593557159</id><published>2011-08-21T22:51:00.000-07:00</published><updated>2011-09-20T11:38:43.594-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="jetpack"/><title type='text'>Administer Git? Get a job!</title><content type='html'>As I <a href="http://mykzilla.blogspot.com/2011/08/why-add-on-sdk-doesnt-land-in-mozilla.html">mentioned recently</a>, <a href="http://git-scm.com/">Git</a> (on <a href="https://github.com/">GitHub</a>) has become a popular VCS for Mozilla-related projects.<br> <br> GitHub is a fantastic tool for collaboration, and the site does a great job running a Git server, but given the importance of the VCS, and because Mozilla's automated test machines don't have access to servers outside the Mozilla firewall, Mozilla should <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=528360">run its own Git server</a> (that syncs with GitHub, so developers can continue to use that site for collaboration).<br> <br> Unfortunately, the organization doesn't have a great deal of in-house Git server administration experience, but we're <a href="http://hire.jobvite.com/CompanyJobs/Careers.aspx?c=qpX9Vfwa&amp;cs=9Kt9Vfw1&amp;page=Job%20Description&amp;j=oIfPVfwr">hiring systems administrators</a>, so if you grok Git hosting and meet the other requirements, <a href="http://hire.jobvite.com/CompanyJobs/Careers.aspx?c=qpX9Vfwa&amp;page=Apply&amp;j=oIfPVfwr">send in your resume</a>!<br> <br> </content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/8020854027593557159/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=8020854027593557159' title='5 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/8020854027593557159'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/8020854027593557159'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2011/08/administer-git-get-job.html' title='Administer Git? Get a job!'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>5</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-1307851753993957811</id><published>2011-08-11T13:33:00.000-07:00</published><updated>2011-09-20T11:38:43.545-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="jetpack"/><title type='text'>Why the Add-on SDK Doesn't "Land in mozilla-central"</title><content type='html'>Various Mozillians sometimes suggest that the Add-on SDK should "land in mozilla-central" and wonder why it doesn't. Here's why.<br /><br /><br />The Add-on SDK depends on features of Firefox (and Gecko), and the SDK's development process synchronizes its release schedule with Firefox's. Nevertheless, the SDK isn't a component of Firefox, it's a distinct product with its own codebase, development process, and release schedule.<br /><br />Mozilla makes multiple products that interact with Firefox (addons.mozilla.org, a.k.a. AMO, is another), and distinct product development efforts should generally utilize separate code repositories, to avoid contention between the projects regarding tree management, the stages of the software development lifecycle (i.e. when which branch is in alpha, beta, etc.), and the schedules for merging between branches.<br /><br />There can be exceptions to that principle, for products that share a bunch of code, use the same development process, and have the same release schedule (cf. the Firefoxes for desktop and mobile). But the SDK is not one of those exceptions.<br /><br /><br />It shares no code with Firefox. Its process utilizes one fewer branch and six fewer weeks of development than the Firefox development process, to minimize the burden of branch management and stabilization build testing on its much smaller development team and testing community. And it merges its branches and ships its releases two weeks before Firefox, to give AMO and addon developers time to update addons for each new version of the browser.<br /><br />Living in its own repository makes it possible for the SDK to have these differences in its process, and it also makes it possible for us to change the process in the future, for example to move up the branch/release dates one week, if we discover that AMO and addon developers would benefit from three weeks of lead time; or to ship twice as frequently, if we determine that doing so would get APIs for new Firefox features into developers' hands faster.<br /><br />Finally, the Jetpack project has a vibrant community of contributors (including both organization staff and volunteers) who strongly prefer contributing via Git and <a href="https://github.com/">GitHub</a>, because they find it easier, more efficient, and more enjoyable, and for whom working in mozilla-central would mean taking too great a hit on their productivity, passion, and participation.<br /><br />Mozilla Labs innovates not only on features and user experience but also on development process and tools, and while Jetpack didn't lead the way to GitHub, we were a fast follower once early experiments validated its benefits. And our experience since then has only confirmed our decision, as GitHub has proven to be a fantastic tool for branch management, code review/integration, and other software development tasks.<br /><br />Other Mozillians agree: there are now almost two hundred members and over one hundred repositories (not counting forks) in the Mozilla organization on GitHub, with major initiatives like <a href="https://github.com/mozilla/openwebapps">Open Web Apps</a> and <a href="https://github.com/mozilla/browserid">BrowserID</a> being hosted there, not to mention all the Mozilla projects in user repositories, including <a href="https://github.com/graydon/rust">Rust</a> and <a href="https://github.com/jbalogh/zamboni">Zamboni</a>.<br /><br /><br />Even if we don't make mozilla-central the canonical repository for SDK development, however, we could still periodically drop a copy of the SDK source against which Firefox changes should be tested into mozilla-central. And doing so would theoretically make it easier for Firefox developers to run SDK tests when they discover that a Firefox change breaks the SDK, because they wouldn't have to get the SDK first.<br /><br />But the benefit to Firefox developers is minimal. Currently, we periodically drop a reference to the SDK revision against which Firefox changes should be tested, and developers have to do the following to initiate testing:<br /><br /><pre>&nbsp; wget -i testing/jetpack/jetpack-location.txt -O addon-sdk.tar.bz2
|
|
<br />&nbsp; tar xjf addon-sdk.tar.bz2
|
|
<br />&nbsp; cd addon-sdk-[revision]
|
|
<br />&nbsp; source bin/activate
|
|
<br />&nbsp; cfx testall --binary path/to/Firefox/build
|
|
<br /></pre><br />We can simplify this to:<br /><br /><pre>&nbsp; testing/jetpack/clone
|
|
<br />&nbsp; cd addon-sdk
|
|
<br />&nbsp; source bin/activate
|
|
<br />&nbsp; cfx testall --binary path/to/Firefox/build
|
|
<br /></pre><br />Whereas if we dropped the source instead of just a reference to it, it would instead be the only slightly simpler: <br /><br /><pre>&nbsp; cd testing/jetpack/addon-sdk
|
|
<br />&nbsp; source bin/activate
|
|
<br />&nbsp; cfx testall --binary path/to/Firefox/build
|
|
<br /></pre><br />Either of which can be abstracted to a single make target.<br /><br />But if we were to drop source instead of a reference thereto, the drops would be larger and riskier changes. And test automation would still need to be updated to support Git (or at least continue to use brittle Git -&gt; Mercurial mirroring), in order to run tests on SDK changes, which periodic source drops do not address.<br /><br /><br />Now, this doesn't mean that no SDK code will ever land in mozilla-central.<br /><br />Various folks have discussed integrating parts of the SDK into core Firefox<span class="st">—</span>including stable API implementations, the module loader, and possibly the bootstrapper<span class="st">—</span>to reduce the size of addon packages, improve addon startup times, and decrease addon memory consumption. I have written a very preliminary draft of a <a href="https://wiki.mozilla.org/Features/Jetpack/Land_Parts_of_Add-on_SDK_In_Core">feature page describing this work</a>, although I do not think it is a high priority at the moment, relative to the other priorities identified in the <a href="https://wiki.mozilla.org/Jetpack/Roadmap">Jetpack roadmap</a>.<br /><br />And Dietrich Ayala recently suggested <a href="http://groups.google.com/group/mozilla.dev.planning/browse_frm/thread/2b57ebe15aad4130">integrating the SDK into core Firefox for use by core features</a>, by which he presumably also means the API implementations/module loader/bootstrapper rather than the command-line tool for testing and packaging addons.<br /><br />Nevertheless, I am (and, I suspect, the whole Jetpack team is) even open to discussing integration of the command-line tool (or its replacement by a graphical equivalent), merging together the two products, and erasing the distinction between them, just as Firefox ships with core features for web development.&nbsp; We've even drafted a <a href="https://wiki.mozilla.org/Features/Jetpack/Add-on_SDK_as_an_Addon">feature page for converting the SDK into an addon</a>, which is a big step in that direction.<br /><br />But until that happens, farther on up the road, the SDK is its own product that we develop with its own process and ship on its own schedule. And it has good reason to live in its own repository, and a Git one at that, as do the many (and growing number of) other Mozilla projects using similar processes and tools, which our community-wide development, collaboration, and testing infrastructure must evolve to accommodate.</content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/1307851753993957811/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=1307851753993957811' title='6 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/1307851753993957811'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/1307851753993957811'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2011/08/why-add-on-sdk-doesnt-land-in-mozilla.html' title='Why the Add-on SDK Doesn't "Land in mozilla-central"'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>6</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-6715608859512848344</id><published>2010-12-02T11:07:00.001-08:00</published><updated>2011-09-20T11:38:43.568-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="jetpack"/><title type='text'>SDK Training and More at Add-on-Con</title><content type='html'><div class="moz-text-html" lang="x-western">Next Wednesday, December 8, I'll be at <a href="http://addoncon.com/">Add-on-Con</a>.<br> <br> In the morning, I'll conduct a training session introducing Mozilla's new Add-on SDK, which makes it faster and easier to build Firefox add-ons. Afterwards, I'll be around and about to discuss add-ons and answer questions about the SDK and add-on development generally.<br> <br> Lots of other Mozilla folks will also be on hand over the course of the two-day conference, including <a href="http://www.oxymoronical.com/">Dave Townsend</a>, Jorge Villalobos, <a href="http://jboriss.wordpress.com/">Jeniffer Boriss</a>, <a href="http://starkravingfinkle.org/blog/">Mark Finkle</a>, and <a href="http://blog.fligtar.com/">Justin Scott</a>. A rockin' time should be had by all. Join us!<br> <br> </div> </content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/6715608859512848344/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=6715608859512848344' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/6715608859512848344'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/6715608859512848344'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2010/12/sdk-training-and-more-at-add-on-con.html' title='SDK Training and More at Add-on-Con'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-1323551422046235302</id><published>2010-11-27T20:47:00.001-08:00</published><updated>2011-09-20T11:38:43.550-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="jetpack"/><title type='text'>Further Adventures In Git(/Hub)ery</title><content type='html'><div class="moz-text-html" lang="x-western"> This evening I decided to check if there were any outstanding pull requests for the SDK repository (to which I haven't been paying attention).<br> <br> There were! The oldest was <a href="https://github.com/mozilla/addon-sdk/pull/29">pull request 29</a> from Thomas Bassetto, which contains two small fixes (<a href="https://github.com/tbassetto/addon-sdk/commit/8268334070d03a896d5c006d1b4db94d4cb44b17">first</a>, <a href="https://github.com/tbassetto/addon-sdk/commit/666ad7a99e05e338348dfc579d5b1f75e8d3bb1b">second</a>) to the docs.<br> <br> So I fetched the branch of his fork in which the changes reside:<br> <br> <blockquote><tt>$ git fetch <a class="moz-txt-link-freetext" href="https://github.com/tbassetto/addon-sdk.git">https://github.com/tbassetto/addon-sdk.git</a> master</tt><br> </blockquote> <br> But that branch (and the fork in general) is a few weeks out-of-date, so "<tt>git diff HEAD FETCH_HEAD</tt>" showed a bunch of changes, and it was unclear how painful the merge would be.<br> <br> Thus I decided to try cherry-picking the changes, my first time using "<tt>git cherry-pick</tt>".<br> <br> The first one went great:<br> <br> <blockquote><tt>$ git cherry-pick 8268334070d03a896d5c006d1b4db94d4cb44b17</tt><br> <tt>Finished one cherry-pick.</tt><br> <tt>[master ceadb1f] Fixed an internal link in the widget doc</tt><br> <tt>&nbsp;1 files changed, 1 insertions(+), 1 deletions(-)</tt><br> </blockquote> <br> Except that I realized afterward I hadn't added "r,a=myk" to the commit message. So I tried "<tt>git commit --amend</tt>" for the first time, which worked just fine:<br> <br> <blockquote><tt>$ git commit --amend</tt><br> <tt>[master 2d674a6] Fixed an internal link in the widget doc; r,a=myk</tt><br> <tt>&nbsp;1 files changed, 1 insertions(+), 1 deletions(-)</tt><br> </blockquote> <br> Next time I'll remember to use the "<tt>--edit</tt>" flag to "<tt>git cherry-pick</tt>", which lets one "edit the commit message prior to committing."<br> <br> The second cherry-pick was more complicated, because I only wanted one of the two changes in the commit (in <a href="https://github.com/tbassetto/addon-sdk/commit/666ad7a99e05e338348dfc579d5b1f75e8d3bb1b#commitcomment-204023">my review</a>, I had identified the second change as unnecessary); and, as it turned out, also because there was a merge conflict with other commits.<br> <br> I started by cherry-picking the commit with the "<tt>--no-commit</tt>" option (so I could remove the second change):<br> <br> <blockquote><tt>$ git cherry-pick --no-commit 666ad7a99e05e338348dfc579d5b1f75e8d3bb1b</tt><br> <tt>Automatic cherry-pick failed.&nbsp; After resolving the conflicts,</tt><br> <tt>mark the corrected paths with 'git add &lt;paths&gt;' or 'git rm &lt;paths&gt;' and commit the result.</tt><br> <tt>When commiting, use the option '-c 666ad7a' to retain authorship and message.</tt><br> </blockquote> <br> The conflict was trivial, and I knew where it was, so I resolved it manually (instead of trying "<tt>git mergetool</tt>" for the first time), removed the second change, added the merged file, and committed the result, using the "<tt>-c</tt>" option to preserve the original author and commit message while allowing me to edit the message to add "r,a=myk":<br> <br> <blockquote><tt>$ git add packages/addon-kit/docs/request.md</tt><br> <tt>$ git commit -c 666ad7a</tt><br> <tt>[master 774d1cb] Completed the example in the Request module documentation; r,a=myk</tt><br> <tt>&nbsp;1 files changed, 1 insertions(+), 0 deletions(-)</tt><br> </blockquote> <br> Then I used "<tt>gitg</tt>" and "<tt>git log master ^upstream/master</tt>" to verify that the commits looked good to go, after which I pushed them:<br> <br> <blockquote><tt>$ git push upstream master</tt><br> <tt>[git's standard obscure and disconcerting gobbledygook]</tt><br> </blockquote> <br> Finally, I closed the pull request with <a href="https://github.com/mozilla/addon-sdk/pull/29#issuecomment-570630">this comment</a> that summarized what I did and provided links to the cherry-picked commits.<br> <br> It would have been nice if the cherry-picked commit that didn't have merge conflicts (and which I didn't change in the process of merging) had kept its original commit ID, but I sense that that is somehow a fundamental violation of the model.<br> <br> It would also have been nice if the cherry-picked commit messages had been automatically annotated with references to the original commits.<br> <br> But overall the process seemed pretty reasonable, it was fairly easy to do what I wanted and recover from mistakes, and the author, committer, reviewer, and approver are clearly indicated in the cherry-picked commits (<a href="https://github.com/mozilla/addon-sdk/commit/2d674a6ea84d3be88b5365b2d24b994297a60d7a">first</a>, <a href="https://github.com/mozilla/addon-sdk/commit/774d1cbf49e152a030a0bf6cbde7b4139c8c3f49">second</a>).<br> <br> [Also <a href="http://groups.google.com/group/mozilla-labs-jetpack/browse_thread/thread/430750c65fe80231">posted to the discussion group</a>.]<br> <br> </div> </content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/1323551422046235302/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=1323551422046235302' title='3 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/1323551422046235302'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/1323551422046235302'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2010/11/further-adventures-in-githubery.html' title='Further Adventures In Git(/Hub)ery'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>3</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-7960433840999647174</id><published>2010-11-27T20:39:00.001-08:00</published><updated>2011-09-20T11:38:43.583-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="jetpack"/><title type='text'>More Git/Hub Workflow Experiences</title><content type='html'>After posting about my <a href="http://mykzilla.blogspot.com/2010/11/github-workflow-experiences.html">first Git/Hub workflow experiences</a>, I got lots of helpful input from various folks, particularly Erik Vold, Irakli Gozalishvili, and Brian Warner, which led me to refine my process for handling pull requests:<br /><br /><ol><li>From the "how to merge this pull request" section of the pull request page (f.e. <a href="https://github.com/mozilla/addon-sdk/pull/43">pull request 34</a>), copy the command from step two, but change the word "pull" to "fetch" to fetch the remote branch containing the changes without also merging it:<br /><br /><code>git fetch <a class="moz-txt-link-freetext" href="https://github.com/toolness/jetpack-sdk.git">https://github.com/toolness/jetpack-sdk.git</a> bug-610507<br /><br /></code></li><li>Use the magic FETCH_HEAD reference to the last fetched branch to verify that the set of changes is what you expect:<br /><br /><tt>git diff </tt><tt>HEAD </tt><tt>FETCH_HEAD</tt><br /><br />(The exact syntax here may need some work; HEAD..FETCH_HEAD? three dots?)<br /><br /></li><li>Merge the remote branch into your local branch with a custom commit message:<br /><br /><tt>git merge FETCH_HEAD --no-ff -m"bug 610507: get rid of the nsjetpack package; r=myk"</tt><br /><br /></li><li>Push the changes upstream:<br /><br /><tt>git push upstream master</tt><br /></li></ol><br />I like this set of commands because it doesn't require me to add a remote, I can copy/paste the fetch command from GitHub (being careful not to issue the pull before I change it to a fetch), and I always type the same FETCH_HEAD reference to the remote branch in step three.<br /><br />However, I wish the <a href="https://github.com/mozilla/addon-sdk/commit/0e23d1c1555d5de228ed7ad62c8715e2775d2390">merge commit page</a> explicitly referenced the <a href="https://github.com/mozilla/addon-sdk/commit/68b6e306dfeccef103b071e0812dc3a375830ac0">specific</a> <a href="https://github.com/mozilla/addon-sdk/commit/715cb47c720bcdd11846cae6c6cab325bb1a982b">commits</a> that were merged. It does mention that it's a branch merge, it isn't obvious how to get from that page to the pages for the commits I merged from the branch.<br /><br />"<tt>git log --oneline --graph</tt>", <tt>gitg</tt>, and <tt>gitk</tt> do give me that information, though, so I'm ok on the command line, anyway.<br /><br />[More discussion can be found in the <a href="http://groups.google.com/group/mozilla-labs-jetpack/browse_thread/thread/2c6cb3e7f3bec468">discussion group thread</a>.]</content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/7960433840999647174/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=7960433840999647174' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/7960433840999647174'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/7960433840999647174'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2010/11/more-github-workflow-experiences.html' title='More Git/Hub Workflow Experiences'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-7037189428773681360</id><published>2010-11-12T18:55:00.000-08:00</published><updated>2011-09-20T11:38:43.577-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="jetpack"/><title type='text'>Git/Hub Workflow Experiences</title><content type='html'><div class="moz-text-html" lang="x-western">The Jetpack project recently migrated its SDK repository to Git (hosted on GitHub), and we've been working out changes to the bug/review/commit workflow that GitHub's tools enable (specifically, pull requests).</div><div class="moz-text-html" lang="x-western">&nbsp;</div><div class="moz-text-html" lang="x-western">Here are some of my initial experiences and my thoughts on them (which I've also <a href="http://groups.google.com/group/mozilla-labs-jetpack/browse_thread/thread/2c6cb3e7f3bec468">posted to the Jetpack discussion group</a>).</div><div class="moz-text-html" lang="x-western">&nbsp;</div><div class="moz-text-html" lang="x-western"> </div><div class="moz-text-html" lang="x-western"> Warning: Git wonkery ahead, with excruciating details. I would not want to read this post. I recommend you skip it. ;-)<br /><br /><br /><span style="font-size: large;"><b> Part 1: Wherein I Handle My First Pull Request</b></span><br /><br />To fix some test failures, Atul submitted <a href="https://github.com/mozilla/addon-sdk/pull/33">GitHub pull request 33</a>, I reviewed the changes (comprising <a href="https://github.com/toolness/jetpack-sdk/commit/97619b0b25554712756827de883883c9b810319d">two</a> <a href="https://github.com/toolness/jetpack-sdk/commit/405390a586f6c09bad2b26183fe2925d09bcd52b">commits</a>) on GitHub, and then I pushed them to the canonical repository via the following set of commands:<br /><ol><li>git checkout -b toolness-<span class="commit-ref from">4.0b7-bustage-fixes</span> master</li><li>git pull <a class="moz-txt-link-freetext" href="https://github.com/toolness/jetpack-sdk.git">https://github.com/toolness/jetpack-sdk.git</a> <span class="commit-ref from">4.0b7-bustage-fixes</span></li><li>git checkout master</li><li>git merge toolness-<span class="commit-ref from">4.0b7-bustage-fixes</span></li><li>git push upstream master</li></ol><br />That landed the <a href="https://github.com/mozilla/addon-sdk/commit/97619b0b25554712756827de883883c9b810319d">two</a> <a href="https://github.com/mozilla/addon-sdk/commit/405390a586f6c09bad2b26183fe2925d09bcd52b">commits</a> in the canonical repository, but it isn't obvious that they were related (i.e. part of the same pull request), that I was the one who reviewed them, or that I was the one who pushed them.<br /><br /><br /><span style="font-size: large;"><b>Part 2: Wherein I Handle My Second Pull Request</b></span><br /><br />Thus, for the fix for <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=611042">bug 611042</a>, for which Atul submitted <a href="https://github.com/mozilla/addon-sdk/pull/34">GitHub pull request 34</a>, I again reviewed the changes (also comprising <a href="https://github.com/toolness/jetpack-sdk/commit/5e6ca0e1834e65623f6ac87d3828965da420847c">two</a> <a href="https://github.com/toolness/jetpack-sdk/commit/1ab9c78c94fb08610460ad19fd763a7402fc233c">commits</a>) on GitHub, but then I pushed them to the <a href="https://github.com/mozilla/addon-sdk">canonical repository</a> via this different set of commands (after discussion with Atul and Patrick Walton of the Rust team):<br /><ol><li>git checkout -b toolness-bug-611042 master</li><li>git pull <a class="moz-txt-link-freetext" href="https://github.com/toolness/jetpack-sdk.git">https://github.com/toolness/jetpack-sdk.git</a> bug-611042</li><li>(There might have been something else here, since the pull request resulted in a merge; I don't quite remember.)<br /></li><li>git checkout master</li><li>git merge --no-ff --no-commit toolness-bug-611042</li><li>git commit --signoff -m "bug 611042: remove request.response.xml for e10s compatibility; r=myk" --author "atul"</li><li>git push upstream master</li></ol><br />Because Atul's pull request was no longer against the tip (since I had just merged those previous changes), when I pulled the remote bug-611042 branch into my local toolness-bug-611042 branch (step 2), I had to merge his changes, which resulted in a <a href="https://github.com/mozilla/addon-sdk/commit/6a3c9e2a614f29b61e580a7a7619f91dd1306eea">merge commit</a>.<br /><br />Merging the changes to my local master with "--no-ff" and "--no-commit" (step 5) then allowed me to commit the merge to my master branch manually (step 6), resulting in another <a href="https://github.com/mozilla/addon-sdk/commit/9f202a3003cddace040bc695ab7137d4a31051ec">merge commit</a>.<br /><br />For the second merge commit, I specified "--signoff", which added "Signed-off-by: Myk Melez <a class="moz-txt-link-rfc2396E" href="mailto:myk@mozilla.org"><myk@mozilla.org></myk@mozilla.org></a>" to the commit message; crafted a custom commit message that included "r=myk"; and specified '--author "atul"', which made Atul the author of the merge.<br /><br />I dislike having the former merge commit in history, since it's extraneous, unuseful details about how I did the merging locally before I pushed to the canonical repository. I'm not sure how to avoid it, though.<br /><br />On the other hand, I like having the latter merge commit in history, since it provides context for Atul's <a href="https://github.com/mozilla/addon-sdk/commit/5e6ca0e1834e65623f6ac87d3828965da420847c">two</a> <a href="https://github.com/mozilla/addon-sdk/commit/1ab9c78c94fb08610460ad19fd763a7402fc233c">commits</a>: the bug number, the fact that the changes were reviewed, and a commit message that describes the changes as a whole.<br /><br />I'm ambivalent about --signoff vs. adding "r=myk" to the commit message, as they seem equivalentish, with --signoff being more explicit (so in theory it might form part of an enlightened workflow in the future), while "r=myk" is simpler.<br /><br />And I dislike having made Atul the author of the merge, since it's incorrect: he wasn't the author of the merge, he was only the author of the changes (for which he is correctly credited). And if the merge itself caused problems (f.e. I accidentally backed out other recent changes in the process), I would be the one responsible for fixing those problems, not Atul.<br /><br /><br /><span style="font-size: large;"><b>Part 3: Pushing Patches</b></span><br /><br />In addition to pull requests, one can also contribute via patches. I've pushed a few of these via something like the following set of commands:<br /><ol><li>git apply patch.diff</li><li>git commit -a -m "bug <number>: <description changes="" of="">; r=myk" --author "<author name="">"<br /></author></description></number></li><li>git push upstream master</li></ol>That results in a commit like <a href="https://github.com/mozilla/addon-sdk/commit/026b4e8e78336c2dbbf30edb14e5db78ca4afb21">this one</a>, which shows me as the committer and the patch author as the author. And that seems like a fine record of what happened.<br /><br /><br /><span style="font-size: large;"><b>Part 4: To Bug or Not To Bug?</b></span><br /><br />One of the questions GitHub raises is whether or not every change deserves a bug report. And if not, how do we differentiate those that do from the rest?<br /><br />I don't have the definitive answers to these questions, but my sense, from my experience so far, is that we shouldn't require all changes to be accompanied by bug reports, but larger, riskier, time-consuming, and/or controversial changes should have reports to capture history, provide a forum for discussion, and permit project planning; while bug reports should be optional for smaller, safer, quickly-resolved, and/or non-controversial changes.<br /><br /></div></content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/7037189428773681360/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=7037189428773681360' title='3 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/7037189428773681360'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/7037189428773681360'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2010/11/github-workflow-experiences.html' title='Git/Hub Workflow Experiences'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>3</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-236254320002589931</id><published>2010-07-15T14:22:00.000-07:00</published><updated>2011-09-20T11:38:43.557-07:00</updated><category scheme="http://www.blogger.com/atom/ns#" term="jetpack"/><title type='text'>My Recent Jetpack Presentations</title><content type='html'>The last few weeks have been presentation-heavy.<br /><br />First, I gave a presentation about the Jetpack project (past accomplishments, present status, future plans) at the <a href="https://wiki.mozilla.org/MAOW:2010:London">2010 London Mozilla Add-ons Workshop</a> (MAOW), including a demo of using <a href="https://builder.mozillalabs.com/">Add-on Builder</a> to build an add-on in five minutes.<br /><br />Then I reprised the Add-on Builder demo as part of the opening day keynote at the <a href="https://wiki.mozilla.org/Summit2010">Mozilla Summit</a>, where it got a great reception. You can watch it in <a href="http://www.youtube.com/watch?v=lKN4_fOKEWQ">this Youtube video</a>.<br /><br />Finally, I gave an updated version of the MAOW presentation on the third day of the summit. The slides are available in <a href="https://people.mozilla.com/%7Emyk/presentations/Prepare%20for%20Liftoff%20-%20Summit%202010.odp">OpenDocument</a> and <a href="https://people.mozilla.com/%7Emyk/presentations/Prepare%20for%20Liftoff%20-%20Summit%202010.pdf">PDF</a> formats, and Jetpack presentation materials generally are all available from the <a href="https://wiki.mozilla.org/Labs/Jetpack/Presentations">Jetpack Presentations wiki page</a>.</content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/236254320002589931/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=236254320002589931' title='6 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/236254320002589931'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/236254320002589931'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2010/07/my-recent-jetpack-presentations.html' title='My Recent Jetpack Presentations'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>6</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-6583468542975089893</id><published>2010-03-05T23:03:00.001-08:00</published><updated>2010-04-18T23:58:52.841-07:00</updated><title type='text'>This blog has moved</title><content type='html'><br /> This blog is now located at http://mykzilla.blogspot.com/.<br /> You will be automatically redirected in 30 seconds, or you may click <a href='http://mykzilla.blogspot.com/'>here</a>.<br /><br /> For feed subscribers, please update your feed subscriptions to<br /> http://mykzilla.blogspot.com/feeds/posts/default.<br /> </content><link rel="related" href="http://mykzilla.blogspot.com/" title="This blog has moved"/><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/6583468542975089893/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=6583468542975089893' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/6583468542975089893'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/6583468542975089893'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2010/03/this-blog-has-moved.html' title='This blog has moved'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>0</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-7015776887411907934</id><published>2009-11-17T17:26:00.000-08:00</published><updated>2009-11-17T17:26:50.807-08:00</updated><title type='text'>The Skinny on Raindrop's Mailing List Extensions</title><content type='html'>Raindrop is an exploration of messaging innovation that strives to intelligently assist people in managing their flood of incoming messages. And mailing lists are a common source of messages you need to manage. So, with assistance from the Raindrop hackers, I wrote extensions that make it easier to deal with messages from mailing lists.<br /><br />Their goal is to soothe two particular pain points when dealing with mailing lists: grouping their messages together by list and unsubscribing from them once you're no longer interested in their subject matter.<br /><br />This post explains how the extensions do this; touches on some aspects of Raindrop's message processing and data storage models; and speculates about possible future directions for the extensions.<br /><h3>Raindrop Extensibility</h3>Raindrop is being built with the explicit goal of being broadly and deeply extensible, and it includes a number of APIs for adding and modifying functionality. The mailing list enhancements comprise two related extensions, one in the backend and one in the user interface.<br /><br />The backend extension plugs into Raindrop's incoming message processor, intercepting incoming email messages and extracting info about the mailing lists to which they belong. It also handles much of the work of unsubscribing from a list.<br /><br />The frontend extension plugs into Raindrop's Inflow application, modifying its interface to show you the most recent mailing list messages at a glance, group mailing list conversations together by list, and provide a button you can press to easily unsubscribe from a mailing list.<br /><h3>Message Processing and Data Storage<br /></h3>Before getting into how the extensions work, it's useful to know a bit about how Raindrop processes and stores messages.<br /><br />Raindrop stores information using <a href="http://couchdb.apache.org/">CouchDB</a>, a document-centric database whose principal unit of information storage and retrieval is the document (the equivalent of a record in SQL databases). Documents are just JSON blobs that can contain arbitrary name -> value pairs (unlike SQL records, which can only contain values for predeclared columns).<br /><br />To distinguish between different kinds of documents, Raindrop assigns each a schema (similar to a table in SQL parlance) that describes (and may one day constrain) its properties. The <tt>rd.msg.email</tt> schema is the primary schema representing an email message, while the <tt>rd.mailing-list</tt> is the schema representing a mailing list, and the <tt>rd.msg.email.mailing-list</tt> is a simple schema that associates messages with their lists.<br /><br />(In an SQL database, <tt>rd.msg.email</tt> and <tt>rd.mailing-list</tt> would be tables whose rows represent email messages and mailing lists, while <tt>rd.msg.email.mailing-list</tt> would be a table whose rows map one to the other.)<br /><br />Note that there's a many-to-one relationship between messages and lists, since messages belong to a single list, although lists contain many messages, so <tt>rd.msg.email.mailing-list</tt> isn't strictly necessary. Its <tt>list-id</tt> property (which identifies the list to which the message belongs) could simply be a property of <tt>rd.msg.email</tt> docs (or, in SQL terms, a foreign key in the <tt>rd.msg.email</tt> table).<br /><br />But putting it into its own document has several advantages. First, it improves robustness, as it reduces the possibility of conflicts between extensions and core code writing to the same documents.<br /><br />It also improves write performance, as it's faster to add a document than to modify an existing one (although index generation and read performance can be an issue).<br /><br />Finally, it improves extensibility, because it makes it possible to write an extension that extends the backend mailing list extension.<br /><br />That's because Raindrop's incoming message processing model allows extensions to observe the creation of any kind of document, including those created by other extensions.<br /><br />So just as the mailing list extension observes the creation of <tt>rd.msg.email</tt> documents, another extension can observe the creation of <tt>rd.msg.email.mailing-list</tt> documents and process them further in some useful way. If the mailing list extension simply modified the original document instead of creating its own, that would require some additional and more complicated API.<br /><h3>The Backend Extension</h3>The primary function of the backend extension is to examine every incoming message and dress the ones from mailing lists with some additional structured information that the frontend can use to organize them.<br /><br />Backend extensions are accompanied by a JSON manifest that tells Raindrop what kinds of incoming documents it wants to intercept. The mailing list extension's manifest registers it as an observer of incoming <tt>rd.msg.email</tt> documents, which get created when Raindrop retrieves an email message:<br /><pre style="background-color: rgb(238, 238, 238); border: 1px solid rgb(187, 187, 187); color: black; padding: 10px;">"schemas" : {<br /> "rd.ext.workqueue" : {<br /> "source_schemas" : ["rd.msg.email"],<br />...</pre><br />The extension itself is a Python script with a <tt>handler</tt> function that gets passed the <tt>rd.msg.email</tt> document and looks to see if it contains a <tt>List-ID</tt> header (or, in certain cases, another identifier) identifying the mailing list from which the message comes:<br /><pre style="background-color: rgb(238, 238, 238); border: 1px solid rgb(187, 187, 187); color: black; padding: 10px;">def handler(message):<br /> ...<br /> if 'list-id' in message['headers']:<br /> # Extract the ID and name of the mailing list from the list-id header.<br /> # Some mailing lists give only the ID, but others (Google Groups,<br /> # Mailman) provide both using the format 'NAME &lt;id&gt;', so we extract them<br /> # separately if we detect that format.<br /> list_id = message['headers']['list-id'][0]<br /> ...</pre><br />If it doesn't find a list identifier, it simply returns, and Raindrop continues processing the message:<br /><pre style="background-color: rgb(238, 238, 238); border: 1px solid rgb(187, 187, 187); color: black; padding: 10px;">if not list_id:<br /> logger.debug("NO LIST ID; ignoring message %s", message_id)<br /> return</pre><br />Otherwise, it calls Raindrop's <tt>emit_schema</tt> function to create an <tt>rd.msg.email.mailing-list</tt> document linking the message document to an <tt>rd.mailing-list</tt> document representing the mailing list:<br /><pre style="background-color: rgb(238, 238, 238); border: 1px solid rgb(187, 187, 187); color: black; padding: 10px;">emit_schema('rd.msg.email.mailing-list', { 'list_id': list_id })</pre><br />In this function call, <tt>rd.msg.email.mailing-list</tt> is the type of document to create, while <tt>{ 'list_id': list_id }</tt> is the document itself, written as Python that will get serialized to JSON.<br /><br />A document created inside a backend extension like this automatically gets a reference to the document the extension is processing (i.e. the <tt>rd.msg.email</tt> document), so the only thing it has to explicitly include is a reference to the list document, in the form of a <tt>list_id</tt> property whose value is the list identifier.<br /><br />The extension also checks if there's an <tt>rd.mailing-list</tt> document in the database for the mailing list itself, and if not, it creates one, populating it with information from the message's <tt>List-*</tt> headers, like how to unsubscribe from the list. Otherwise, it updates the existing mailing list document if the message's <tt>List-*</tt> headers contain updates.<br /><h3>The Frontend Extension</h3>The frontend extension uses the information extracted by the backend to help users manage mailing lists in the Inflow application.<br /><br />It adds a widget to the Home view that shows you the last few messages from your lists at the bottom of the page, so you can keep an eye on those messages without having to give them your full attention:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://www.melez.com/mykzilla/uploaded_images/latest-list-messages-714113.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img src="http://www.melez.com/mykzilla/uploaded_images/latest-list-messages-714111.png" height="176" width="320" border="0" /></a><br /></div><br /><br />It adds a list of your mailing lists to the Organizer widget:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://www.melez.com/mykzilla/uploaded_images/mailing-list-list-722772.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img src="http://www.melez.com/mykzilla/uploaded_images/mailing-list-list-722768.png" height="320" width="190" border="0" /></a><br /></div><br /><br />And when you click on the name of a list, it shows you its conversations in the conversation pane:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://www.melez.com/mykzilla/uploaded_images/list-conversations-763392.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img src="http://www.melez.com/mykzilla/uploaded_images/list-conversations-763369.png" height="201" width="320" border="0" /></a><br /></div><br /><br />In traditional mail clients, users who want to break out their list messages into separate buckets like this typically have to create a folder for each list to contain its messages and then a filter for each list to move incoming list messages into the appropriate folders. The extension does this for you automatically!<br /><br />Finally, while viewing list conversations, if the extension knows how to unsubscribe you from the list, it displays an Unsubscribe button:<br /><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://www.melez.com/mykzilla/uploaded_images/unsubscribe-button-794151.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img src="http://www.melez.com/mykzilla/uploaded_images/unsubscribe-button-794149.png" height="201" width="320" border="0" /></a><br /></div><br /><br />Pressing the button (and then confirming your decision) unsubscribes you from the list. You don't have to do anything else, like remembering your username/password for some web page, sending an email, or confirming your request with the list admin. The extensions handle all those details for you so you don't have to know about them!<br /><h3>List Unsubscription</h3>In case you do want to know the details, however, it goes like this...<br /><br />First, the frontend extension sends a message to the list's admin address requesting unsubscription, with a certain command (like "unsubscribe") in the subject or body of the message (lists often specify exactly what command to send in the <tt>mailto:</tt> link they include in the <tt>List-Unsubscribe</tt> header):<br /><pre style="background-color: rgb(238, 238, 238); border: 1px solid rgb(187, 187, 187); color: black; padding: 10px;">From: Jan Reilly <jan@example.com><br />To: wasbigtalk-admin@example.com<br />Subject: unsubscribe</jan@example.com></pre><br />Then the server responds with a message requesting confirmation of the request, often putting a unique token into the Subject or Reply-To header to track the request:<br /><pre style="background-color: rgb(238, 238, 238); border: 1px solid rgb(187, 187, 187); color: black; padding: 10px;">From: wasbigtalk-admin@example.com<br />To: jan@example.com<br />Subject: please confirm unsubscribe from wasbigtalk (4bc3b7e439fd)<br /><br />Hello jan@example.com,<br /><br />We have received a request to unsubscribe you from wasbigtalk.<br />Please confirm this request to unsubscribe by replying to this email.<br />...</pre><br />Then the backend extension responds with a message confirming the request that includes the unique token:<br /><pre style="background-color: rgb(238, 238, 238); border: 1px solid rgb(187, 187, 187); color: black; padding: 10px;">From: jan@example.com<br />To: wasbigtalk-admin@example.com<br />Subject: Re: please confirm unsubscribe from wasbigtalk (4bc3b7e439fd)</pre><br />Finally, the server responds with a message confirming that the subscriber has, indeed, been unsubscribed:<br /><pre style="background-color: rgb(238, 238, 238); border: 1px solid rgb(187, 187, 187); color: black; padding: 10px;">From: wasbigtalk-admin@example.com<br />To: jan@example.com<br />Subject: you have been unsubscribed from wasbigtalk<br /><br />Hello jan@example.com,<br /><br />Your unsubscription from wasbigtalk was successful.<br />...</pre><br />At this point, the backend extension marks the list unsubscribed in the database, and the frontend extension marks it unsubscribed in the user interface.<br /><br />This process matches the way much mailing list server software works, although there are daemons in the details, so the extensions have to be programmed to support each server individually.<br /><br />Currently, they know how to handle <a href="http://groups.google.com/">Google Groups</a> and <a href="http://www.gnu.org/software/mailman/">Mailman</a> lists. <a href="http://www.mj2.org/">Majordomo2</a> (used by the <a href="http://www.bugzilla.org/">Bugzilla</a> and <a href="http://www.openbsd.org/">OpenBSD</a> projects, among others) is not supported, because it doesn't send <tt>List-*</tt> headers (alhough supposedly it can be configured to do so). The <a href="http://www.w3.org/">W3C</a>'s list server is not yet supported, although it does send <tt>List-*</tt> headers, and support should be fairly easy to add.<br /><br />Note that some of the processing the extension does is (locale-dependent) "screen"-scraping, as Google Groups and Mailman don't consistently identify the list ID and message type in some of their correspondence. In the long run, hopefully server software will improve in that regard. Perhaps someone can spearhead an effort to make it so?<br /><h3>The Future</h3>The extensions' current features fit in well with Raindrop's goal of helping people better handle their flood of incoming messages. But there is surely much more they could do to help in this regard.<br /><br />Besides general improvements to reliability and robustness--like support for additional list servers and handling of localized admin messages--they could let you resubscribe to a mailing list from which you've unsubscribed. And perhaps they could automatically fetch the messages you missed while you were away. Or even retrieve the entire archive of a list to which you're subscribed, so you can browse the archive in Raindrop!<br /><br />What bugs you about mailing lists? And how might Raindrop's mailing list extensions make them easier (and even funner) to use?</content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/7015776887411907934/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=7015776887411907934' title='7 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/7015776887411907934'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/7015776887411907934'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2009/11/skinny-on-raindrops-mailing-list.html' title='The Skinny on Raindrop's Mailing List Extensions'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>7</thr:total></entry><entry><id>tag:blogger.com,1999:blog-18929277.post-7740719470656815276</id><published>2009-11-04T15:58:00.001-08:00</published><updated>2009-11-04T15:58:03.687-08:00</updated><title type='text'>Building/Releasing Personas</title><content type='html'>Want to know how a popular extension like Personas gets built and released? Neither do I! Yet I know anyway. And I've written it down for your edification! So <a href="https://wiki.mozilla.org/Labs/Personas/Build">check it out</a>.<br> <br> </content><link rel='replies' type='application/atom+xml' href='http://mykzilla.blogspot.com/feeds/7740719470656815276/comments/default' title='Post Comments'/><link rel='replies' type='text/html' href='http://www.blogger.com/comment.g?blogID=18929277&postID=7740719470656815276' title='0 Comments'/><link rel='edit' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/7740719470656815276'/><link rel='self' type='application/atom+xml' href='http://www.blogger.com/feeds/18929277/posts/default/7740719470656815276'/><link rel='alternate' type='text/html' href='http://mykzilla.blogspot.com/2009/11/buildingreleasing-personas.html' title='Building/Releasing Personas'/><author><name>Myk Melez</name><uri>http://www.blogger.com/profile/01837818348188071923</uri><email>noreply@blogger.com</email><gd:image rel='http://schemas.google.com/g/2005#thumbnail' width='32' height='32' src='http://2.bp.blogspot.com/-_YZppM5V97U/VedxzrpG9BI/AAAAAAAAAGA/wHrKKAgCoH0/s220/headshot-2014.jpg'/></author><thr:total>0</thr:total></entry></feed> |