Nice comparison of the git vs bzr meeging approaches.
Git: "The changes appear to emerge fully-formed with no evidence of the process which created them."
Bzr: "the project's revision history will show the actual process the developer went through to create the branch."
comparison
Since some [D]CVSes support both styles - heck, even git and mercurial support both styles, and I think even bzr does - it may be more accurate to call it "clean history" versus "actual history" approaches.
The availability of a "rebase" tool is the main thing that enables the "clean history" approach.
Myself, I am unambiguously an "actual history" advocate. "Those who cannot remember the past are condemned to repeat it".
But I can understand why so many Linux developers want a clean history.
Myself, I want both: the actual history, and possibly a clean history that is what you see by default, when the actual history is pretty messy. (And believe me, I have seen the actual history get very messy.)
E.g. if you haven't rebased a task branch before merging, I want to see it in the style that the page depicts as bzr-style. But I suppose that it is okay to "fold" it into the trunk, if there has ben no trunk activity in the meantime. And if every checkin on the task branch is release-worthy. But if there are any checkins on the task-brach that were half-assed, that you might not want to bisect to, then no, I don't want it folded in.
But if you have rebased a task branch, because the trunk has been modified since the task branch was originally forked, and have tested all of the intermediate points on the rebase, then I want to see BOTH in the actual history.
I want to see the original, pre-rebase, task branch. Where the work was actually done.
But I am okay on seeing the rebased task branch, and even having it folded into the trunk,
I am okay on only presenting ONLY the rebased task branch and/or folded into the trunk, by default, HIDING the original pre-rebased task branch. But this is by default only. I would want to have some sort of indication that says "there's more history here".
Why?
Because I don't believe that you can completely test correctness.
Because experience shows that there is always a chance that the rebased task branch, folded into the trunk, will have a bug. A bug that occurred in the rebased task branch, but not in the original pre-rebased task branch. Essentially a bug caused by interference between whatever happened on the trunk and whatever happened on the task branch.
Even if your full test suite has been run on all of the pre- and post- rebase checkins. Because sometimes the test suite doesn't test for everything.
Sure, oftentimes it will not matter - you bisect on the rebased and folded task checkins, and find what the bug is. But sometimes it is good to understand why the bug occurred, not just what it is.
Rebasing, and other history rewriting mechanisms, have two functions IMHO:
1) cleaning up the history
2) as debugging tools
E.g. if you have a task branch, which has passed te test suite at all checkins, and a trunk which has similarly passed the test suite, and you merge - and there is a failure. But then obviously the failure is due to an interaction.
Creating a rebased clone of the task branch is then a debugging tool - you can see which of the task branch checks, which all passed tests pre-rebasing, causes tests to fail post-rebasing.
This is a damned useful thing to do even if the rebased task branch is not checked in / pushed to some more public repo - even if all you do is a branch merge.
E.g. sometimes I use a rebase just for debugging, and then through out the rebased branch.
What I do object to, however, is rebasing and NOT testing all of the intermediate checkins.
Merging in bzr: The git approach vs the bzr approach: "often"
'via Blog this'
Tuesday, September 29, 2015
Monday, September 21, 2015
Twitter's Tips for Making Software Engineers More Efficient - IEEE Spectrum
Amen!!!!!!!! (sez me, who has been dealing with FrameMaker and Parallels crashing many times a day.)
Twitter's Tips for Making Software Engineers More Efficient - IEEE Spectrum: "Reducing the number of times tools break—even if each incident just causes an interruption of a minute or two—can bring about huge productivity improvements. Seibel explains that each interruption takes an engineer out of “flow,” and studies show that it typically takes 15 minutes to enter a flow state. "
'via Blog this'
Twitter's Tips for Making Software Engineers More Efficient - IEEE Spectrum: "Reducing the number of times tools break—even if each incident just causes an interruption of a minute or two—can bring about huge productivity improvements. Seibel explains that each interruption takes an engineer out of “flow,” and studies show that it typically takes 15 minutes to enter a flow state. "
'via Blog this'
Thursday, September 17, 2015
Zero - smart and secure email client for your inbox on the App Store
I just installed the "Zero" iPhone app - and I *love* it. It allowed me to plow through 200+ (I think 300+) emails in my Gmail Inbox in less than half an hour. Whereas I only had managed to clear out a dozen in an hour using Google "Inbox for Gmail" earlier today.
I love Zero enough that I paid 5.99$ for an upgrade to unlimited accounts within an hour or starting to use it. But, see below.
And I cleared out my Gmail Inbox using Zero while walking on my treadmill desk!!! OK, I admit that I do everything except detailed drawing and coding while walking on my treadmill desk. But Zero was easier to use than most other apps.
Zero is a lot like Triage (http://www.triage.cc/) - an email app that I used to use on Android, although the web page only mentions IOS at the moment. I gave up Triage a while back, because back then (1) it required VPN to run on my phone in order to connect to my mailserver - which I am guessing meant that it did not use ActiveSync to connect to Microsoft Exchange) - which was suboptimal because it meant more hassle, and a long password, to type in when I wanted to quickly triage my email, and (2) back then Triage crashed a lot - sometimes seeming to delete email.
But when Triage was connected and was not crashing, it was sweet!
Both Zero and Triage do one job really well. They aren't full mail readers. What they do is allow you to quickly go through your Inbox, quickly archiving or discarding low priority email, allowing you to manually filter out low priority stuff so that only important stuff is left for you to handle, using a more powerful mailreader. Both Zero and Triage have some ability to respond to forward, email, or create new email - short messages, after which you archive or delete. But longer replies you would want to handle somewhere else. (Back when I was using Triage, most of the crashes and lossages were related to replying to or composing new email.
The key reason why Zero and Triage are more efficient for this particular email task is their user interface: they both use a "card" interface. One email per card.
The card shows a lot of a message - often the whole thing. Imagine the "preview" lines you get in a typical mailreader, but expanded to a screenful per message. You can tap on an email to truly see the whole thing, with HTML formatting, etc. But the "large preview" you see on the card allows me to process emails more quickly, much more often than the "short previews" you see with regular mailreaders like Outlook or Inbox or Mail or ...
And then the actual processing is easy: in Zero's case, swipe upwards to archive a message, so that it no longer appears in your Inbox. Swipe left exposes a screen to the right where you can see the full email. Tap a star to leave the mail in the Inbox.
Yes, this is not that different from the swipe actions of your favorite mailreader. Swipe right to archive, swipe left to schedule. (AFAICT neither Zero nor Triage have a "Defer" feature.)
But the cards, allowing a large amount, often all, of the email to be seen, and the simple swipe, allows me to go much faster.
Also, I have noticed: I seem to be able to swipe up or down much more easily than left or right. In part because I often switch the hand I am using the phone with: thumb swiping up works easily with either hand, but swiping left or right is more difficult no matter what, and often much more difficult in a non-preferred direction.
(I believe that swiping up was one of the big reasons that I found Flipboard https://flipboard.com/ so pleasant to use when it first came out. And Flipboard isn still pleasant to use in terms of swiping - it is just horribly full of ads and crashes my iPhone.)
I think this "card" interface is becoming a BKM (Best Known Method). I wish that it were integrated with standard email apps, like Inbox or Outlook for iPhone. Cards are just an alternate interface or "view". Most email apps have several views: (1) the message list, w/wo previews, possibly sorted. For Inbox, some other folder, or a search. (2) a full message view. (3) Now "cards".
(I really think that a "folder tree view" should be included, although most email readers have really, really, sucky tree viewers.)
I love Zero enough that I paid 5.99$ for an upgrade to unlimited accounts within an hour or starting to use it. But...
Zero is free for the first account, 1.99$ for the second, and 5.99$ for unlimited.
I hoped that I could be able to use Zero for my work email - I seem to remember that Triage could access our work server, using Imap (hence requiring VPN). But this seems not to fly.
So, I can only really use Zero for my personal email, not at work. I won't begrudge them the 6$ - I like supporting software that is useful. I wish them luck.
This situation is becoming more and more common: email is something people spend a lot of time on. There are many good ideas bubbling up - cards, swiping, AI-like autoprioritization. But no single app has all of the good ideas.
So we end up using multiple apps. Email widget apps, that do one thing well, but where you have to use other apps for other things. And just cross our fingers that the apps play together well.
Zero seems to use Gmail's standard Archive feature. And Zero's "mailfeed" seems to be just "Inbox and Unread" - i.e. Zero's concepts seem to map to standard Gmail concepts. I hope it will not interfere.
As far as I know, there is no standard feature for "Defer email to process later at a scheduled time". Different mailreaders handle this in different ways: labels, special folders.
And this is a common situation wrt security: typically, not being able to access corporate mailservers using your favorite mobile app. Being restricted to a much smaller number of limited, less innovative, email apps, like Microsft's Outlook app or Apple's standard Mail.app.
I understand corporate IT's unwillingness to allow random apps access to the corporate mailservers. Especially when those apps often process the email on the app company's servers - even if they put it back on your employer's mailservers.
I just wish that there was a better way: a way to get innovative features, like Zero and Triage's cards, on my work email.
I suppose monetization is part of the problem.
More and more, I find that the technology I use to handle email at work sucks compared to what I use outside work. Not only is it slow, but it is so much less pleasant that I am averse to reading work email using the primitive apps.
Zero - smart and secure email client for your inbox on the App Store
'via Blog this
I love Zero enough that I paid 5.99$ for an upgrade to unlimited accounts within an hour or starting to use it. But, see below.
And I cleared out my Gmail Inbox using Zero while walking on my treadmill desk!!! OK, I admit that I do everything except detailed drawing and coding while walking on my treadmill desk. But Zero was easier to use than most other apps.
Zero is a lot like Triage (http://www.triage.cc/) - an email app that I used to use on Android, although the web page only mentions IOS at the moment. I gave up Triage a while back, because back then (1) it required VPN to run on my phone in order to connect to my mailserver - which I am guessing meant that it did not use ActiveSync to connect to Microsoft Exchange) - which was suboptimal because it meant more hassle, and a long password, to type in when I wanted to quickly triage my email, and (2) back then Triage crashed a lot - sometimes seeming to delete email.
But when Triage was connected and was not crashing, it was sweet!
Both Zero and Triage do one job really well. They aren't full mail readers. What they do is allow you to quickly go through your Inbox, quickly archiving or discarding low priority email, allowing you to manually filter out low priority stuff so that only important stuff is left for you to handle, using a more powerful mailreader. Both Zero and Triage have some ability to respond to forward, email, or create new email - short messages, after which you archive or delete. But longer replies you would want to handle somewhere else. (Back when I was using Triage, most of the crashes and lossages were related to replying to or composing new email.
The key reason why Zero and Triage are more efficient for this particular email task is their user interface: they both use a "card" interface. One email per card.
The card shows a lot of a message - often the whole thing. Imagine the "preview" lines you get in a typical mailreader, but expanded to a screenful per message. You can tap on an email to truly see the whole thing, with HTML formatting, etc. But the "large preview" you see on the card allows me to process emails more quickly, much more often than the "short previews" you see with regular mailreaders like Outlook or Inbox or Mail or ...
And then the actual processing is easy: in Zero's case, swipe upwards to archive a message, so that it no longer appears in your Inbox. Swipe left exposes a screen to the right where you can see the full email. Tap a star to leave the mail in the Inbox.
Yes, this is not that different from the swipe actions of your favorite mailreader. Swipe right to archive, swipe left to schedule. (AFAICT neither Zero nor Triage have a "Defer" feature.)
But the cards, allowing a large amount, often all, of the email to be seen, and the simple swipe, allows me to go much faster.
Also, I have noticed: I seem to be able to swipe up or down much more easily than left or right. In part because I often switch the hand I am using the phone with: thumb swiping up works easily with either hand, but swiping left or right is more difficult no matter what, and often much more difficult in a non-preferred direction.
(I believe that swiping up was one of the big reasons that I found Flipboard https://flipboard.com/ so pleasant to use when it first came out. And Flipboard isn still pleasant to use in terms of swiping - it is just horribly full of ads and crashes my iPhone.)
I think this "card" interface is becoming a BKM (Best Known Method). I wish that it were integrated with standard email apps, like Inbox or Outlook for iPhone. Cards are just an alternate interface or "view". Most email apps have several views: (1) the message list, w/wo previews, possibly sorted. For Inbox, some other folder, or a search. (2) a full message view. (3) Now "cards".
(I really think that a "folder tree view" should be included, although most email readers have really, really, sucky tree viewers.)
I love Zero enough that I paid 5.99$ for an upgrade to unlimited accounts within an hour or starting to use it. But...
Zero is free for the first account, 1.99$ for the second, and 5.99$ for unlimited.
I hoped that I could be able to use Zero for my work email - I seem to remember that Triage could access our work server, using Imap (hence requiring VPN). But this seems not to fly.
So, I can only really use Zero for my personal email, not at work. I won't begrudge them the 6$ - I like supporting software that is useful. I wish them luck.
This situation is becoming more and more common: email is something people spend a lot of time on. There are many good ideas bubbling up - cards, swiping, AI-like autoprioritization. But no single app has all of the good ideas.
So we end up using multiple apps. Email widget apps, that do one thing well, but where you have to use other apps for other things. And just cross our fingers that the apps play together well.
Zero seems to use Gmail's standard Archive feature. And Zero's "mailfeed" seems to be just "Inbox and Unread" - i.e. Zero's concepts seem to map to standard Gmail concepts. I hope it will not interfere.
As far as I know, there is no standard feature for "Defer email to process later at a scheduled time". Different mailreaders handle this in different ways: labels, special folders.
And this is a common situation wrt security: typically, not being able to access corporate mailservers using your favorite mobile app. Being restricted to a much smaller number of limited, less innovative, email apps, like Microsft's Outlook app or Apple's standard Mail.app.
I understand corporate IT's unwillingness to allow random apps access to the corporate mailservers. Especially when those apps often process the email on the app company's servers - even if they put it back on your employer's mailservers.
I just wish that there was a better way: a way to get innovative features, like Zero and Triage's cards, on my work email.
I suppose monetization is part of the problem.
More and more, I find that the technology I use to handle email at work sucks compared to what I use outside work. Not only is it slow, but it is so much less pleasant that I am averse to reading work email using the primitive apps.
Zero - smart and secure email client for your inbox on the App Store
'via Blog this
Tuesday, September 08, 2015
Version Control of Crash Recovery Cruft
I have developed a system whereby I archive the "cruft" created by a crash into a tar file
TAR.archived-framemaker-cruft.tar
so that I can recover autosave files if necessary, but so that they do not clutter my directory.
I just added a quickie to count the number of crashes saved, or at least an approximation thereof.
This is one of those "duh, why didn't I do this years ago" sorts of things.
EVERYTHING needs version control.
Even crash recovery files.
It sure is nice to have multiple versions of the same crash recovery file(name) , rather than having to rename them autosave.1 autosave.2, ... (Most important thing is to be able to name things. Second most important thing is to not have to name things.)
CRUFT_FILES= $(FM_CRUFT_FILES) $(PPT_CRUFT_FILES) FM_CRUFT_FILES= *.auto.fm *.backup.fm *.auto.book *.backup.book *.recover.fm *.recover.book PPT_CRUFT_FILES= *Autosaved*.pptx .PHONY: save-cruft save-cruft: archive-all-autosave-files .PHONY: archive-all-autosave-files archive-all-autosave-files: -echo $(PPT_CRUFT_FILES) | gtar -uf TAR.archived framemaker-cruft.tar -rm $(PPT_CRUFT_FILES) -echo $(FM_CRUFT_FILES) | gtar -uf TAR.archived-framemaker-cruft.tar -rm $(FM_CRUFT_FILES) make unlock-all-framemaker-files
.PHONY: ls-cruft ls-cruft: ls $(CRUFT_FILES)
.PHONY: count-crashes count-crashes: .PHONY: count-saved-crash-cruft count-saved-crash-cruft: gtar tvf TA*tar | perl -p -e 's/^([^ \t]+[ \t]+){3}([^ \t]+ [^ \t]+).*/\2/' | sort -u | tee >(echo "Unique timestamps (crash points in archive):" `gwc --lines`)
Sunday, September 06, 2015
Who says Mac OS X does not need uninstallers
I have heard people say that Windows needs uninstallers for DSW because of design flaws, whereas Mac OS X does not need uninstallers because of its perfect UNIX-ish design.
False!
Evidence: uninstalling the "Basis Sync.app", now that I am no longer using my Basis B1 watch (R.I.P.).
The web page link says, paraphrasing: "To uninstall move the 'Basis Sync.app' from the /Applications folder to Trash. Also, go and remove support files from ~/Library/Application Support/Basis Sync."
The two separate steps would be encapsulated by an uninstaller.
But furthermore: trying to move the 'Basis Sync.app' fails, because the app is running - I was starting it by default. (I guess Apple has put in a Windows like interlock; normal UNIX would blindly unlink a running program.) Option-Command-Escape does not show 'Basis Sync.app' as running. However, standard UNIX ps does, and I can kill it, and then remove the app.
I know how to do this. But how many non-UNIX users would? My wife? My mother?
Automating - creating an uninstaller - forces the software vendor to really know how to uninstall.
False!
Evidence: uninstalling the "Basis Sync.app", now that I am no longer using my Basis B1 watch (R.I.P.).
The web page link says, paraphrasing: "To uninstall move the 'Basis Sync.app' from the /Applications folder to Trash. Also, go and remove support files from ~/Library/Application Support/Basis Sync."
The two separate steps would be encapsulated by an uninstaller.
But furthermore: trying to move the 'Basis Sync.app' fails, because the app is running - I was starting it by default. (I guess Apple has put in a Windows like interlock; normal UNIX would blindly unlink a running program.) Option-Command-Escape does not show 'Basis Sync.app' as running. However, standard UNIX ps does, and I can kill it, and then remove the app.
I know how to do this. But how many non-UNIX users would? My wife? My mother?
Automating - creating an uninstaller - forces the software vendor to really know how to uninstall.
Wednesday, September 02, 2015
Watch and fitness band
After the Withings Activite' Pop failed to satisfy, I have reverted to a slightly updated version of what I have been wearing for the past year: a semi-smart watch on one wrist, and a fitness tracker wristband on the other.
Before their watery demise, I was wearing the Basis B1 watch, and a Jawbone UP. I bought the Basis watch first. I later bought the Jawbone UP, at first just to get vibrating alarms - but I liked the UP iPhone app so much more that it became my main fitness tracker. I mainly used the Basis as a watch, to tell the time, and because it had a display so that I could see how many steps I had done without opening my phone.
Now I am wearing a Pebble Smartwatch, and a Jawbone UP2.
The UP2 because I continue to prefer its app, and for sleep monitoring. The Jawbone UP was able to tell whether I was awake or asleep automatically, but only the Misfit watchapp can do that on the Pebble - and it interferes with other watchapps, like the Jawbone UP watchapp, which actually counts steps.
Interference between watchapps is the bugbear of the Pebble.
I was therefore a bit disappointed to learn that the UP2 has separate modes for sleep and awake. Automatically detecting is the entire reason I got the UP2.
The Pebble SmartWatch (a) because running the Jawbone UP watchapp displays steps taken in almost real time - i.e. because it has a display. (b)_Swimming. (c)_Other smartwatch goodness: (c.1) calendar (via SmartWatch Pro), (c.2)_notifications about email and text (mixed blessing, needs better filtering), (c.3)_bus and train schedule. (d) Because I can write my own watchapps, in my own copious free time.
I can already feel the gravitational pull: I am frustrated when something that could fit in the smartwatch's limited form factor is not available as a watchapp. Just as I prefer to use my cellphone for most things that fit on it, I think the same will apply to the watch. The cellphone just has a bigger display, and the MacBook an even bigger display, and a big keyboard.
If we had goggles...
Tuesday, September 01, 2015
Development Platforms for MIPS (esp MIPS64)
I have often been asked by my hacker friends "Where do I get a MIPS based system to play with?" As in home, personal, hacking and experimentation. SW and/or HW.
Apart from saying "Well, your home router probably has a MIPS CPU" or "Install OpenWRT or the like on a home router" I have never really had a good answer for my friends.
In particular, I did not know where to find a MIPS64 development system - to recommend to my friends, but also for my playing around with at home.
I just found the webpage of MIPS development systems here, and in particular the Ubiqiti Edgemac ERlite-3. With its big brothers in the Ubiqiti EdgeRouter family (datasheet), the ER-8 and the ERpro-8, ranging from
2 MIPS64 cores (from Cavium) @ 500 MHz
512MB DRAM / 2GB flash / 4 ports
to
2 MIPS64 cores @ 1 GHz
2G DRAM / 4GB flash / 8 ports
with prices from circa 92$ to 345$ on Amazon.
I was about to complain about the relatively small amounts of DRAM and Flash for 64-bit OS development. (Although, a lot more than most routers have.)
But: this is MIPS. SW TLB miss handling is the norm. If you can memory map the flash, you could make the flash part of the memory hierarchy beyond DRAM. I.e. treat DRAM as a cache for flash, write absorbing.
Heck, this could be a fun system for ASPLOS type OS hacking, designing alternative page table structures for OSes, virtual machines, etc.
Attach a NAS to the ethernet ports, and away you go.
A very nice system for SW hacking, especially if you hack at the virtual memory level.
Unclear how much hardware hacking you can do.
Daddy knows what he wants for Christmas.
Apart from saying "Well, your home router probably has a MIPS CPU" or "Install OpenWRT or the like on a home router" I have never really had a good answer for my friends.
In particular, I did not know where to find a MIPS64 development system - to recommend to my friends, but also for my playing around with at home.
I just found the webpage of MIPS development systems here, and in particular the Ubiqiti Edgemac ERlite-3. With its big brothers in the Ubiqiti EdgeRouter family (datasheet), the ER-8 and the ERpro-8, ranging from
2 MIPS64 cores (from Cavium) @ 500 MHz
512MB DRAM / 2GB flash / 4 ports
to
2 MIPS64 cores @ 1 GHz
2G DRAM / 4GB flash / 8 ports
I was about to complain about the relatively small amounts of DRAM and Flash for 64-bit OS development. (Although, a lot more than most routers have.)
But: this is MIPS. SW TLB miss handling is the norm. If you can memory map the flash, you could make the flash part of the memory hierarchy beyond DRAM. I.e. treat DRAM as a cache for flash, write absorbing.
Heck, this could be a fun system for ASPLOS type OS hacking, designing alternative page table structures for OSes, virtual machines, etc.
Attach a NAS to the ethernet ports, and away you go.
A very nice system for SW hacking, especially if you hack at the virtual memory level.
Unclear how much hardware hacking you can do.
Daddy knows what he wants for Christmas.
Subscribe to:
Posts (Atom)