https://petitions.whitehouse.gov/petition/create-national-holidays-voting-consolidating-other-holidays-honor-civic-engagement/wx7xMFCR
Please consider whether this suggestion makes sense.
Saturday, August 23, 2014
Saturday, March 23, 2013
Who worries about the Internet "pipes" getting clogged?
I started looking at the pool.ntp.org project. I manage several data centers with various kinds of connections and some of the machines disagree with each other about the time. The effort behind pool.ntp.org seems to be a really good idea. It made me wonder, why is information about the Internet not shared in the same way?
Remember hearing about Internet blockages in Syria? A private company in the US reported it. Who is that? Who are their customers? Why are we hearing about the state of the Internet from a private company? There could be a distributed group of people sharing information to do the same thing. Sounds sort of like something you would do on the Internet, yes?
I worry about what drives connectivity, because often it seems to not do so. We wanted to serve customers in Jakarta. The Jakarta-based provider have really bad service to Jakarta. It turns out that if you go to Tokyo, the connection to Jakarta is wicked fast. Well, all the infrastructure in Indonesia points out. There is less infrastructure for services within Indonesia.
And then I hear that if you look at connections between the US and Europe on the Internet, the distributed-to-survive-a-nuclear-war-or-massive-disaster-Internet, a massive proportion of them go through Manhattan, an island. Because who would ever attack Manhattan? Really.
What's my point? I am not sure. But if you want a robust Internet, is letting the companies run it put all of the eggs in a very small number of baskets a good idea? Maybe not. Maybe I should find out about the state of connectivity around the things I care about. I bet I know where I can but a $10,000 whitepaper that tells me what I want to know.
Remember hearing about Internet blockages in Syria? A private company in the US reported it. Who is that? Who are their customers? Why are we hearing about the state of the Internet from a private company? There could be a distributed group of people sharing information to do the same thing. Sounds sort of like something you would do on the Internet, yes?
I worry about what drives connectivity, because often it seems to not do so. We wanted to serve customers in Jakarta. The Jakarta-based provider have really bad service to Jakarta. It turns out that if you go to Tokyo, the connection to Jakarta is wicked fast. Well, all the infrastructure in Indonesia points out. There is less infrastructure for services within Indonesia.
And then I hear that if you look at connections between the US and Europe on the Internet, the distributed-to-survive-a-nuclear-war-or-massive-disaster-Internet, a massive proportion of them go through Manhattan, an island. Because who would ever attack Manhattan? Really.
What's my point? I am not sure. But if you want a robust Internet, is letting the companies run it put all of the eggs in a very small number of baskets a good idea? Maybe not. Maybe I should find out about the state of connectivity around the things I care about. I bet I know where I can but a $10,000 whitepaper that tells me what I want to know.
Thursday, February 02, 2012
Facebook IPO chatter reminds me why Firefox is so important to me...
Hearing all the media blather about the upcoming Facebook IPO has made me think about a couple of things. Mostly, I am so glad I have Firefox available. I learned to develop Facebook applications a few years back, looked at what the applications could see about a user, and removed myself from every single application on Facebook. The amount of information an application user is giving away is amazing.
Luckily, I have Firefox and add-ons like Adblock and Ghostery (for tracking/blocking inter-site data slurping) and other tools of that sort to help me to, perhaps, stay under the radar of some of those people. Somewhat.
On the other hand, Mozilla seems to be reluctant to let the search bar be configured to go to https://www.google.com. (http://bugzilla.mozilla.org/show_bug.cgi?id=633773) Hm. Maybe Mozilla is still, in some ways at least, just another company. O well, it is something to think about.
Luckily, I have Firefox and add-ons like Adblock and Ghostery (for tracking/blocking inter-site data slurping) and other tools of that sort to help me to, perhaps, stay under the radar of some of those people. Somewhat.
On the other hand, Mozilla seems to be reluctant to let the search bar be configured to go to https://www.google.com. (http://bugzilla.mozilla.org/show_bug.cgi?id=633773) Hm. Maybe Mozilla is still, in some ways at least, just another company. O well, it is something to think about.
Sunday, August 28, 2011
The Internet: how are those tubes working anyway?
I am finding myself dealing with an unexpected question. Does the Internet work? You know, the whole moving data from place to place. Is it really working?
Well, of course it is. But perhaps not for everyone. I am trying to find out why we often have problems reaching our data centers. The company I work for sells software for people learning English. I think this is the root of the problem. There might be 2 billion people on the planet with an interest in learning English, but not too many of them live near a T1. Why can't I reach my data centers? Maybe because they are in places like Ulan Bator and Ho Chi Minh City.
Why do we need all these data centers? Often it is because we have to have an in-country data center to avoid having all of our customers take a "Golden Shield" hit. If customers in China, or Vietnam or Saudi Arabia, or other places, need to get content from outside the country, the latency turns out to be very high. Get the content into an in-country data center and your performance problems go away.
But here is an odd thing. We have customers in Jakarta that have connect problems. Getting an ISP in Jakarta does not fix it. Turns out that a connection from one part of Jakarta to another part of Jakarta is slow and unreliable. Serving data from Tokyo to Jakarta, however, is fast and reliable. Hm.
Actually I am interested if anyone has ideas about how to measure connectivity more broadly. One might think the net would have distributed sources of information about connectivity, but it does not seem to be so. One can measure pings, but one needs to keep track of a lot of pings to figure anything out. One can run traceroutes. Or not. Somebody in Mongolia blocks traceroutes, for example. And traceroutes do not necessarily follow the same routes that regular traffic will. Or you can buy reports about connectivity, if you have spend tens of thousands on them or sign up for fairly expensive services. And Akamai and other services work great, assuming you want to sell something to the creme de la creme of the First World. And that is, after all, most of the businesses out there.
I wonder if there is a way to collect connectivity information in a distributed, peer-to-peer manner. Perhaps we can use this Internet thing for that, too. Or is something available and I just have not hit upon it? Does anyone run "weather reports" for the Internet? Could it be accessed as a utility? Looking for suggestions, questions, thoughts, ridicule, insults, jibes, or whatever works for you.
Well, of course it is. But perhaps not for everyone. I am trying to find out why we often have problems reaching our data centers. The company I work for sells software for people learning English. I think this is the root of the problem. There might be 2 billion people on the planet with an interest in learning English, but not too many of them live near a T1. Why can't I reach my data centers? Maybe because they are in places like Ulan Bator and Ho Chi Minh City.
Why do we need all these data centers? Often it is because we have to have an in-country data center to avoid having all of our customers take a "Golden Shield" hit. If customers in China, or Vietnam or Saudi Arabia, or other places, need to get content from outside the country, the latency turns out to be very high. Get the content into an in-country data center and your performance problems go away.
But here is an odd thing. We have customers in Jakarta that have connect problems. Getting an ISP in Jakarta does not fix it. Turns out that a connection from one part of Jakarta to another part of Jakarta is slow and unreliable. Serving data from Tokyo to Jakarta, however, is fast and reliable. Hm.
Actually I am interested if anyone has ideas about how to measure connectivity more broadly. One might think the net would have distributed sources of information about connectivity, but it does not seem to be so. One can measure pings, but one needs to keep track of a lot of pings to figure anything out. One can run traceroutes. Or not. Somebody in Mongolia blocks traceroutes, for example. And traceroutes do not necessarily follow the same routes that regular traffic will. Or you can buy reports about connectivity, if you have spend tens of thousands on them or sign up for fairly expensive services. And Akamai and other services work great, assuming you want to sell something to the creme de la creme of the First World. And that is, after all, most of the businesses out there.
I wonder if there is a way to collect connectivity information in a distributed, peer-to-peer manner. Perhaps we can use this Internet thing for that, too. Or is something available and I just have not hit upon it? Does anyone run "weather reports" for the Internet? Could it be accessed as a utility? Looking for suggestions, questions, thoughts, ridicule, insults, jibes, or whatever works for you.
Thursday, June 16, 2011
Why iCloud?
I am increasingly glad that I left Apple to do other things. And I am sure Apple will continue to make more money for a while. But one has to wonder.
Here is a company dedicated to the "Wow!". The stars in their developer teams create these applications that you launch and, really, they are beautiful. They are only 85% finished, but they look good and one does not see the problems until a few days later. Then, hey, you already bought it. They have a Support group to make you feel better about this. And you can file bugs. And wait for the next version. But that's about it.
There was only one place in Apple that spoke about things like MTBF and that actually measured things like reliability. That was the server group. You know, the one whose products got deprecated and that is probably mostly gone at this point. Apple's apps are known for the elegance of their UIs and not for reliability. Everyone else at Apple says "You re-boot and your problem is gone? Problem solved." And these are the people that are going to build a cloud-based music service?
The important people at Apple used to design things, create standards, carve beauty out of technological crap. Now, the important people are going to be running a data center full of HP machines. In North Carolina. It is truly sad.
Of course, iCloud is a good idea for Apple. You used to pay for your music, own your music, and hold your music. With the iTunes Store, you pay for your music and hold your music and Apple owns your music. Now, with iCloud, you pay for your music, Apple holds your music and Apple owns your music. And this is a good deal. Why is Apple doing this? They might say, "because iCould."
Here is a company dedicated to the "Wow!". The stars in their developer teams create these applications that you launch and, really, they are beautiful. They are only 85% finished, but they look good and one does not see the problems until a few days later. Then, hey, you already bought it. They have a Support group to make you feel better about this. And you can file bugs. And wait for the next version. But that's about it.
There was only one place in Apple that spoke about things like MTBF and that actually measured things like reliability. That was the server group. You know, the one whose products got deprecated and that is probably mostly gone at this point. Apple's apps are known for the elegance of their UIs and not for reliability. Everyone else at Apple says "You re-boot and your problem is gone? Problem solved." And these are the people that are going to build a cloud-based music service?
The important people at Apple used to design things, create standards, carve beauty out of technological crap. Now, the important people are going to be running a data center full of HP machines. In North Carolina. It is truly sad.
Of course, iCloud is a good idea for Apple. You used to pay for your music, own your music, and hold your music. With the iTunes Store, you pay for your music and hold your music and Apple owns your music. Now, with iCloud, you pay for your music, Apple holds your music and Apple owns your music. And this is a good deal. Why is Apple doing this? They might say, "because iCould."
Monday, January 18, 2010
China Stealing IP? I'm Shocked, Shocked I Tell You....
We're hearing a lot of news about China trying to steal intellectual property from companies like Google. There's a lot of sanctimonious news coverage about how we have innovative companies and China is trying to steal their way out of having to do the work.
Then one of these "innovative" companies was named. Microsoft. Then it occurred to me where the objection really comes from. Microsoft has never done an innovative thing, ever, except invent OLE. And you can thank that for your virus problems. But they do buy lots and lots of other companies that have innovated. So, in the US, the currency of our society is just that, currency. The dollar rules all. In China, political power is the currency. So, Microsoft spends one type of currency to get access to other people's creativity because they are out of ideas. And China spends another type of currency to get access to other people's creativity because they are out of ideas. They are different, but there are similarities.
We lose a lot of IP because we manufacture in China. We manufacture there because they have weak worker protection laws, no environmental regulations and, basically, business can do what it wants. There is a basic lack of civic law. Want to make cheap plastic crap and dump the waste in the river? Rock and roll! But then our stuff gets stolen. CDs get pirated, designs get copied. Why? Perhaps it is because there is a basic lack of civic law. But isn't that why we want to manufacture there in the first place? And then, do we get to complain about it as well?
People who are really being creative know their work cannot be outsourced. Companies trying to milk a fifty-year old file of patents have reason to be upset. It just does not bother me.
Then one of these "innovative" companies was named. Microsoft. Then it occurred to me where the objection really comes from. Microsoft has never done an innovative thing, ever, except invent OLE. And you can thank that for your virus problems. But they do buy lots and lots of other companies that have innovated. So, in the US, the currency of our society is just that, currency. The dollar rules all. In China, political power is the currency. So, Microsoft spends one type of currency to get access to other people's creativity because they are out of ideas. And China spends another type of currency to get access to other people's creativity because they are out of ideas. They are different, but there are similarities.
We lose a lot of IP because we manufacture in China. We manufacture there because they have weak worker protection laws, no environmental regulations and, basically, business can do what it wants. There is a basic lack of civic law. Want to make cheap plastic crap and dump the waste in the river? Rock and roll! But then our stuff gets stolen. CDs get pirated, designs get copied. Why? Perhaps it is because there is a basic lack of civic law. But isn't that why we want to manufacture there in the first place? And then, do we get to complain about it as well?
People who are really being creative know their work cannot be outsourced. Companies trying to milk a fifty-year old file of patents have reason to be upset. It just does not bother me.
Wednesday, November 18, 2009
Three Pictures
What do these three pictures have in common?
The first is a US Dept of Homeland Security warning. The second is a Proposition 65 warning from California. The third is from Firefox when we add _any_ add-on.
Obvious questions are:
- does anyone feel safer when they see these?
- do these actually inform one of anything?
- why are these being displayed? for whose benefit?
 |  |  |
