How to Replace the LCD Display on a Roland Juno-G
So on this very snowy weekend in northern Virginia, I had enough time to try out replacing the defecitve LCD display on my Roland Juno-G. This has been a common problem with this keyboard, especially with the the first units produced. I purchased my Juno-G used from Guitar Center for $650 in December of 2008. About 6 monthhs later, the display started to act strangley. At first, the display was distorting. Eventually, half to 3/4 of the screen went blank.
After reading several blog posts about other folks having this issue, I called Roland Support. They informed me I could buy the part for $135 or go to an authorized repair center. Maybe it was my recent experience with embedded device software engineering, but I had the urge to try the repair myself for the first time. So I ordered the part, and it was delivered a week later.
So here are my instructions on replacing the LCD. It took me about 2 hours, but I was really going slow :
- Get about a dozen small bowls or container to keep the screws organized. Get little strips of paper. When you remove the screws from a section, write a label of what the section is, put the label in the container, and put the screws in the container. There are close to 50 screws, and you don’t want to confuse them.
- Grab a philips screw driver, small wire cutters, and small needle nose plyers.
- Remove the data wheel to the right of screen. Keep pulling firmly and it will eventually slide off.
- Flip the keyboard over and begin removing the screws to separate the case. You need to remove every single screw you see on the bottom of the keyboard.
- Separate the case.
Inside the Roland Juno-G
- Unscrew the mounting screws from the circuit board containing the jacks and disconnect any ribbon connectors that are in your way. You should be able to flip the board back and over and out of the way.
Getting Juno-G jack circuit board out of the way
- Next, unscrew the mounting screws from the motherboard on your far right. You may need to snip a couple wire ties to make room to move the motherboard up enough to get at the center board. Disconnect any ribbon connectors that get in your way.
Juno-G Mother Board disconnected to free up the center board
- The LCD display is on the other side of the center circuit board, so you are almost there. Unscrew mounting screws and disconnect any ribbon connectors. There are a few screws hidden under black pieces of tape. You also may need to cut some the the clear plastic sheets that back the circuit board.
- Flip the center board over and unscrew the LCD display.
Juno-G Center board flipped over to reveal LCD display
- Screw in the new display, and work backwards mounting the circuit boards back into place and reconnecting the ribbon connectors.
- Put the case back together and put the data knob back on.
- Plug in, switch on, and get back to enjoying your Roland Juno-G.
I’ve got a little confidence now, so I suspect I’ll be trying more of my own repairs in the future.
Tips for Effective User Story Gathering Meetings
The typical approach in gathering requirements for an agile managed software or hardware development project is to first conduct user role modeling meetings. A collection of developers, product people, marketing, subject matter experts meet to brainstorm all the different user roles that will interact with the system being created.
After gathering the list, the next step is to generate a list of user stories. One very effective way to do this is to conduct user story gathering sessions, where the group of project members and customers iterate through each user role, brainstorming all the ways the user will interact with the system. Often, a paper prototype outlining a rough workflow is used or created during the session to facilitate the conversation.
Mike Cohn has done an excellent job describing both of these activities in his books Agile Estimating and Planning and User Stories Applied. I’d like to suggest a few tips that have helped make these activities even more useful in generating requirements documentation
- Prepare paper prototypes before the user story gathering meetings with the obvious stories. This will give your meeting attendees a good starting point, serve as examples of how to do a prototype, and speed things along.
- Use Visio or Powerpoint to build your paper prototypes instead of a whiteboard or notecards. Having an electronic copy I can pass around to distributed members of the team is very useful. Plus I find that I am often flipping between multiple workflows during user story gathering meetings, which is hard to do if you drew everything on a whiteboard that might be already erased.
- Start with the user role with the largest role in the system and work your way through each user role in descending order of system interaction. This will cause you to write up a lot of different paper prototype workflows. As you get further down the list of roles, you will find that the paper prototypes you need to facilitate the discussion are mostly already built. (Yet another reason to keep your workflows in an electronic format)
- Don’t forget to gather stories for the hidden users roles! I find it extremely useful to work through the system as the role of developer, designer, project manager, qa manager, product owner, suppler, etc. Example stories you could generate as a project manager for a new web application project could be:
- As a project manager I want to conduct a PCI compliance gap analysis for my planed network architecture to make it easier to attain compliance later.
- As a developer, I want to setup a continuous integration server for the project so that our unit tests are executed regularly.
I hope you find these suggestions useful.
Don’t work harder. Work different.
We’ve all been told by our bosses that we need to “work harder”. The project is behind, the product is selling as predicted, to many bugs, etc… and the solution presented by management is “work harder”. Or if you are a manager, you may be fond of using this as direction to your team. I’ve come to be very weary of the “work harder” solution. Here’s why:
- Manager’s often use the “work harder” solution as a fallback when they cannot or will not figure out what the real problem is. It is simply easier for a manager to declare “work harder” rather than make difficult decsions on prioritizing work or changing what people are working on.
- Manager’s may use the “work harder” speach as motivation, but this has diminishing returns. You can only use this solution so many times until your team is skeptic that the problem isn’t in execution, but in strategy. And really, can’t a manager come up with something more original than “we gotta work harder!”?
- I prefer to reserve the “work harder” solution for emergencies only. Reserving this solution for times when more execution is the only solution to an immediate emergency helps ensures that the emergency is handled.
In summary, I believe there are times when “working harder” is an acceptable solution to a problem. But managers, please be very frugal in how you use this tool. Be sure that the problem will be solved with improved execution, and investigate the more likely solution that the planning or strategy is the real culprit.
Send and Receive SMS Text Messages Using a GSM GPRS Wireless Modem
If you need the ability to send SMS text messages from your website or Internet connected software, you will quickly discover several options such as using the free wireless carrier email to SMS gateways (ex. 5555551212@vtext.com), third party SMS gateways (ex. CellTrust HTTP API), direct connection to SMSC’s (after days of research and phone calls to AT&T, we couldn’t figure out how to do this), and GSM GPRS wireless modems.
The free SMS gateways are great if you know both the phone number and mobile carrier, and you don’t require delivery to or from a short code. If you don’t know the mobile carrier you can look it up through any number of free or paid third party API’s (CellTrust offers one). If you need to use a short code, then third party SMS gateways are your only choice. But at large volumes, the cost can really add up. GSM GPRS modems are the best choice if you need to send high volume, don’t know the carrier, and don’t need a short code. However, programming and scaling GPRS modems can be a challenge because you have to use AT commands that aren’t always implemented in a standard format and you also have to do deal with serial port communication (For a great tutorial, checkout: http://www.developershome.com/sms/). If only somebody made a GSM GPRS modem attached to a web server…. Somebody did, and I have to give it a very positive review.
We stumbled upon the SMSFinder while on a tech support call with Multi-Tech. We had purchased a GSM GPRS modem and we intended on programming it using AT commands to send and receive text messages. We found out from our very helpful tech support person (Multi-Tech support is excellent btw), that if we just wanted to send text messages, the SMSFinder is for us. The SMSFinder is a GPRS Wireless Modem, with an ethernet port, wrapped with a web server. Just slide in an active SIM card, plug it in, and your ready to go. It exposes a simple HTTP API for sending messages, along with a basic GUI web admin portal. The device handles queuing the requests if it gets behind. We have put multiple modems behind a load balancer, assigned it a VIP, and instantly have the ability to scale. The downside to this approach is that your messages will come from one or more phone numbers, not short codes. But if you need to inexpensively send a large volume of messages very cheaply (10,000 messages via a third party api will cost you about $500), and you don’t require a short code, then you should consider the SMSFinder.
Here’s a short summary of options for sending SMS test messages.
| Option | API | Cost | Deliverability | Carrier Required | Short Code Support | Receiving | Volume |
|---|---|---|---|---|---|---|---|
| Carrier Email to SMS Gateways | Free | Can be Slow | Yes | No | Yes, but requires inbound mail server. Needed to manage unsubscribes | Larger commercial volumes (> 1000/day) may cause you trouble with the wireless carriers | |
| 3rd Party Gateway API | HTTP, SOAP, Email | 1 to 6 cents per message | Fastest Delivery | No | Yes, either dedicated or shared | Yes via callbacks | Unlimited |
| GSM GPRS Modem | Hayes AT Commands | $200 to $700 + $50/month for unlimited sms wireless plan | 7 to 20 per minute | No | No | Yes | Unlimited Domestic |
| SMS Appliance (ex. Multi-Tech SMSFinder) | HTTP | $700 (1-port) + $50/month for unlimited sms wireless plan | 7 to 20 per minute | No | No | Yes via callbacks | Unlimited Domestic |
And one more thing, Multi-Tech is releasing a 4 and 8 port version in Summer of 2009.
Don’t Mix Brainstorming and Estimating Effort in the same Design Meeting
Recently, Derrek Long, my system architect, asked me to read a few pages from the book I.M. Wright’s Hard Code by Eric Brechner. He had observed issues our company was having with mixing brainstorming and scope cutting in the same meeting. Brechner describes over a few page in Chapter 5 how to avoid getting FOCKED, or “Failing to Orchestrate Collective Knowledge Effictively for Design”. Essentially, Brechnar preaches to have very specific goals for a meeting, and to avoid at all costs mixing goals, especially when the goals are completely opposite to each other.
After reading Brechner, and thinking about it for the last few weeks, I’ve expanded this idea out a bit further as to why mixing brainstorming and estimating effort during initial design meetings between the business stakeholders and development is a bad idea.
- Discussing effort for each idea discourages creativity when brainstorming. People will be less likely to offer “out of the box” or “half baked ideas” that need to be flushed out if they are afraid they will be scolded for coming up with something “too hard”.
- Dev often will give a big estimate when they don’t like an idea. So waiting to estimate the idea at a later time demonstrates that dev still put in the due dillagence to consider the idea and the estimate isn’t just based on dev not immediately liking it.
- Initial estimates given 10 seconds after hearing an idea in a brainstorming meeting will be less accurate. Dev needs time to absorb the idea, think it through, and then offer an estimate of effort. Even spending 5 or 10 minutes considering an idea results in the developer spending 100 times more time considering the idea and will result in a more accurate and reliable estimate.
- Other ideas presented later in the meeting might add further clarity to earlier ideas or might prevent the idea from needing estimation altogether.
I would love to hear from other people their experience with keeping brainstorming and estimating separate. If you have techniques you employ to do this, let us know!
Save Time by Checking Email on Your BlackBerry Instead of Your Computer
I’ve noticed that I can get through my email in half the time if I use my BlackBerry rather than my computer. Email using my computer takes about 3 to 4 hours of my day, so using my BlackBerry is a huge time saver.
So why is it faster to do email on my BlackBerry than a computer?
For one, firing up my Windows Vista laptop sure ain’t quick. Even coming out of sleep mode, this can take a few minutes. My BlackBerry is always on, ready to go as fast as I can reach in my pocket.
Two, I’ve got about 1.5 GB of email, and I receive about 150 emails a day, so opening Outlook can take a while. Other actions, like deleting messages, switching to the next message, etc… also take a second or two and seem to get worse as my mailbox grows over time (I know I can archive things, but I tend to use past mails every so often). Flipping to email on my BlackBerry takes about a second. Deleting multiple messages is fast and easy to do by selecting multiple messages. Opening messages is instant. Even viewing attachments is quick on my Verizon BlackBerry Curve.
Thirdly, typing on a BlackBerry is almost as fast as a computer for me. But because its a BlackBerry, I somehow feel it’s ok to much more brief in my responses… like its a text message. I make use of common acronyms like TY or IMHO (or WTF) that I wouldn’t normally do in an email I’d type out from my computer. Maybe it’s just me, but I feel like its ok to use text speak in email from a BlackBerry but not from a email created on a computer. Saves alot of typing and time!
If a particular email message requires extra attention, or a very long response, I will mark the message as not opened and take care of it from my computer later.
So maybe this approach can work for you? If you have a BlackBerry, or any smart phone with a real physical keyboard (I don’t think a touch screen keyboard will be fast enough), consider using this as your primary email device.
Release Web Software to Production in the Morning
Until recently, most development shops I’ve been a part of have performed software releases to production after hours, typically late at night. The conventional thinking is that releasing off hours minimizes the risk of disrupting users if there are bugs in the release that were not found in QA or if the web site must go down during the release process.
Over the past few months, we’ve tried something different. We release once every 3 weeks or so. The day before the release, the dev team works long and hard to ensure that QA is completed, all bugs are fixed and verified in QA environments. Then we all go home, get a good nights sleep, then start the release first thing in the morning when everyone is back at work. Our releases usually take about 45 minutes, but some can last several hours if we are pushing a lot of configuration changes. We rarely need to bring production completely down for a release, as we can shift load and take clusters out of service using a load balancer.
Reasons why I’ve come to really like this approach:
- If you release at the end of the day, often times not all your development staff is around. I’ve seen this many times where developers don’t stick around because they don’t have any code going in the release. But, that doesn’t mean you might not need that particular developer if something goes wrong, especially if you have to rollback.
- First thing in the morning, your development staff is fresh and ready to go. If you release at then end of a long day, and something bad happens in production, it can be brutal to try to figure it out. It’s like working 12 hours, then someone handing you a calculus problem. Good luck. The developer is much more likely to fix the issue quickly and correctly early in the day.
- Releasing in the morning also makes it easier to observe the production environment for a time after the release. A production issue might not be apparant right after the release, it may take an hour or two (ahem, a queue backing up). Releasing in the morning allows development to keep an eye on production during the day and make sure everything is running smoothly.
Releasing in the morning might will not work for everyone. If your production environment has so much load that it can’t afford part of the cluster going down, then this isn’t possible for you. But if you can technically do it, I suggest you give it a try. I’d love to hear back from others about their experiences with this.
Save Time… Avoid Agile Planning Poker
The agile project management technique of planning poker is a popular estimation process for software development. My favorite Agile author Mike Cohn presents a good description of the practice on his blog here: http://blog.mountaingoatsoftware.com/?p=14.
Let me start off by saying that I really like planning poker. It’s a very clever way to estimate user stories. However, from a tech startup standpoint, where time is a critical resource, planning poker becomes a non-essential part of the agile process. Here’s why:
- The cost is material. My typical 2 to 3 week iteration has approximately 40 stories. I find that it takes between 2 to 5 minutes per story. Using 3 minutes as average, that brings us to 120 minutes. So my team of 10 people, spend 2 hours in planning poker. Multiply that by $75/hour and you get a cost of $1,500, not to mention the opportunity cost of not coding. At a startup, where time is so valuable, this is a tough pill to swallow.
- After several iterations and planning poker sessions, I began to realize that I could estimate just as good as the developers. I would compare actual hours reported by my developers spent on user stories to the story points estimated and calculated that my estimates had the same standard deviation as the whole team did the estimation. Even if you continue to practice planning poker, this is an excellent exercise to refine your estimating skills.
- Take shortcuts. The average bug tracked in our bug tracking software is about a 1 story point. Skip estimating every bug and just apply this average.
- If deadlines are less critical to your particular situation, then why care so much about your estimates? My web application dev team often has a release plan that changes every couple weeks. We are not tracking a burn down to know when the release is complete, because the story make-up of the release changes so frequently. The burn down chart is not actionable for us.
On particularly large stories or Epic’s, I ask the developer who will probably be working on the story to give me their estimate. But for the majority of user stories, I take care of the estimation. Maybe you can too?
Review of Web Analytics An Hour A Day by Avinash Kaushik
This is one of the first books that I have read on the topic of Web Analytics. This book is not a deep dive of a particular tool like Google Analytics or Omniture, but rather a comprehensive description of a web analytics framework (Trinity) and a 6 month plan to implement. The book is targeted more towards medium to large companies. A small startup like my own couldn’t begin to implement all of the suggested actions. In some chapters, Avinash clearly notes which strategies (such as the testing chapter) are best for companies with limited resources, but overall he doesn’t always do this. I would have like to see him make minimum suggestions or short cuts for companies that don’t have even 1 FTE dedicated to web analytics.
A few key points from the book that I really found beneficial:
- Heuristic Evaluations: An easy way to quickly determine if a web page is designed well by going over a checklist of about 20 basic design rules of thumb
- 10/90 Rule: Spend 10% of your web analytics budget on tools and 90% on people.
- Web Analytics function should align with the business, not IT.
- 10% variability in web tools is not uncommon.
- 2% is standard conversion rate
- In Google, type in “site: <www.yourdomain.com>”. This will show you how well Google has indexed your site. If Google shows 50 pages, and you know you have 200, then something is stopping its spider from indexing your entire site.
- http://snipurl.com/poplink. Great tool to quickly view your website ranking across multiple search engines for a search phrase.
- 80% of the time, company employees are wrong about what customer’s want.
- About 20 search phrases represent the majority of search engine traffic to your website.
I definitely recommend this book, but be ready to pick apart what you can realistically do in the amount of time you can afford to spend on web analytics.
Achieving a Work Life Balance at an Internet Startup
To quote Luke… “You ask the impossible”. Although making your boss at work and your family at home happy may not be as difficult as lifting an x-wing fighter out of a murky Degobah swamp with nothing more than your thoughts, it is still quite the challenge.
Everyone wants more. Your family wants more of you. Your board of directories want more. Your employees and co-workes want more. No one is ever happy with the amount of time you are able to devote to them.
A manager at a startup should expect to work 50 to 60 hours a week. Find an amount within that range that is sustainable, and try to stick to this. I find that I can do 10 hours a day during the week, and 5 hours over the weekend. So to get your hours in and be the most productive you can, try out these tips.
- Try to do 8 hours in the office, and 2 at home during the week. Sitting next to your spouse on the sofa in the evening allows you to multitask: spending time with the family while working.
- Be home for bedtime. If you have kids, make sure you are home at least 3 times a week for bedtime. I find that I can leave work around 6pm, get my kids bathed and put to bed, eat, then get back to work. Life is short, and you shouldn’t miss this special time of the day.
- I like to be home at 5 on Fridays, so I will work one late night a week so that I can cut out early on Friday.
- Save email for later. I find that addressing my email at night, when I’m a little tired, is a good use of my brain in a tired state. Doing this regularly gets people used to expecting 24 hour turn around on emails, rather than immediate response. Plus, doing email all at one time at the end of the day allows you to not get interrupted during the day.
- Use your time efficiently. Eat lunch at your desk. Get a smartphone with email. Your drive to work is a great time to check mail.
For those times that your spouse looses their patience with you, I suggest reminding them that if building a successful business was easy, everyone would do it.
About
A blog about software development, marketing and general business practices at an Internet Startup.
Keith is currently a co-founder and Director of Product Development at RideCharge, a startup mobile and web taxi booking service. Prior to RideCharge, Keith has been an IT project manager, Java developer, and PeopleSoft developer. He holds a MS in E-Commerce Technolgy from DePaul University.
