At my company, we have a library that allows us to read data from a content management server. The library will check for new content periodically. This allows us to make content changes (change the label on a button or the legal disclaimers on the bottom of the page) without going through a full code elevation. We just change the content in the CMS and the JVMs automatically pick up the content change.
This library was not implemented in a testable way, however. Instead of being a Spring bean, or a singleton, or another of a hundred other ways, the developers show to make it a static class. The class has all static methods. We can still technically mock the class; we just need to use a tool like PowerMock. This class is used all over the place, so what should be simple unit tests end up containing dozens of lines of mock statements.
I was tasked to make a change to a REST call. The change needed to be made, but it was a very risky change. I decided to heavily unit test the REST call to make sure my change didn't break anything. If the content library was written in a testable way, I would have the opportunity to create my own implementation of it. In that implementation, I would return the content chunks I care about, and ignore the content chunks I don't care about. Instead, the code was written statically. I had to use PowerMock to mock out every single time that REST call called the content system. I cared about 3 pieces of content. I had to mock out 30 pieces of content, per unit test. I had 27 test cases. I put all the mocking for the content I don't care about in a common method that each test case could call. This isn't the worst part of the situation though.
A few weeks later, someone else had to make changes to the same REST call. Their changes had nothing to do with my changes. The build broke because my unit tests were failing. The unit tests didn't actually find a problem. What they found was new content being requested that the mocking system didn't know about. This is why so many developers hate unit tests. This particular developer spent more time trying to fix my unit test than writing the code they were supposed to make. This gave me a bad reputation because I'm the guy who wrote the crappy unit test.
Fast forward even more and another developer is making changes to the same REST call. This time they are making changes in the code that I made changes in. Once again the unit tests fail. This time, they fail for two reasons: 1) new content and 2) a regression was introduced. Since these unit tests have a reputation for being brittle and the developer didn't want to deal with unit tests that give false positives, he removed the unit tests. This was a major regression that would have cost lots of money to fix if it made its way into production. Luckily it was caught in manual testing.
Automated unit testing can be a wonderful thing. It can save lots of money. There is a big but, though. It can only do those things when it is done right. Forcing the wrong type of unit testing makes the situation worse.
Friday, January 30, 2015
Monday, January 26, 2015
Build all the things! (and wait for it to fail)
Continuous integration is a great concept. Within a few minutes of making a change, you can get quick feedback about potential problems with your change. You can run unit tests, which helps spot problems internal to your module. You can run integration tests, which helps find problems between your module and any modules you depend on. You can run static code analysis to attempt to find bugs in your code. How about code complexity analysis, or dependency analysis, or a build violations checker. Well, as long as those run fast, I guess, maybe. How about installing your war file into Tomcat, starting up a browser and running a browser automation tool to validate that it still works. Hmm....this is starting to be a lot. What ever happened to quick feedback?
Oh, you want quick feedback? Then we can just at a time limit to your Jenkins job, so if it runs more than 9 minutes, then your job fails? How about that for quick feedback! Well, if my jobs are going to fail because too much is running during the builds, I can just reduce what runs in those builds. Brilliant! What....I don't actually have access to reduce the number of things that occur during the build? The team that mandated that builds fail after 9 minutes is the same team that mandates that all those build steps must be done? The same team that gives us a Jenkins instance that 10 executors and a backlog of 60+ items at all times?
When you try to measure everything, you end up measuring nothing. This is my life.
Oh, you want quick feedback? Then we can just at a time limit to your Jenkins job, so if it runs more than 9 minutes, then your job fails? How about that for quick feedback! Well, if my jobs are going to fail because too much is running during the builds, I can just reduce what runs in those builds. Brilliant! What....I don't actually have access to reduce the number of things that occur during the build? The team that mandated that builds fail after 9 minutes is the same team that mandates that all those build steps must be done? The same team that gives us a Jenkins instance that 10 executors and a backlog of 60+ items at all times?
When you try to measure everything, you end up measuring nothing. This is my life.
Friday, January 2, 2015
EInk on a phone. Maybe with Project Ara
I have been talking about EInk with a buddy of mine for months. I want a phone that supports an EInk display. Obviously an EInk display will not work 100% of the time, but if you could hot-swap the screen.....like with Project Ara....then you could have an awesome set. This topic was recently brought up on reddit. I am not the only crazy one that wants an EInk display for a phone.
I see two major benefits for having an optional EInk screen on a phone. The first is battery life. Out of all the components in your phone (antenna, process, RAM) your screen takes up the most battery. EInk displays only require battery when the contents of the screen change. This is why they are great for e-Books. You spend a little electricity to change the screen to display words. Once the words are visible, the screen no longer draws electricity. If you have an EInk display on your phone, then turning on your screen is no longer a big deal. You obviously can't play games, but it is good enough for email, SMS and phone calls.
The second major benefit is using your phone outside in the daylight. LED displays are sometimes hard to see in sunlight. You often have to bump up the brightness just so you can see the screen, taking up even more battery. With an EInk display, you can use your phone outside again!
The question becomes how do you put an EInk display into a phone. The Yota Phone 2 puts an EInk display on the back of the phone, so all you have to do is spin the phone and switch which display gets used. There was a Kickstarter for a second screen that attaches to your phone. This screen is awkward and not very compatible. I think the best bet is with Project Ara. With Project Ara, you could in theory hotswap the screen with one that uses EInk. I can't wait for Project Ara to be released.
I see two major benefits for having an optional EInk screen on a phone. The first is battery life. Out of all the components in your phone (antenna, process, RAM) your screen takes up the most battery. EInk displays only require battery when the contents of the screen change. This is why they are great for e-Books. You spend a little electricity to change the screen to display words. Once the words are visible, the screen no longer draws electricity. If you have an EInk display on your phone, then turning on your screen is no longer a big deal. You obviously can't play games, but it is good enough for email, SMS and phone calls.
The second major benefit is using your phone outside in the daylight. LED displays are sometimes hard to see in sunlight. You often have to bump up the brightness just so you can see the screen, taking up even more battery. With an EInk display, you can use your phone outside again!
The question becomes how do you put an EInk display into a phone. The Yota Phone 2 puts an EInk display on the back of the phone, so all you have to do is spin the phone and switch which display gets used. There was a Kickstarter for a second screen that attaches to your phone. This screen is awkward and not very compatible. I think the best bet is with Project Ara. With Project Ara, you could in theory hotswap the screen with one that uses EInk. I can't wait for Project Ara to be released.
Wednesday, December 31, 2014
No issues with Lollipop on my Nexus 5
A lot of people with the Nexus 5 have been complaining about Lollipop. Some have complained about battery life. One large group of users complained about a memory leak, which Google has checked in a fix for. I have not experienced any of these issues, though. I am currently running 5.0.1 on my Nexus 5. Although I do reboot it from time to time (mostly to play around with Ubuntu Touch), my current uptime is just under 10 days. I multitask heavily on the phone. I have what seems to be an infinite scroll in Task Manager, mostly due to Chrome tabs showing up in there. When my car turns on, RocketPlayer automatically starts playing over Bluetooth. Pandora is always running since I sometimes pause RocketPlayer to listen to Pandora in the car. I have a service that runs to run Text-to-speech to read my incoming SMSes to me while I am driving. I have Google Now configured to always listen to that I can respond to the SMS with Speech-to-text. I have a service that automatically turns on Bluetooth tethering so that my Nexus 7 will automatically get internet when I am away from home. I just opened up Settings and the System was only using 471MB of RAM.
I do consider myself a bit of a power user, so I would expect battery issues and memory leaks to happen to me first, but they haven't. I bring all of this up because of a few comments I read about the memory leak. Some of pointed out that they are not experiencing the memory leak. They are not seeing apps force closing due to running out of RAM. Whenever I see one of those comments, I always see a response saying they aren't using the phone enough to see the issue. Somehow, the unaffected people are not power users and never actually needed the Nexus 5 to begin with. This irritates me to no end.
As a software engineer, I can appreciate that some users have having a problem while others do not. I have seen major bugs only affect small portions of users. Just because most people don't have an issue doesn't mean the bug doesn't exist. Just because some people don't see the bug doesn't mean those people aren't techy enough to see the bug. Attitudes like this make it harder to get effective feedback and make it harder to prioritize the work. It makes it harder to find patterns with the users that are experiencing the issue. These patterns could be helpful to the engineers that are trying to find the bug.
That being said, there are a few reasons why I might not be seeing the issues:
1) I don't play games on my Nexus 5. That is what my Nexus 7 is for.
2) I use (and LOVE) Multirom. In fact, Kitkat is still my "primary" rom, but Lollipop is the default rom.
3) I have USB debugging and developer options on because I do write Android apps
What this post comes down to is your mileage may vary. This is true for all devices/things. Don't let a few loud users convince you that Lollipop doesn't work well on the Nexus 5, just because it didn't work well for them.
I do consider myself a bit of a power user, so I would expect battery issues and memory leaks to happen to me first, but they haven't. I bring all of this up because of a few comments I read about the memory leak. Some of pointed out that they are not experiencing the memory leak. They are not seeing apps force closing due to running out of RAM. Whenever I see one of those comments, I always see a response saying they aren't using the phone enough to see the issue. Somehow, the unaffected people are not power users and never actually needed the Nexus 5 to begin with. This irritates me to no end.
As a software engineer, I can appreciate that some users have having a problem while others do not. I have seen major bugs only affect small portions of users. Just because most people don't have an issue doesn't mean the bug doesn't exist. Just because some people don't see the bug doesn't mean those people aren't techy enough to see the bug. Attitudes like this make it harder to get effective feedback and make it harder to prioritize the work. It makes it harder to find patterns with the users that are experiencing the issue. These patterns could be helpful to the engineers that are trying to find the bug.
That being said, there are a few reasons why I might not be seeing the issues:
1) I don't play games on my Nexus 5. That is what my Nexus 7 is for.
2) I use (and LOVE) Multirom. In fact, Kitkat is still my "primary" rom, but Lollipop is the default rom.
3) I have USB debugging and developer options on because I do write Android apps
What this post comes down to is your mileage may vary. This is true for all devices/things. Don't let a few loud users convince you that Lollipop doesn't work well on the Nexus 5, just because it didn't work well for them.
Monday, December 29, 2014
Sony's 300 billion dollar "mistake"
As of 12/28, Sony's The Interview has been streamed 2 million times. That is unfortunate, since Sony might have stolen music for the movie. Various sources are reporting that a 30s clip of Yoon Mi-rae's "Pay Day" was put into the movie without a copyright license. It appears that Sony was in negotiations for the license, but those negotiations fell through. Sony tried to get the license, failed, then put the music into them movie anyways. To me that fits the very definition of "willful infringement". Because the infringement was willful, the statutory damages are $150,000 per infringement. That is $150K x 2M, or $300B. That is a lot.
Should Yoon Mi-rae have a $300B payday? In my opinion, no. The problem is Sony, via the RIAA and the MPAA, has consistently argued yes. Did Sony steal the music? Again, no, but Sony has argued in the past that copyright infringement is stealing. Does it make sense that a movie that grossed $15M should cost a company $300B in fines? No. That doesn't make sense. Once again, though, it makes sense to Sony. If a single person illegally downloads one music track instead of paying the $2 for the track, Sony will demand $150K. It is a statutory damage for "willful infringement". The point of increasing the damages to something so astronomical is to deter infringement. Well, statutory damages hasn't deterred Sony from stealing music.
The bigger problem is this isn't going to amount to a whole lot. Large corporations don't have to follow the same set of rules that people do. Sony will see no problem requesting $150K when it is their intellectual property being "stolen" but will cry foul when they steal someone else's intellectual property. And they will win.
Should Yoon Mi-rae have a $300B payday? In my opinion, no. The problem is Sony, via the RIAA and the MPAA, has consistently argued yes. Did Sony steal the music? Again, no, but Sony has argued in the past that copyright infringement is stealing. Does it make sense that a movie that grossed $15M should cost a company $300B in fines? No. That doesn't make sense. Once again, though, it makes sense to Sony. If a single person illegally downloads one music track instead of paying the $2 for the track, Sony will demand $150K. It is a statutory damage for "willful infringement". The point of increasing the damages to something so astronomical is to deter infringement. Well, statutory damages hasn't deterred Sony from stealing music.
The bigger problem is this isn't going to amount to a whole lot. Large corporations don't have to follow the same set of rules that people do. Sony will see no problem requesting $150K when it is their intellectual property being "stolen" but will cry foul when they steal someone else's intellectual property. And they will win.
Tuesday, September 30, 2014
Amazon: An example on how NOT to run an app store
After a recent release to the app stores, my company discovered a crash in the public area of our Android app. The crash was caused by a race condition in making HTTP requests. It was crashing enough that we decided to deploy a fix to the Google Play and Amazon App stores. Google Play has some issues (Google Play gives a cryptic error when you deploy two versions in "rapid" succession), but we launched in the store. Amazon ended up rejecting us.
When you elevate to a store, you have to provide a demo account so that Apple, Google and Amazon to test out the functionality. During the main release, Apple, Google and Amazon (in that order) were able to login. Then, during the fix release, Google was able to log in just fine. Somehow, in the hours between Google successfully logging in, and Amazon trying to log in, the demo account got locked out. This shouldn't be that big of a deal. We called up our support group to unlock the account. We contacted Amazon to try again. That is when we found out the bad news. They can't just "try again". We have to resubmit our app. That frustrated us for two reasons. First, in large companies, there tends to be some bureaucracy when it comes to changes to a production environment. This is usually done to allow different groups a chance to reschedule or join a change. Another reason resubmitting frustrated us is the Amazon upload process is really painful. For those of you not familiar with Amazon's DRM process, here it is:
1) Upload your APK
2) Amazon adds their DRM jar into your APK, then modifies every Activity to hook into their DRM
3) You download the modified APK
4) You sign the APK with your digital signature
5) You upload the modified APK
In a small shop, this is not a big deal. In a large enterprise, all production changes tend to be executed by a different team. That team tends to have no clue what "signing" is. You end up with multiple people on a conference call since different people need to do different parts of the change.
A few days later (due to a weekend and holiday) we resubmit. After the overnight (Amazon test engineers seem to work in a timezone on the opposite end of the world), we get rejected again! This time:
Bug Description: "The App" was found to be incompatible because of issues with the app’s interaction with Kindle Fire's hibernation feature. "The App" force closes, crashes, or loses user state after the device hibernates and then resumes.
Steps to Reproduce:
1. Install and launch the app.
2. Login using the credentials given.
3. Hibernate the device.
4. Unlock the device, app restarts and reverts back to the login page.
What Amazon calls a bug is actually a security feature that my company's (paranoid) security team said we must have. We detect if you background then foreground the app. If you are on a secure page (a page that requires you to be logged in), then we log you out and send you to the home page to log in again. While our clients find this extremely annoying, we do provide the ability to disable the security feature. You have to opt into it, though.
This is not a new feature. Amazon has accepted our app before with this feature. It seems to me that Amazon's test team is inconsistent with their testing procedures. At this point, I'm wondering why we are even in the Amazon store.
When you elevate to a store, you have to provide a demo account so that Apple, Google and Amazon to test out the functionality. During the main release, Apple, Google and Amazon (in that order) were able to login. Then, during the fix release, Google was able to log in just fine. Somehow, in the hours between Google successfully logging in, and Amazon trying to log in, the demo account got locked out. This shouldn't be that big of a deal. We called up our support group to unlock the account. We contacted Amazon to try again. That is when we found out the bad news. They can't just "try again". We have to resubmit our app. That frustrated us for two reasons. First, in large companies, there tends to be some bureaucracy when it comes to changes to a production environment. This is usually done to allow different groups a chance to reschedule or join a change. Another reason resubmitting frustrated us is the Amazon upload process is really painful. For those of you not familiar with Amazon's DRM process, here it is:
1) Upload your APK
2) Amazon adds their DRM jar into your APK, then modifies every Activity to hook into their DRM
3) You download the modified APK
4) You sign the APK with your digital signature
5) You upload the modified APK
In a small shop, this is not a big deal. In a large enterprise, all production changes tend to be executed by a different team. That team tends to have no clue what "signing" is. You end up with multiple people on a conference call since different people need to do different parts of the change.
A few days later (due to a weekend and holiday) we resubmit. After the overnight (Amazon test engineers seem to work in a timezone on the opposite end of the world), we get rejected again! This time:
Bug Description: "The App" was found to be incompatible because of issues with the app’s interaction with Kindle Fire's hibernation feature. "The App" force closes, crashes, or loses user state after the device hibernates and then resumes.
Steps to Reproduce:
1. Install and launch the app.
2. Login using the credentials given.
3. Hibernate the device.
4. Unlock the device, app restarts and reverts back to the login page.
What Amazon calls a bug is actually a security feature that my company's (paranoid) security team said we must have. We detect if you background then foreground the app. If you are on a secure page (a page that requires you to be logged in), then we log you out and send you to the home page to log in again. While our clients find this extremely annoying, we do provide the ability to disable the security feature. You have to opt into it, though.
This is not a new feature. Amazon has accepted our app before with this feature. It seems to me that Amazon's test team is inconsistent with their testing procedures. At this point, I'm wondering why we are even in the Amazon store.
Wednesday, August 20, 2014
My issue list for Ubuntu Touch 14.10-devel r179 on Nexus 5
This is my issue list from using Ubuntu Touch as my primary mobile operating system for a few days. While this seems like a large list, don't let it scare you away. This list shouldn't tell you that Ubuntu Touch will be a failure. There are a few things to keep in mind. First, Ubuntu Touch isn't even in Beta yet. Second, most of these issues are polish-type problems. It doesn't stop the user from doing something, and it doesn't happen very frequently, but it is noticeable. Polishing is something you tend to do when you get the major issues out of the way. Finally, I am using an unsupported device. The only phone that is officially supported at this point is the Nexus 4. These are all issues I experienced on a Nexus 5.
On to the list:
When I first installed Ubuntu Touch, after the wizard, the system wasn't usable until I rebooted. The landing team knows about this issue.
Sometimes, when I boot, the lock screen never comes up. After a few minutes, I tried hitting the power button thinking the system locked up on boot, and the lock screen came up. It turns out the system booted, but the screen had gone blank due to an idle timeout before the lock screen was available. This only happened twice to me.
When hitting the power button to turn off the screen, the backlight stays on. This drains the battery very fast. I have noticed that it will eventually turn off. This is the one of the two problems that I consider a true blocker for me, since the phone dies way too fast. Other users have noticed this on the Nexus 5 and Nexus 7, but I haven't seen a forum post about it happening on the Nexus 4.
In Settings->Storage, in the list of apps, each app is listed twice.
When upgrading apps, the "Transfers" area in the notification bar shows an entry for each app, but the entry only shows a red X to cancel the transfer. It doesn't tell you anything about it, like the app or the download status.
Sometimes, the action bar of the app slides up by 50% of the height of the action bar. This means the top 1/2 of the action bar is cut off, hidden under the notification bar. Sometimes the app fixes itself, but I mostly open up task manager, swipe to kill, then relaunch. I have seen a bug report of this in Launchpad already.
Sometimes, clicking on an app in the home screen that is already open causes weird things to happen. It does work from time to time. I have seen it just hang there for a few seconds, though. When it hangs there, I usually cannot switch to that app anymore. I have to kill it and restart it. I have seen it kill the app and restart it as well. It will sometimes just do nothing. I get frustrating thinking the app won't launch until I realize that it is already open and I just need to switch to it.
In System Settings, the "Updates available" section doesn't go away after you perform all the updates until you relaunch the System Settings app.
Clicking on System Settings->About this phone->Developer mode crashes the System Settings app. I have no idea what is supposed to be in there, but I was curious.
Open up Messenger, Click in the "Write a message..." text box to bring up the keyboard, hit the power button turn off the screen, hit the power button to bring up the lock screen, swipe to unlock. The bottom row of the app (that has the text box and send button) are still in the higher position (as if the software keyboard was still there), but the software keyboard isn't actually showing. Clicking on the text box does not bring up the keyboard because the text box already has focus. You can get back to normal just by scrolling in the app.
Bluetooth does not work. This is a blocker for me, since I use the Bluetooth on my phone to play music while I drive. This is a known issue. I don't know which devices have Bluetooth working.
Sometimes, launching an app will leave you at the home screen, frozen and unusable, for a long time before actually starting the app
The Facebook app is mostly just a webview. My news feed doesn't seem to auto-update. I have to open the menu and click on News Feed, but that doesn't always refresh my news feed. This isn't technically an Ubuntu Touch issue.
When rotating the phone, sometimes the phone detects the first rotation really fast, but takes some jiggling to detect the rotation back.
I sometimes have problems connecting to my work WiFi network. That network is a little....special. Other devices have issues, but Ubuntu on my Nexus 5 has more issues than Android on my Nexus 5. The main problem is the WiFi network requires you to enter in your ActiveDirectory credentials on a page before you can do anything. On Android, the notification bar will usually pop up with something that you can click that takes you to the login page. Ubuntu doesn't do anything to let you know that you need to go to the webpage. As a backup, the WiFi router is supposed to send an HTTP redirect to the login page if you try and access any webpage. This is the part that is the real issue. Ubuntu doesn't seem to want to handle or understand the redirect. If I can't authenticate, then I can't access the internet. I have to drop back to 4G and try again later. I found the easiest way around the issue was to authenticate to the WiFi in Android, then boot into Ubuntu.
On to the list:
When I first installed Ubuntu Touch, after the wizard, the system wasn't usable until I rebooted. The landing team knows about this issue.
Sometimes, when I boot, the lock screen never comes up. After a few minutes, I tried hitting the power button thinking the system locked up on boot, and the lock screen came up. It turns out the system booted, but the screen had gone blank due to an idle timeout before the lock screen was available. This only happened twice to me.
When hitting the power button to turn off the screen, the backlight stays on. This drains the battery very fast. I have noticed that it will eventually turn off. This is the one of the two problems that I consider a true blocker for me, since the phone dies way too fast. Other users have noticed this on the Nexus 5 and Nexus 7, but I haven't seen a forum post about it happening on the Nexus 4.
In Settings->Storage, in the list of apps, each app is listed twice.
When upgrading apps, the "Transfers" area in the notification bar shows an entry for each app, but the entry only shows a red X to cancel the transfer. It doesn't tell you anything about it, like the app or the download status.
Sometimes, the action bar of the app slides up by 50% of the height of the action bar. This means the top 1/2 of the action bar is cut off, hidden under the notification bar. Sometimes the app fixes itself, but I mostly open up task manager, swipe to kill, then relaunch. I have seen a bug report of this in Launchpad already.
Sometimes, clicking on an app in the home screen that is already open causes weird things to happen. It does work from time to time. I have seen it just hang there for a few seconds, though. When it hangs there, I usually cannot switch to that app anymore. I have to kill it and restart it. I have seen it kill the app and restart it as well. It will sometimes just do nothing. I get frustrating thinking the app won't launch until I realize that it is already open and I just need to switch to it.
In System Settings, the "Updates available" section doesn't go away after you perform all the updates until you relaunch the System Settings app.
Clicking on System Settings->About this phone->Developer mode crashes the System Settings app. I have no idea what is supposed to be in there, but I was curious.
Open up Messenger, Click in the "Write a message..." text box to bring up the keyboard, hit the power button turn off the screen, hit the power button to bring up the lock screen, swipe to unlock. The bottom row of the app (that has the text box and send button) are still in the higher position (as if the software keyboard was still there), but the software keyboard isn't actually showing. Clicking on the text box does not bring up the keyboard because the text box already has focus. You can get back to normal just by scrolling in the app.
Bluetooth does not work. This is a blocker for me, since I use the Bluetooth on my phone to play music while I drive. This is a known issue. I don't know which devices have Bluetooth working.
Sometimes, launching an app will leave you at the home screen, frozen and unusable, for a long time before actually starting the app
The Facebook app is mostly just a webview. My news feed doesn't seem to auto-update. I have to open the menu and click on News Feed, but that doesn't always refresh my news feed. This isn't technically an Ubuntu Touch issue.
When rotating the phone, sometimes the phone detects the first rotation really fast, but takes some jiggling to detect the rotation back.
I sometimes have problems connecting to my work WiFi network. That network is a little....special. Other devices have issues, but Ubuntu on my Nexus 5 has more issues than Android on my Nexus 5. The main problem is the WiFi network requires you to enter in your ActiveDirectory credentials on a page before you can do anything. On Android, the notification bar will usually pop up with something that you can click that takes you to the login page. Ubuntu doesn't do anything to let you know that you need to go to the webpage. As a backup, the WiFi router is supposed to send an HTTP redirect to the login page if you try and access any webpage. This is the part that is the real issue. Ubuntu doesn't seem to want to handle or understand the redirect. If I can't authenticate, then I can't access the internet. I have to drop back to 4G and try again later. I found the easiest way around the issue was to authenticate to the WiFi in Android, then boot into Ubuntu.
Subscribe to:
Posts (Atom)