The first is a US Dept of Homeland Security warning. The second is a Proposition 65 warning from California. The third is from Firefox when we add _any_ add-on.
Obvious questions are:
- does anyone feel safer when they see these?
- do these actually inform one of anything?
- why are these being displayed? for whose benefit?
Tuesday, April 07, 2009
Benefits of Open Source, or Why the iPhone Will Continue to Suck
I am doing less direct development using Mozilla tools lately, but a recent trip to British Columbia has brought home to me, again, why Mozilla is important.
I am doing iPhone development and will, in the future, be doing Android development as well. But I was surprised that, on most of my trip, my iPhone was useless. I often did not have cell service, but when I did, I had no access to network-based services. Apparently I would have had to connect via Rogers and pay roaming charges and I was unwilling to do so. This is the problem with a single point-of-failure in the Internet. This is why we do not have one company, like Apple, running the Internet. Apple is seeking control of the iPhone market for obvious reasons, but this costs us as consumers. We should, as we pay those ever-increasing monthly charges, keep this in mind. Really, the fact that we cannot have data services everywhere is just sad. Companies would rather offer less and control more of it than offer more to consumers if they lose some control. And let's not even talk about how bad the App Store is for finding things. Please. There's to much and it hurts to talk about it.
I am also recently using Chandler for my calendar and for keeping track of 'to do' items. It is an interesting app and I went to see the latest dev versions of it and see about building it. Apparently, I have a level of expectation about open source projects. Apparently it is not worth it to interact with the source unless it builds like Mozilla. Chandler development is Linux-only, and while I could upgrade to the version of Parallels I need (since VirtualBox does not see to do enough for me) and build it that way, I find myself unwilling to do so. Despite my ability to complain about the quirks of building mozilla tools, it seems to work better than most alternatives. But I really only complain loudest about something when I like it. This may not be obvious to people to whom I complain.
It turns out that being connection-less for a time is a good thing, though. It makes you think about the value and cost of being always connected. When I was working for Mozilla, one of the things that was a problem for me (though I did not realize it at the time) is that Mozilla's offices are on-line all the time. It is too easy to be "at the office" every day, all day. Reading most Mozilla posts you see how the veterans deal with it, so that they can keep their families, their friends and their sanity. It probably would have been easier to focus if I had not found the information ecosystem around Mozilla to be so rich and fascinating. One has to balance finding that connection with a new friend in Europe with the need to get things done. It is easier, for now, working for myself, but I will have to figure this out someday. We'll see.
I am doing iPhone development and will, in the future, be doing Android development as well. But I was surprised that, on most of my trip, my iPhone was useless. I often did not have cell service, but when I did, I had no access to network-based services. Apparently I would have had to connect via Rogers and pay roaming charges and I was unwilling to do so. This is the problem with a single point-of-failure in the Internet. This is why we do not have one company, like Apple, running the Internet. Apple is seeking control of the iPhone market for obvious reasons, but this costs us as consumers. We should, as we pay those ever-increasing monthly charges, keep this in mind. Really, the fact that we cannot have data services everywhere is just sad. Companies would rather offer less and control more of it than offer more to consumers if they lose some control. And let's not even talk about how bad the App Store is for finding things. Please. There's to much and it hurts to talk about it.
I am also recently using Chandler for my calendar and for keeping track of 'to do' items. It is an interesting app and I went to see the latest dev versions of it and see about building it. Apparently, I have a level of expectation about open source projects. Apparently it is not worth it to interact with the source unless it builds like Mozilla. Chandler development is Linux-only, and while I could upgrade to the version of Parallels I need (since VirtualBox does not see to do enough for me) and build it that way, I find myself unwilling to do so. Despite my ability to complain about the quirks of building mozilla tools, it seems to work better than most alternatives. But I really only complain loudest about something when I like it. This may not be obvious to people to whom I complain.
It turns out that being connection-less for a time is a good thing, though. It makes you think about the value and cost of being always connected. When I was working for Mozilla, one of the things that was a problem for me (though I did not realize it at the time) is that Mozilla's offices are on-line all the time. It is too easy to be "at the office" every day, all day. Reading most Mozilla posts you see how the veterans deal with it, so that they can keep their families, their friends and their sanity. It probably would have been easier to focus if I had not found the information ecosystem around Mozilla to be so rich and fascinating. One has to balance finding that connection with a new friend in Europe with the need to get things done. It is easier, for now, working for myself, but I will have to figure this out someday. We'll see.
Sunday, February 08, 2009
Software Patents and Open-Source
I am slightly sanguine about the possibility that reality and rationality might actually drive the Supreme Court to invalidate software patents, which they might eventually do in the In re Bilski case. I hope the open-source community appreciates the importance of this.
I was working at Apple as they were looking at making a certain technology open source. There was quite a bit of evidence that making this technology available via open-source licenses would make it much more widely usable and it would get maintenance and TLC that Apple had no business case to provide, but it got nixed from higher-ups.
It turns out that one of the best uses of a patented software technology is to seal it in a black box and say nothing. It is a secret landmine that one can use against others. This will not help the software get used, but that is not the point. It does not actually matter whether it is a good patent or not. Lots of bad patents get approved by the Patent Office and the cost of defending against the holder of a bad patent is the same as the cost of defending against the holder of a patent that actually does involve innovation.
Software companies use these patents like playing cards. One big company goes to another and tries to strong-arm some licensing money out of them. The target company pulls out its cards and says, "Sue us for X, Y, and Z and we will sue you for A, B and C." Eventually their lawyers sit down, cards are shown, somebody decides to pay something or not, they write a cross-licensing agreement and both companies go home happy.
A side benefit of this is that small companies that might be developing innovative software cannot afford the ante and they are locked out. The big patent holders, IBM, Apple, Microsoft, Sony at al are happy and they shut down those annoying whipper-snappers who want to do something better.
This state of affairs is particularly saddening when one looks at why we have patents. Ask 100 people "what is the purpose of a patent?" and 99 will say that they protect the author of some discovery or creative work. In reality the temporary monopoly provided to a copyright or patent holder is the means of fulfilling the purpose. It is not the purpose itself. Looking at the Constitution, one sees this power assigned to Congress in Article 1, Section 8 of the US Constitution:
I was working at Apple as they were looking at making a certain technology open source. There was quite a bit of evidence that making this technology available via open-source licenses would make it much more widely usable and it would get maintenance and TLC that Apple had no business case to provide, but it got nixed from higher-ups.
It turns out that one of the best uses of a patented software technology is to seal it in a black box and say nothing. It is a secret landmine that one can use against others. This will not help the software get used, but that is not the point. It does not actually matter whether it is a good patent or not. Lots of bad patents get approved by the Patent Office and the cost of defending against the holder of a bad patent is the same as the cost of defending against the holder of a patent that actually does involve innovation.
Software companies use these patents like playing cards. One big company goes to another and tries to strong-arm some licensing money out of them. The target company pulls out its cards and says, "Sue us for X, Y, and Z and we will sue you for A, B and C." Eventually their lawyers sit down, cards are shown, somebody decides to pay something or not, they write a cross-licensing agreement and both companies go home happy.
A side benefit of this is that small companies that might be developing innovative software cannot afford the ante and they are locked out. The big patent holders, IBM, Apple, Microsoft, Sony at al are happy and they shut down those annoying whipper-snappers who want to do something better.
This state of affairs is particularly saddening when one looks at why we have patents. Ask 100 people "what is the purpose of a patent?" and 99 will say that they protect the author of some discovery or creative work. In reality the temporary monopoly provided to a copyright or patent holder is the means of fulfilling the purpose. It is not the purpose itself. Looking at the Constitution, one sees this power assigned to Congress in Article 1, Section 8 of the US Constitution:
To promote the progress of science and useful arts, by securing for limited times to authors and inventors the exclusive right to their respective writings and discoveries;Does our current system of patents, especially software patents, "promote the progress of science and the useful arts?" The answer is obvious. It does not. Is it obvious enough for the Supreme Court to go against the wishes of the "intellectual property nomenklatura" of this country, with their fictitious billions of dollars on their balance sheets? Maybe. We'll see. Another interesting question is this. On the day after all those patents are invalidated, what will the stock market do? It will be interesting to see....
Sunday, January 25, 2009
Trustedness in Ubiquity and Other Places
I have started to use Ubiquity and it is, of course, as amazing as people have been saying it is. And I see questions being raised about how one gets new commands and how one can trust sources for new commands. I hope that, as these questions get answered, the answers can apply to other areas of concern within Mozilla.
Almost two years ago, I was asking Window Snyder why the add-ons on AMO all had warnings from lack of certificates or authentication. It seemed that MoCo could not decide how to decide whether an add-on is "certifiably safe" or not. Perhaps there is a way to determine whether a command is "certifiably safe" or not. I have a feeling that certifying safety falls in a weird area between what the community around Mozilla can do and what the corporation feels that it should do. When MoCo takes off its nice and fuzzy gloves and puts on its "corporate" hat, what reason do they have for taking on this risk? These kinds of risks are notoriously hard to judge. Or rather, one can see when a problem is less likely to occur, but one can never guarantee there will never be a problem and one can never find a limit to how much damage might be caused. So, there is a clear benefit of moderate import and a slight risk but with no way to guess the cost. A corporation which has to show due diligence will probably not sign up for this risk.
I hope I am wrong. Perhaps this is a way to certify these. And maybe a "casual" certification will work. Sort of like saying, "it is not certified, but this add-on is up on AMO and we like the developer and you should like the developer too but we're not responsible for any problems and yadda, yadda, yadda...", and so on down into the fine print. And maybe this works well enough for everyone, except for dealing with the occasionally nasty security dialog.
But it also seems obvious that the more places one needs trusted content, or trusted sites, or trusted chrome, the more ways there are to stub one's toes. I guess we'll see.
Almost two years ago, I was asking Window Snyder why the add-ons on AMO all had warnings from lack of certificates or authentication. It seemed that MoCo could not decide how to decide whether an add-on is "certifiably safe" or not. Perhaps there is a way to determine whether a command is "certifiably safe" or not. I have a feeling that certifying safety falls in a weird area between what the community around Mozilla can do and what the corporation feels that it should do. When MoCo takes off its nice and fuzzy gloves and puts on its "corporate" hat, what reason do they have for taking on this risk? These kinds of risks are notoriously hard to judge. Or rather, one can see when a problem is less likely to occur, but one can never guarantee there will never be a problem and one can never find a limit to how much damage might be caused. So, there is a clear benefit of moderate import and a slight risk but with no way to guess the cost. A corporation which has to show due diligence will probably not sign up for this risk.
I hope I am wrong. Perhaps this is a way to certify these. And maybe a "casual" certification will work. Sort of like saying, "it is not certified, but this add-on is up on AMO and we like the developer and you should like the developer too but we're not responsible for any problems and yadda, yadda, yadda...", and so on down into the fine print. And maybe this works well enough for everyone, except for dealing with the occasionally nasty security dialog.
But it also seems obvious that the more places one needs trusted content, or trusted sites, or trusted chrome, the more ways there are to stub one's toes. I guess we'll see.
Thursday, January 08, 2009
Amusing iPhone Sound Volume Interface
I waited long enough to be almost the last multicellular organism on the planet that did not have an iPhone. Well, we share our phone plan with my wife's parents and my father-in-law was hot for an iPhone and so here we are.
Some of the interface ideas in it are amazing. Then some are, well, something else.
Everybody has seen the thing where you turn the iPhone on its side and the app that is running rotates. I was looking at the calculator in portrait mode and I was just, literally, seconds away from pointing out I would need some scientific calculator stuff and then turned in sideways and there it is. Very cool.
But the interface for setting the sound volume has a strangeness. For one thing, you do not hear a tone that increases in volume as you increase the volume. You just have to eye-ball the volume indicator. Really. There is no auditory feedback for changing the sound volume. It really boggles the mind.
Then you turn it sideways. The hardware does not change its behavior. So, picture this. In portrait mode you press the down side of the toggle and the sound goes down and a visual "volume progress bar" thing slides to the left. Push on the up toggle, the volume goes up and the "volume progress bar" thing slides to the right. So far, so good. But turn it sideways and you press on what is now the right side of the switch and in my "right-hand-is-right-ish" view, this should make the sound increase. But the volume decreases and the "volume progress bar" slides to the left. And if you press on the left hand side of the toggle, the volume increases and the sound goes up.
I cannot decide if it is my brain that is wrong or, is it possible they just thought it would be ok to respond backwards?
Some of the interface ideas in it are amazing. Then some are, well, something else.
Everybody has seen the thing where you turn the iPhone on its side and the app that is running rotates. I was looking at the calculator in portrait mode and I was just, literally, seconds away from pointing out I would need some scientific calculator stuff and then turned in sideways and there it is. Very cool.
But the interface for setting the sound volume has a strangeness. For one thing, you do not hear a tone that increases in volume as you increase the volume. You just have to eye-ball the volume indicator. Really. There is no auditory feedback for changing the sound volume. It really boggles the mind.
Then you turn it sideways. The hardware does not change its behavior. So, picture this. In portrait mode you press the down side of the toggle and the sound goes down and a visual "volume progress bar" thing slides to the left. Push on the up toggle, the volume goes up and the "volume progress bar" thing slides to the right. So far, so good. But turn it sideways and you press on what is now the right side of the switch and in my "right-hand-is-right-ish" view, this should make the sound increase. But the volume decreases and the "volume progress bar" slides to the left. And if you press on the left hand side of the toggle, the volume increases and the sound goes up.
I cannot decide if it is my brain that is wrong or, is it possible they just thought it would be ok to respond backwards?
Thursday, December 11, 2008
Add-ons Interacting Badly? Nope. report from AddOnCon...
I just wanted to call this out. I am at the Add-On-Con in Mountain View today. The keynote was good. Great questions, good back-and-forth, interesting responses.
I asked the panelists (reps from Conduit, http://www.oneriot.com/, http://www.alexa.com/, http://www.adaptiveblue.com/, http://www.cooliris.com/) how much of their time or mental energy is taken up by dealing with confusions or bugs from cross-addon interactions.
I see this as a, theoretically, very serious problem. It was interesting, though, that the panelists said things like (paraphrasing):
- "browser upgrades are more of an issue. MS is bad about this and Mozilla is much better"
- "this does take up time, but the problems have gotten better"
- "Symantec should not try to clean up people's registry"
- "there are generic best practices and these could be more publicized"
I think the responses I heard speak well of how Mozilla has addressed or is addressing this issue. Considering how huge the problem could (again, theoretically) be, it is great that people who are actually relying on their add-ons to make money do not seem to be very upset or worried about it.
I asked the panelists (reps from Conduit, http://www.oneriot.com/, http://www.alexa.com/, http://www.adaptiveblue.com/, http://www.cooliris.com/) how much of their time or mental energy is taken up by dealing with confusions or bugs from cross-addon interactions.
I see this as a, theoretically, very serious problem. It was interesting, though, that the panelists said things like (paraphrasing):
- "browser upgrades are more of an issue. MS is bad about this and Mozilla is much better"
- "this does take up time, but the problems have gotten better"
- "Symantec should not try to clean up people's registry"
- "there are generic best practices and these could be more publicized"
I think the responses I heard speak well of how Mozilla has addressed or is addressing this issue. Considering how huge the problem could (again, theoretically) be, it is great that people who are actually relying on their add-ons to make money do not seem to be very upset or worried about it.
Sunday, November 09, 2008
Freebase HackDay in SF
It has only a slight connection to Firefox, but I did meet people there doing database-ish things with Firefox extensions to provide a whole experience....
Freebase (http://www.freebase.com) is an odd service. It is a wiki-like database. Anybody can go in, look at a table and decide there needs to be another column on it and add a new column. Anyone can put new data in. Anyone can create new "types" (like tables). There are APIs for managing time information and geo information and all that kind of stuff. They have created the concept of a "Base" which sort of combines a social situation with a custom view of data. It allows a better separation between the model and the view.
The tools are mostly Javascript or Google-app based and they work pretty well.
And how many places can one go to and talk about the re-contextualization of socially-constructed semi-structured database tables into dynamic entities and not have people get glassy-eyed and start looking for open doors or windows to jump out of?
Freebase (http://www.freebase.com) is an odd service. It is a wiki-like database. Anybody can go in, look at a table and decide there needs to be another column on it and add a new column. Anyone can put new data in. Anyone can create new "types" (like tables). There are APIs for managing time information and geo information and all that kind of stuff. They have created the concept of a "Base" which sort of combines a social situation with a custom view of data. It allows a better separation between the model and the view.
The tools are mostly Javascript or Google-app based and they work pretty well.
And how many places can one go to and talk about the re-contextualization of socially-constructed semi-structured database tables into dynamic entities and not have people get glassy-eyed and start looking for open doors or windows to jump out of?
Sunday, June 22, 2008
Mozilla Dev Kit ... and Scratchbox?
Seeing a post on the Mozilla Developer Kit (MozDevKit? MDK?) has gotten me very psyched. I have been trying to add some things to the developer doc site. I see, for example, a lot of really good information in blog posts and then the corresponding DevMo pages are ... not so up-to-date. In general, there is much that can be done to make developing Mozilla more accessible to people and MDC does not get as much love as it deserves from people who are doing development and should therefore be able to write. But they probably have no time to doc because they are, you know, coding. It is a conundrum.
But build environments are complicated. How can setting up such an environment be made easy?
Can a Mozilla development kit can be set up in a trackable, verifiable, chroot-ed environment using a tool such as scratchbox? I have been trying to get a xulrunner (FF Mobile) build working to an embedded device using scratchbox and it has been challenging, to say the least, but interesting. Tools like scratchbox or crosstool seem a very good idea. And every production build environment, such as the one I used while I was in the Dev Tools group at Apple, uses a verifiable, chroot-ed environment. It is really hard to get reproducibility without it, and without reproducibility, it is really hard to help anybody who has problems. This is why most responses to build issues on the newsgroups consist of 'please set up X, Y, and Z, and do A, B and C, and see if that helps....'
Also, the usual use of scratchbox is to build on host A for a different architecture, target B. But A and B can actually be the same. MoCo builds Linux binaries on Linux and Mac OS X binaries on Mac OS X, but that does not have to be so. Of course, scratchbox is very Linux-centric. And I see that a Linux version of the MDK is the first item listed on the aforementioned blog post. This is probably true because Linux is amenable to scripted, verifiable building. But it would be interesting (perhaps for only me) to consider how a scratchbox on Linux could build Mac OS X binaries, or how a scratchbox on Mac OS X could build binaries for either Linux or the Mac. And of course, some might be interested in making Windows development possible, but that is way beyond my bailiwick. Yo no hablo Microsoft and I am just fine with that. Can you imagine, for example, getting the Microsoft development tools into a scratchbox environment? I cannot, and I am sure it would be ugly, but it might be possible.)
Downloading a single file, launching it and then finding oneself in a known, trackable, verifiable virtual host for building Mozilla apps seems a compelling opportunity.
But build environments are complicated. How can setting up such an environment be made easy?
Can a Mozilla development kit can be set up in a trackable, verifiable, chroot-ed environment using a tool such as scratchbox? I have been trying to get a xulrunner (FF Mobile) build working to an embedded device using scratchbox and it has been challenging, to say the least, but interesting. Tools like scratchbox or crosstool seem a very good idea. And every production build environment, such as the one I used while I was in the Dev Tools group at Apple, uses a verifiable, chroot-ed environment. It is really hard to get reproducibility without it, and without reproducibility, it is really hard to help anybody who has problems. This is why most responses to build issues on the newsgroups consist of 'please set up X, Y, and Z, and do A, B and C, and see if that helps....'
Also, the usual use of scratchbox is to build on host A for a different architecture, target B. But A and B can actually be the same. MoCo builds Linux binaries on Linux and Mac OS X binaries on Mac OS X, but that does not have to be so. Of course, scratchbox is very Linux-centric. And I see that a Linux version of the MDK is the first item listed on the aforementioned blog post. This is probably true because Linux is amenable to scripted, verifiable building. But it would be interesting (perhaps for only me) to consider how a scratchbox on Linux could build Mac OS X binaries, or how a scratchbox on Mac OS X could build binaries for either Linux or the Mac. And of course, some might be interested in making Windows development possible, but that is way beyond my bailiwick. Yo no hablo Microsoft and I am just fine with that. Can you imagine, for example, getting the Microsoft development tools into a scratchbox environment? I cannot, and I am sure it would be ugly, but it might be possible.)
Downloading a single file, launching it and then finding oneself in a known, trackable, verifiable virtual host for building Mozilla apps seems a compelling opportunity.
Friday, May 16, 2008
the age of bugs, and other useless information...
In a recent post, dbaron suggested that people inappropriately judge Mozilla by, for example, the age of the bugs that one can see. I think he is right, but I think there is a reason for this. It is usually completely impossible to look at a bug and figure out whether it will be fixed or not. There are long-standing reasons for the use of nobody as an assignee, but this can be un-helpful.
Mozilla code development is socially driven. This may seem obvious, but the effects of this are not necessarily obvious, especially to someone in coming from commercial software. Look at the recent revisions of the module ownership system and you can see how tenuous the ownership of code can be. Nobody has to care about any bug. Or, to say it another way, only 'nobody' actually has to care about the vast majority of bugs.
It is very hard to look at a bug and see who actually cares about it. No. I will not gripe about bugzilla. Really. But I will just say that anything in a bug is not what it says, but how that is looked at by which group does the work. Priority, Confirmed, and many other terms mean different things to different groups of people. And everyone seems to be ok with that.
I have filed many bugs thinking that Firefox should just 'do the right thing' and that people would want to know. Is still have this idealism at times, but I recognize the other viewpoint as being valid. It may be true that one should not fix something that does not need to be fixed.
And as dbaron has pointed out to me many times, one is always welcome to file a patch. And, actually, that turns out to be the key to many things. I used to think there was value in asking about a bug to understand it. I used to think there was value in discussing a solution before creating a patch. But, as a practical matter, the number of people willing to talk about making changes is vastly more huge than the number of people who will make changes. So, considered questions almost always get silence while patches that are crap get responses. If I have 10+ years of database experience and ask a question about sqlite use by Places, and a 12-year-old asks a question with a patch he came up with in five minutes, who will get a response? Who will be more likely to get something started on a bug? It seems obvious to me now.
So when in doubt, submit a patch. Any patch.
So, this leaves a question. How does Mozilla want to manage bugs submitted by or read by or tracked by non-developers? It seems clear that bugzilla is really best only for developers. Asking users to look at bugzilla and make sense of what they see is, I would suggest, not realistic. Maybe the idea behind Hendrix needs to be developed further. A lot of what is in bugzilla looks like graffiti in a train station. So maybe something is needed manages that graffiti and relates it to actual bugs that people may actually work on. But then, the people who do the work do not mind looking at the graffiti and just working on what they talk about. They seem to know which ones are actually significant, so why fix it if it's not broken?
Mozilla code development is socially driven. This may seem obvious, but the effects of this are not necessarily obvious, especially to someone in coming from commercial software. Look at the recent revisions of the module ownership system and you can see how tenuous the ownership of code can be. Nobody has to care about any bug. Or, to say it another way, only 'nobody' actually has to care about the vast majority of bugs.
It is very hard to look at a bug and see who actually cares about it. No. I will not gripe about bugzilla. Really. But I will just say that anything in a bug is not what it says, but how that is looked at by which group does the work. Priority, Confirmed, and many other terms mean different things to different groups of people. And everyone seems to be ok with that.
I have filed many bugs thinking that Firefox should just 'do the right thing' and that people would want to know. Is still have this idealism at times, but I recognize the other viewpoint as being valid. It may be true that one should not fix something that does not need to be fixed.
And as dbaron has pointed out to me many times, one is always welcome to file a patch. And, actually, that turns out to be the key to many things. I used to think there was value in asking about a bug to understand it. I used to think there was value in discussing a solution before creating a patch. But, as a practical matter, the number of people willing to talk about making changes is vastly more huge than the number of people who will make changes. So, considered questions almost always get silence while patches that are crap get responses. If I have 10+ years of database experience and ask a question about sqlite use by Places, and a 12-year-old asks a question with a patch he came up with in five minutes, who will get a response? Who will be more likely to get something started on a bug? It seems obvious to me now.
So when in doubt, submit a patch. Any patch.
So, this leaves a question. How does Mozilla want to manage bugs submitted by or read by or tracked by non-developers? It seems clear that bugzilla is really best only for developers. Asking users to look at bugzilla and make sense of what they see is, I would suggest, not realistic. Maybe the idea behind Hendrix needs to be developed further. A lot of what is in bugzilla looks like graffiti in a train station. So maybe something is needed manages that graffiti and relates it to actual bugs that people may actually work on. But then, the people who do the work do not mind looking at the graffiti and just working on what they talk about. They seem to know which ones are actually significant, so why fix it if it's not broken?
Sunday, March 30, 2008
A Really Neat Test Reusability Situation
I had something happen yesterday which makes me think there might be hope. For my brain and how I sometimes fail to keep track of things. I was asked, in a bug I filed a while back, if the failure was reproducible.
I do not why it was not reproducible earlier. I hardly ever find out why people do not see the bugs I see. I filed the bug and it got the usual responses: "works for me", "what are the running? are you sure?", "i see something weird", "why are we checking this?", "can you attach more information?", "did you configure the thingamagig to build the whatamacallit?", "can you attach a lot more information?". It just gets really ... exhausting. Actually, this particular bug was not as bad as some others. And it is nice when someone can actually reproduce something I filed.
But right now, if you look in my ~/mo directory, you see 3 different builds of the browser, a half-dozen nightlies (some a few months old), a couple of calendar builds, a few xulrunners, an nspr build (what the heck was I doing with that?), a re-usable profile directory, and other random stuff. So, do I still see my bug? I look in the directory and and it is, again, exhausting, even to just think about.
Then I saw something.
tests_20080106_160400/
You know, I was talking about a re-usable test product, wasn't I? Oh, yeah.
% cd tests_20080106_160400
% ls
dist/ runReftests* testing/ xpcshell-simple/
%
% ./runReftests ~/mo/browser_20080327_235255/dist/MinefieldDebug.app/Contents/MacOS/firefox ~/mo/debug.mozilla_20080106_173138_PST
Holy test failures, Batman! It worked! I just gave it a fairly recent build and that re-usable profile directory I mentioned and there it is. Lots of failures.
Now, I am thinking again of that standalone test product I was mentioning. Once again, the buzzing in my head is beginning. There is apparently a new way to build a product out of the Mozilla build system. Create a directory, put some stuff in it, and voila! A new product. Now, to find the documentation for this wonderful new capability. Ok, I am sure that people are busy. Is it fair to ask them to document things? Should I ask a question in the newsgroups? I will just get that response that I really hate so much: "what exactly are you trying to do?". I think I was trying to ask a question. Again, it can just be exhausting. I even created an MDC page. Seeing a place for something like this to to be documented, someone who knows what is going on might, you know, document something. Not even a nibble on that yet. O well. You can lead them to water....
And, finally, I have to do homework today. My Stats and PDE homework is not doing itself. And why don't I get more Mozilla stuff done?
I do not why it was not reproducible earlier. I hardly ever find out why people do not see the bugs I see. I filed the bug and it got the usual responses: "works for me", "what are the running? are you sure?", "i see something weird", "why are we checking this?", "can you attach more information?", "did you configure the thingamagig to build the whatamacallit?", "can you attach a lot more information?". It just gets really ... exhausting. Actually, this particular bug was not as bad as some others. And it is nice when someone can actually reproduce something I filed.
But right now, if you look in my ~/mo directory, you see 3 different builds of the browser, a half-dozen nightlies (some a few months old), a couple of calendar builds, a few xulrunners, an nspr build (what the heck was I doing with that?), a re-usable profile directory, and other random stuff. So, do I still see my bug? I look in the directory and and it is, again, exhausting, even to just think about.
Then I saw something.
tests_20080106_160400/
You know, I was talking about a re-usable test product, wasn't I? Oh, yeah.
% cd tests_20080106_160400
% ls
dist/ runReftests* testing/ xpcshell-simple/
%
% ./runReftests ~/mo/browser_20080327_235255/dist/MinefieldDebug.app/Contents/MacOS/firefox ~/mo/debug.mozilla_20080106_173138_PST
Holy test failures, Batman! It worked! I just gave it a fairly recent build and that re-usable profile directory I mentioned and there it is. Lots of failures.
Now, I am thinking again of that standalone test product I was mentioning. Once again, the buzzing in my head is beginning. There is apparently a new way to build a product out of the Mozilla build system. Create a directory, put some stuff in it, and voila! A new product. Now, to find the documentation for this wonderful new capability. Ok, I am sure that people are busy. Is it fair to ask them to document things? Should I ask a question in the newsgroups? I will just get that response that I really hate so much: "what exactly are you trying to do?". I think I was trying to ask a question. Again, it can just be exhausting. I even created an MDC page. Seeing a place for something like this to to be documented, someone who knows what is going on might, you know, document something. Not even a nibble on that yet. O well. You can lead them to water....
And, finally, I have to do homework today. My Stats and PDE homework is not doing itself. And why don't I get more Mozilla stuff done?
Saturday, March 29, 2008
Participating in Earth Hour?
Are you participating in Earth Hour? I am, apparently. My wife says that we can and should turn off all lights in the house. We can then turn off all electrical devices (even my Server machine!) and, further, she is convinced we will survive and may perhaps even escape psychological damage.
I am dubious.
If you do not hear back from me, you know why. Good luck.
I am dubious.
If you do not hear back from me, you know why. Good luck.
Monday, January 07, 2008
A Standalone Test Product
What does one need to do to help test Firefox. It turns out that to help very much, it takes a fair amount of effort. Just downloading the latest browser and "doing stuff" with it does provide testing, but it is not very complete. That kind of testing tends to be shallow at best.
Firefox has great automated testing tools built into it, and so one can build a copy of Firefox using '--enable-tests' as a configuration flag. One gets a bunch of standalone executable tests, some xpcshell tests, the mochitest functionality and reftest. There is a lot there to work with.
However, building Firefox can be a pretty hefty requirement. Is it really necessary? One benefit of automated testing is that the more of it that gets done, the more valuable it can be. There are lots of OS versions and machine configurations to worry about. MoCo can either try to have a copy of all those OSes and all those machines, or it can allow the community to meaningfully assist with testing without jumping through all the extra hoops needed to be able to build the browser. After all, the software required to just run tests is much simpler.
In pursuit of this, I am creating a standalone product which can be a test vehicle for testing Firefox. After all, if Firefox is changing every day, should one have to refetch all those tests? One would hope that when Firefox is changing a lot, the tests are not changing, so that the tests can provide confidence for the changes being made.
So far, I have a standalone product that I can use, on my Mac OS X system, to run reftests. There are issues with some of the other technologies that I will try to address. For now, I have taken the last 4 nightly builds and used the same test product on them and got the same result.
- REFTEST UNEXPECTED FAIL: file:///.../testing/reftest/layout/bidi/bidi-000.html
- REFTEST UNEXPECTED FAIL: file:///.../testing/reftest/layout/bidi/bidi-001.html
- REFTEST UNEXPECTED FAIL: file:///.../testing/reftest/layout/bidi/bidi-001-j.html
- REFTEST UNEXPECTED FAIL: file:///.../testing/reftest/layout/bidi/mixedChartype-02.html
- REFTEST UNEXPECTED FAIL: file:///.../testing/reftest/layout/bidi/mixedChartype-02-j.html
- REFTEST UNEXPECTED FAIL: file:///.../testing/reftest/layout/line-breaking/currency-2.html
There may already be bugs on these test failures. It is hard to tell. I cannot seem to find the obvious way to locate bugs filed against automated tests.
The test product is based on the contents of the "
There are issues, already, that make it a little difficult to just grab this test product and put it up in a shareable location for other Mac OS X users. For one thing, script bits need to be put inside the application bundle of the app being tested. For reftest, it is only three files that need to be put inside the ".app/Contents" directory, but it is awkward to do manually.
Looking at mochitests, I can already see problems. The tests all assume that they can do something like "../../../dist/bin/testExecutable". There is no reason they need to assume that, but they all do. Does the xpcshell executable that runs the tests need to be the same build as the Firefox browser itself? I would say no, but that is the way it has always been done. Until issues like these are teased apart, there will have to be lots of workarounds.
If anyone has any suggestions, I am open to them. If MoCo wants to make automated testing available to a much larger group of people, without massively increasing their app download times, it seems that a standalone test product would be one way to do it.
Firefox has great automated testing tools built into it, and so one can build a copy of Firefox using '--enable-tests' as a configuration flag. One gets a bunch of standalone executable tests, some xpcshell tests, the mochitest functionality and reftest. There is a lot there to work with.
However, building Firefox can be a pretty hefty requirement. Is it really necessary? One benefit of automated testing is that the more of it that gets done, the more valuable it can be. There are lots of OS versions and machine configurations to worry about. MoCo can either try to have a copy of all those OSes and all those machines, or it can allow the community to meaningfully assist with testing without jumping through all the extra hoops needed to be able to build the browser. After all, the software required to just run tests is much simpler.
In pursuit of this, I am creating a standalone product which can be a test vehicle for testing Firefox. After all, if Firefox is changing every day, should one have to refetch all those tests? One would hope that when Firefox is changing a lot, the tests are not changing, so that the tests can provide confidence for the changes being made.
So far, I have a standalone product that I can use, on my Mac OS X system, to run reftests. There are issues with some of the other technologies that I will try to address. For now, I have taken the last 4 nightly builds and used the same test product on them and got the same result.
- REFTEST UNEXPECTED FAIL: file:///.../testing/reftest/layout/bidi/bidi-000.html
- REFTEST UNEXPECTED FAIL: file:///.../testing/reftest/layout/bidi/bidi-001.html
- REFTEST UNEXPECTED FAIL: file:///.../testing/reftest/layout/bidi/bidi-001-j.html
- REFTEST UNEXPECTED FAIL: file:///.../testing/reftest/layout/bidi/mixedChartype-02.html
- REFTEST UNEXPECTED FAIL: file:///.../testing/reftest/layout/bidi/mixedChartype-02-j.html
- REFTEST UNEXPECTED FAIL: file:///.../testing/reftest/layout/line-breaking/currency-2.html
There may already be bugs on these test failures. It is hard to tell. I cannot seem to find the obvious way to locate bugs filed against automated tests.
The test product is based on the contents of the "
_tests" directory as built with the '--enable-tests' flag, with some minor changes. Also, the contents of the directory are actually files, not links back into a source tree. The basic directory structure right now looks as so:
tests\
Minefield.app/Contents/MacOS/chrome/reftest.jar
Minefield.app/Contents/MacOS/chrome/reftest.manifest
Minefield.app/Contents/MacOS/components/reftest-cmdline.js
testing\
mochitest\
reftest\
xpcshell-simple\
There are issues, already, that make it a little difficult to just grab this test product and put it up in a shareable location for other Mac OS X users. For one thing, script bits need to be put inside the application bundle of the app being tested. For reftest, it is only three files that need to be put inside the ".app/Contents" directory, but it is awkward to do manually.
Looking at mochitests, I can already see problems. The tests all assume that they can do something like "../../../dist/bin/testExecutable". There is no reason they need to assume that, but they all do. Does the xpcshell executable that runs the tests need to be the same build as the Firefox browser itself? I would say no, but that is the way it has always been done. Until issues like these are teased apart, there will have to be lots of workarounds.
If anyone has any suggestions, I am open to them. If MoCo wants to make automated testing available to a much larger group of people, without massively increasing their app download times, it seems that a standalone test product would be one way to do it.
Wednesday, December 05, 2007
A Systematic Look at Testing, Perhaps
Seeing the release of Firefox 2.0.0.10, followed by the rapid release of 2.0.0.11, made me wonder about how regression testing is going at Mozilla. Of course, there are no simple answers to be found for any of the issues. We all want less bugs and for bugs to get fixed more quickly. Nor am I feeling that there is some deep and dark hidden flaw that is coming to the fore here. Things could be better. No shock there. Things could be worse. Lots of people care enough to make sure they are not. And MoCo moves from one day to the next. We all love the products that come out of Mozilla, and as with anything one cares about, we are frustrated about some things. Such is life.
But with every new test harness being talked about and with every new set of tests being brought in, the same questions and issues seem to come up for me. Every new test harness I see being developed for MoCo technologies bring me hope, but it is rarely clear why the last one is not being talked about. The same issues seem to be stumbled over. What happened to the lessons learned in the past? One problem with wiki-based communities is that people talk a lot about what they are doing. People tend not to talk about what they are not doing. Search for any kind of solution in Mozilla's information space, in any problem area, and one finds at least four or five different efforts. Only one or two may be current, but nothing gets written about why the others are not moving forward, or why they failed. It may just be against our natures to talk about things that did not work. One just has to puzzle out the things that are real from the things that just look real.
In testing, it often seems to me that one needs to be clear about what kind of tests one wants, who can create, develop, or maintain what kinds of tests, and why different kinds of tests should or should not be run. If one is not clear about these things, tests get developed which do not get run, tests get run but they do not exercise the right things, or their results get ignored, and lots of people might be working hard to no good effect. The result is that there is no joy.
Questions:
(How hard is it to/Who can) develop a new test?
(How hard is it to/Who can) modify an existing test?
(How hard is it to/Who can) identify a feature or fault for which a test should be created?
(How hard is it to/Who can) evaluate the benefit of creating a test of the effectiveness of running a particular test over time?
(How hard is it to/Who can) run a test?
(How hard is it to/Who can) see that a test has failed?
(How hard is it to/Who can) identify the cause of a test failure, or interpret the failure?
I would suggest that each of these questions defines an axis in the "problem space", the space of possibilities to in which to locate problems and suggest solutions about Mozilla products. There are risks to be managed in the Firefox source base, and possibilities to be enabled. The cost of the risk to be averted and the possible improvement to the product that are enabled have to be measured against the costs of testing. I think that answers to these questions can be used to categorize various quality efforts and give a way to judge whether testing is doing what it should do and how much should or should not be spent on it.
I was going to take a stab at answering the one or more of questions above, but I will post this as a start. Answers can come later, especially since I do not know all of the answers. Nor am I sure I know all the questions. And if anyone wants to suggest either questions or answers, please do. And if anyone can think of a way to draw a representation of a, say, 12-dimensional space, so I can draw pictures based on something like the questions above, let me know that too.
Thanks. More to come.
But with every new test harness being talked about and with every new set of tests being brought in, the same questions and issues seem to come up for me. Every new test harness I see being developed for MoCo technologies bring me hope, but it is rarely clear why the last one is not being talked about. The same issues seem to be stumbled over. What happened to the lessons learned in the past? One problem with wiki-based communities is that people talk a lot about what they are doing. People tend not to talk about what they are not doing. Search for any kind of solution in Mozilla's information space, in any problem area, and one finds at least four or five different efforts. Only one or two may be current, but nothing gets written about why the others are not moving forward, or why they failed. It may just be against our natures to talk about things that did not work. One just has to puzzle out the things that are real from the things that just look real.
In testing, it often seems to me that one needs to be clear about what kind of tests one wants, who can create, develop, or maintain what kinds of tests, and why different kinds of tests should or should not be run. If one is not clear about these things, tests get developed which do not get run, tests get run but they do not exercise the right things, or their results get ignored, and lots of people might be working hard to no good effect. The result is that there is no joy.
Questions:
(How hard is it to/Who can) develop a new test?
(How hard is it to/Who can) modify an existing test?
(How hard is it to/Who can) identify a feature or fault for which a test should be created?
(How hard is it to/Who can) evaluate the benefit of creating a test of the effectiveness of running a particular test over time?
(How hard is it to/Who can) run a test?
(How hard is it to/Who can) see that a test has failed?
(How hard is it to/Who can) identify the cause of a test failure, or interpret the failure?
I would suggest that each of these questions defines an axis in the "problem space", the space of possibilities to in which to locate problems and suggest solutions about Mozilla products. There are risks to be managed in the Firefox source base, and possibilities to be enabled. The cost of the risk to be averted and the possible improvement to the product that are enabled have to be measured against the costs of testing. I think that answers to these questions can be used to categorize various quality efforts and give a way to judge whether testing is doing what it should do and how much should or should not be spent on it.
I was going to take a stab at answering the one or more of questions above, but I will post this as a start. Answers can come later, especially since I do not know all of the answers. Nor am I sure I know all the questions. And if anyone wants to suggest either questions or answers, please do. And if anyone can think of a way to draw a representation of a, say, 12-dimensional space, so I can draw pictures based on something like the questions above, let me know that too.
Thanks. More to come.
Wednesday, October 10, 2007
Extension Development, and Trials and Tribulations Thereof
Well, I am almost done with an extension I am developing for a third-party company. Wow! Was this ever harder than I thought it would be....
I had some slightly complicated things in the extension. 2.5K lines of javascript, a custom XPCOM component, a status bar icon, a toolbar popup button, a sidebar, and a partridge in a pear tree thrown in for good measure. The app was crashing on exit. Actually only FF 2.* was crashing. FF 3.* was fine.
So, I am doing a bunch of different kinds of allocations and there are listeners and so on. I figured I was doing something wrong with the memory. Much staring at the code. Much re-reading of dbaron's docs on this stuff. Much more staring at code....
Turned out it was this:
I thought that all this memory stuff might have a problem, and it turns out to be something bone simple! It is amazing what taking a machete to your code can show you. Along the way, an amusing thing happened. I took the image attribute off the toolbarbutton and I got this:
And someone said this was ok! I might try to guess at the logic, but I cannot make myself do it. Obviously, some people are very immersed in how XUL gets rendered. I hope I can learn enough to understand it. I hope I never forget that its contortions are, after all, contortions.
Next things to do now that this monkey is almost off my back:
- do an extension for rule-based qualification of XUL, because you need something to tell you that you can have A, B, and C together, but C makes B have no effect, and C without A does something totally different. Look at a given XUL reference. It inherits all its parent's attributes. Now, how many have any effect? How many break everything? There has got to be a way to get information about this.
- figure out something to help me search bugzilla. I looked for bugs on this many times and did not find it. Maybe it is because the relevant bug was marked for Windows. Maybe it was because the title mentioned <menupopup> and not <toolbarbutton>. Maybe it was because the title said it happened on window close and I was searching for "quit". I do not know. I just know I truly hate trying to find things in bugzilla. But when I suggest changes to bugzilla, they seem to hate that even more. I have no idea why. So, I just obviously need to construct tools to help me get around this thing. There has got to be a better way to find bugs than creating new bugs and letting gavin find the dupes. For one thing, this is not fair to gavin, or neil, or reed, or whoever it is.
- and some other things I am sure I have forgotten. We'll see.
I had some slightly complicated things in the extension. 2.5K lines of javascript, a custom XPCOM component, a status bar icon, a toolbar popup button, a sidebar, and a partridge in a pear tree thrown in for good measure. The app was crashing on exit. Actually only FF 2.* was crashing. FF 3.* was fine.
So, I am doing a bunch of different kinds of allocations and there are listeners and so on. I figured I was doing something wrong with the memory. Much staring at the code. Much re-reading of dbaron's docs on this stuff. Much more staring at code....
Turned out it was this:
<toolbarbutton id="id1" type="menu" popup="id2">
<menupopup id="id2" />
</toolbarbutton>
I thought that all this memory stuff might have a problem, and it turns out to be something bone simple! It is amazing what taking a machete to your code can show you. Along the way, an amusing thing happened. I took the image attribute off the toolbarbutton and I got this:
And someone said this was ok! I might try to guess at the logic, but I cannot make myself do it. Obviously, some people are very immersed in how XUL gets rendered. I hope I can learn enough to understand it. I hope I never forget that its contortions are, after all, contortions.
Next things to do now that this monkey is almost off my back:
- do an extension for rule-based qualification of XUL, because you need something to tell you that you can have A, B, and C together, but C makes B have no effect, and C without A does something totally different. Look at a given XUL reference. It inherits all its parent's attributes. Now, how many have any effect? How many break everything? There has got to be a way to get information about this.
- figure out something to help me search bugzilla. I looked for bugs on this many times and did not find it. Maybe it is because the relevant bug was marked for Windows. Maybe it was because the title mentioned <menupopup> and not <toolbarbutton>. Maybe it was because the title said it happened on window close and I was searching for "quit". I do not know. I just know I truly hate trying to find things in bugzilla. But when I suggest changes to bugzilla, they seem to hate that even more. I have no idea why. So, I just obviously need to construct tools to help me get around this thing. There has got to be a better way to find bugs than creating new bugs and letting gavin find the dupes. For one thing, this is not fair to gavin, or neil, or reed, or whoever it is.
- and some other things I am sure I have forgotten. We'll see.
Subscribe to:
Posts (Atom)
