Tag: Application Design

What to Check When You Review My New Blog Setup

A number of people have written to ask specifically what to check when they look at the new blog setup. Here are the issues I’m most concerned about now as I get the configuration done:

 

  • Does the blog size well when you use your device? I’m especially concerned about how the blog looks in smartphones and tablets, but it has to look great on a PC too.
  • Is the text easy to read?
  • Does the blog size well when you make the text smaller or larger to meet your specific viewing needs?
  • Are the features working well? For example, when you perform a search or click on a tag to view related articles, are you seeing what you expected?
  • Do the colors work well for you? I’m especially interested in hearing about the highlighting on features like the calendar.
  • Are you seeing anything you didn’t think you’d see?


I’m also interested in your opinion about the new software. How does it improve on the experience you had with the old software? What do you miss about the old software? Does the blog seem to work faster or slower? Anything you can tell me about the content, appearance, or performance of the new software would be helpful. This the best time for me to make required tweaks. Please be sure to contact me with your concerns at [email protected].

 

Blog Questions

A number of people have written with questions about the blog update. A lot of these questions will be answered later. Please keep the questions coming because they help me ensure that the new blog will meet your needs.

The one pressing question is about things people have noticed are missing. There are two items that won’t move to the new blog: subscriptions and comments. The comments are pretty much gone unless people want to make them all over again. However, the subscriptions will be easy enough to make again. I’ll post instructions for you after the blog is completely changed over. Please don’t create a new subscription until after I post instructions for you.

I’m adding the tags back in as I move the posts. That’s one of the reasons that the move is taking so long. The tags have to be added by hand (as do the graphics). As of today I’ve moved 293 posts, so there are only 376 more to go !

Thank you again for your patience. This move really shouldn’t have been so hard, but that’s how things go sometimes.

UPDATE 6/24

There are other problems that you’ll notice with the posts that I’ve moved. The most noticeable is that the source code in my posts isn’t moving correctly. Actually, it appears pretty much unusable. The information is there, but you’re going to have to look hard to use it. I’m looking into WordPress compatible source code add-ins to make the source code look nicer. If someone has experience in this area, please contact me at [email protected]. I’d prefer to see an example of the add-in output if you have one to provide.

Another issue has been tables. I think that all of the tables are currently usable, but please let me know if you spot something that doesn’t look quite right and I’ll do my best to fix it.

Blog is Moving!

Hi Everyone,

Never in my life did I imagine that moving my blog to the new software would take so long or come with so many hurdles. However, the time has come to make the move. Please be patient over the next few days as I continue to move posts from one location to the other. Eventually, you’ll find the new software running on the current blog URL and will be able to access it just as you always have. In the meantime, if you truly can’t wait to play with the new software, you can check it out at: https://blog.johnmuellerbooks.com/.

So yes, to answer all your queries, I am aware that the old blog is going away because it’s finding a new home . Please hold your questions for now. The new site setup requires tweaking, but the information you find on it is content complete. After the move, I’ll be uploading posts asking for your input on the new setup. For now, please do test the new software with your cellphone, tablet, and PC. It should run well on any device you choose. The new software is also more accessible and should be considerably easier to read.

Thank you again for all your support. This blog wouldn’t exist without you!

John

Death of Windows XP? (Part 4)

The last post, Death of Windows XP? (Part 3), was supposed to be the last word on this topic that won’t die, but as usual, it isn’t. The hackers of the world have figured out a new an interesting way of getting around Microsoft’s plan to kill Windows XP. It turns out that you can continue to get updates if you’re willing to use a registry hack to convince Windows Update that your system is a different version of Windows that is almost like Windows XP Service Pack 3, but not quite. You can read the article, How to get security updates for Windows XP until April 2019, to get the required details.

The hack involves making Windows Update believe that you actually own a Point of Sale (POS) system that’s based on Windows XP. The POS version of Windows XP will continue to have support until April of 2019, when it appears that Windows XP will finally have to die unless something else comes along. It’s important to note that you must have Windows XP Service Pack 3 installed. Older versions of Windows XP aren’t able to use the hack successfully.

After reading quite a few articles on the topic and thinking through the way Microsoft has conducted business in the past, I can’t really recommend the registry hack. There are a number of problems with using it that could cause issues with your setup.

 

  • You have no way of knowing whether the updates will provide complete security support for a consumer version of Windows XP.
  • The updates aren’t specifically tested for the version of Windows XP that you’re using, so you could see odd errors pop up.
  • Microsoft could add code that will trash your copy of Windows XP (once it figures out how to do so).


There are probably other reasons not to use the hack, but these are the reasons that come to mind that are most important for my readers. As with most hacks, this one is dangerous and I do have a strong feeling that Microsoft will eventually find a way to make anyone using it sorry they did. The support period for Windows XP has ended unless you have the money to pay for corporate level support-it’s time to move on.

I most definitely won’t provide support to readers who use the hack. There isn’t any way I can create a test system that will cover all of the contingencies so that I could even think about providing you with any support. If you come to me with a book-related issue and have the hack installed, I won’t be able to provide you with any support. This may seem like a hard nosed attitude to take, but there simply isn’t any way I can support you.

 

Understanding the Need for Perspective in Development

I have received a lot of e-mails over the years from developers who don’t quite get the idea behind application design. The problem is that developers are taught about tools, strategies, patterns, and all sorts of other technical details, but are never taught an essential lesson that all applications are essentially products and that it’s up to the developer to sell them. The societal claim that all developers are socially inept nerds who are incapable of communicating with other humans doesn’t help. The fact of the matter is that an application that doesn’t serve the customer’s need will never get used—it will never be successful. Developers need to get the idea that they’re creating a product that must satisfy customer needs in order to be successful.

Many applications today are akin to inflexible restaurants. Imagine how you’d feel if you went into a restaurant and ordered a single egg, fried, with white toast, and a side of sausage and the server says, “I can’t fulfill your order.” Your first question would be why the order is so hard and her response of, “It’s not on the menu.” takes you completely by surprise. It turns out that the menu specifies two eggs, not one. Many applications present users with precisely that sort of choice, yet developers seem surprised when users are less than thrilled. A response of, “It’s not on the menu.” was never a good or valid one, yet that’s the response developers have offered users for a long time now.

In order to be successful, an application must be flexible enough to meet user demand. A developer must understand the user perspective and create an application that can meet the demand for one, two, or even three eggs (or how many ever eggs the user wants). After all, it doesn’t matter how many of an item the user ultimately wants, as long as the user is willing to pay for those items. In order to gain that perspective, developers must talk to users, listen to what they have to say, and engage them in the development process. All other businesses that I know of engage their customers in some way to ensure their products meet customer needs and the computer industry must learn to do the same.

Many applications also make things entirely too complicated. It’s akin to going into a restaurant and not being able to order until you provide the secret handshake. Servers who say, “Talk to the hand because the head isn’t listening.” won’t stay employed for very long. A restaurant won’t stay in business very long with that attitude and neither will the developer. A user isn’t interested in the arcane science of development or how many cool widgets your application uses. The user is only interested in taking a picture or performing some other activity that has nothing whatsoever to do with development or even computers for that matter. As far as the user is concerned, your application should be invisible.

So, why my preoccupation with restaurants in this post? I was watching someone use one of those restaurant data entry programs this morning. After the server provided the secret handshake, she had to navigate no less than ten menus before she was able to complete the order, which then failed because they were out of a particular item. So, she had to cancel the order and reenter everything. Would it really have been all that hard to add a feature where the cook could simply tell the server that something was out of stock? Does an order really require navigation of ten menus to accomplish? It surprises me that this order entry system is actually installed somewhere—perhaps nothing better was available.

The day where a developer can offer inflexible solutions that don’t meet user needs and offer only complexity is over. As users become less interested in accommodating developer needs because there is always another solution to try, developers will need to accommodate the user’s needs. Actually, that’s what should have happened in the first place. No other industry would have tolerated what users have had to tolerate from the computer industry. Let me know your thoughts on gaining the user perspective at [email protected].

 

Happy New Year!

Welcome to the New Year! It’s going to be an interesting year from a number of perspectives. I’m really looking forward to seeing the changes and I hope that you are too! Make sure you subscribe to my blog to keep up with all of the new material I provide with greater ease. A subscription will automatically send a synopsis of new content directly to your e-mail, which will make it a lot easier to determine whether you want to follow a certain post (and it’s associated comments).

The computer market will continue to move away from the desktop toward all sorts of mobile devices. Of course, this will make browser-based applications become even more popular because you can achieve the same look and feel no matter which platform you use to interact with the application. I’m not saying the desktop is dead, but look for browser-based applications to take on added importance. In some respects, browser-based applications can still be limited, so you’ll continue to see the desktop used in situations where a user must interact with complex data from multiple sources.

Self-sufficiency is going to take on added importance as well. There are a number of reasons for the increased participation by people. Of course, the economy continues to provide ample reason for many people who are looking to ways to make their money go further. A lot of people are starting to realize that self-sufficiency also comes with substantial health benefits and is also good for the environment. In fact, except for the time commitment and the requirement to learn new skills, self-sufficiency has a lot to recommend it. I’m planning to provide more emphasis on self-sufficiency in the coming months.

My blog will also feature some of the additional kinds of content that you’ve come to know and love. I’ll be posting a number of reviews and a bit more of my poetry as time permits. A few posts on writing technique are almost a requirement. A number of you have sent e-mail asking about my crafting. A few personal issues have kept me from posting on the crafts that I enjoy, but I plan to address that particular need soon. I hope that you continue to enjoy my blog and will let me know the sorts of content you’d like to see at [email protected]. In the meantime, Happy New Year!

 

MTBF and Software

Like many people, I sometimes need a bonk on the noggin to remember some essential bit of wisdom that I shouldn’t have forgotten in the first place. Such is the case with the relationship between hardware and software. In many cases, developers have lost their connection with the hardware. Even though it seems quite obvious that the software provides instructions that change the state of the hardware, developers don’t really seem to make the connection. Once you remember the hardware connection, it also begins to make sense that any aberration of the functionality of that hardware will also reflect in the reliability of the software. In short, the Mean Time Between Failures (MTBF) of the hardware also has an effect on the software that runs on the hardware and causes the hardware to perform specific tasks.

The issue that drove the point home for me is a simple hard drive. This particular hard drive came with the system and the vendor used a lower cost drive to keep prices low (normally I get really high quality hardware simply to avoid problems). What this means is that the MTBF of the drive is also quite low. Unfortunately, I encountered the MTBF late last week as a glitch that caused me to think there was a problem with my software. The software was just fine—it was the glitch with the hard drive that was the source of the problem. I only realized this fact after testing the software on another system. (Unfortunately, the hard drive got worse and took some of my system configuration with it, but I maintain backups, so the loss was minimal.)

However, the partial failure of the drive caused me to realize yet again that software can only operate correctly when the underlying hardware also operates correctly. I can’t remember the last time I read anything that even broached the topic of hardware as a potential source of software problems. It makes me think that there are probably developers out there right now trying to find the error in a piece of software that doesn’t even exist in the software, but is a matter of some hardware glitch.

It’s important to realize that hardware doesn’t always fail in a predictable manner either. For example, a glitch can occur when a hairline fracture occurs in the runs of a board. This sort of error makes its appearance when you start the system. When the board heats up, the failure goes away because the breach in the run is sealed. Expansion of the metal fixes the problem. I’ve actually encountered a host of incredibly odd hardware problems over the years, many of which could appear as an isolated software issue given the right circumstances.

The lesson relearned in this case is to always test software on multiple systems. It’s essential that these systems use different components. Doing so will eliminate a number of non-software issues as the source of a problem. For example, using mismatched systems can help you understand when an error is due to a particular device driver. The point is that you need to avoid shooting yourself in the foot by not thinking of all the possibilities. Complex software interacts with the hardware in a complex way, which makes it all the more likely that some insignificant hardware or firmware issue will cause you woe as a developer.

What are your experiences with odd hardware- or firmware-related behaviors? Have you even encountered such behaviors? Let me know at [email protected].

 

Management Lessons from the Military

Having spent 10 years in the Navy, I know that military life can provide some benefits that translate well into civilian life. Enforced discipline, often described as training, does create an environment in which you can learn how to perform tasks more efficiently and with greater success. The training isn’t always comfortable, but the feeling of success when the training is over is always amazing. That’s why I went through the Ten Workplace Lessons From the Military slideshow on Baseline with great interest. It actually does help you understand how someone who has had military training can provide significant benefit to an organization of any sort.

From a personal perspective, I credit my military training with giving me drive and ambition required to write books and to also work through many of the issues in self-sufficiency that I have. The techniques that I learned in the service have translated well into creating an environment where I can work productively and ensure good results. The organizational and planning skills I gained in the service still serve me well today. I’m not saying that I succeed every time—far from it, but I have learned to keep trying until I find a way to succeed.

My service was quite some time ago, so I can’t speak to the training that the military receives today with any authority. However, judging from the content of the slideshow, I’d say that the military still values the kinds of things that helped me become the sort of person I did after I left the service. Things like learning to see what is important in a list of to do items, and what isn’t, is part of the military way of doing things. You never have enough time to complete a to do list in the service—prioritizing is a must.

The main reason I’m writing this post today is to support my fellow veterans. When you hire a vet, you’re getting someone with a broad range of experiences that you simply can’t get outside of the military. You get someone who had the drive to complete tasks under fire and will certainly have the same drive to complete tasks for your organization. Let me know your thoughts on the military method of management at [email protected].

 

Talking Technical with Non-technical Audiences

Communication has always been key to any sort of technical activity, but the need to communicate efficiently is greater today than ever before. The fact that early developers were successful despite having limited communication skills is more due to the fact that early users were also technical (so they shared the same frame of reference), rather than the superiority of the application environment at the time. In fact, applications are a form of communication specific to computers, but until recently, most developers didn’t view them in that light.

The days of the solo developer working in a darkened room and subsisting on a diet of pizza and soda are gone. Applications today have to appeal to a broad range of people-most of whom have no technical skills and have no desire whatsoever to develop such skills. The complex application environment means that developers must possess the means to articulate abstract coding issues in a concrete and understandable manner to people who view their computers as appliances. In addition, developers now commonly work as part of a team that includes non-developer members such as graphics designers. In short, if you don’t know how to tell others about your ideas and the means you plan to use to implement them, your ideas are likely going to end up on the junk heap. That’s why I wrote, “10 Reasons Development Teams Don’t Communicate” for SmartBear Blog.

The problems that developers experience today have more to do with limited communication skills, than technical ability. It’s quite possible to write amazing applications without developing the skills to communicate the concepts and techniques demonstrated in the applications to others. In fact, the stereotype of the geek is funny, in part, because it has a basis in fact. Schools don’t spend much time teaching those with technical skills how to communicate effectively and the graduates often struggle to understand the basis for miscommunication, even amongst peers. Schools will eventually catch up and begin teaching developers (and other technical disciplines) strong communication skills, but in the meantime, developers and other members of the technical professions will need to rely on articles such as mine to obtain the information needed to communicate clearly.

A successful developer now needs to listen to others actively-to be able to repeat the goals others have for an application in terms that the listener understands. In addition, the developer needs to know how to communicate well in both written and oral forms. The transition between the abstract world of code and the concrete world of the typical user is something that a developer needs to practice because there are no books that adequately address the topic today. To keep costs to a minimum, developers must accomplish communication tasks within a limited time frame and without error. In short, there is a significant burden on the developer today to create an environment in which users, administrators, management, DevOps, and other interested parties can communicate both needs (required application features) and wants (nice-to-have application features) in a way that the developer can interpret and turn into a functioning application. Luckily, there are ways to make this a bit easier on the developer. For example, when it comes to DevOps: Agosto offers expertise to help you rapidly deliver what’s needed.

What sorts of communication issues have you faced as a developer or other technical specialist? Do you often find that people look at you quizzically and then proceed as if they understand (but you can tell they don’t)? Let me know your thoughts about communication issues at [email protected].

 

Methods of Learning

More than a few readers write me about the best way to learn. Many of them are asking about the best way to learn how to become a programmer-a topic I discuss in my Becoming a Programmer post. However, more and more often, readers are asking me about learning in general. The fact is that I can point you to different techniques for learning, but I can’t determine what will work best for you. You’re the only person who can make that determination and you won’t know until you try a number of techniques. In a society ever more devoted to success at all costs, learning requires that you fail in order to make gains. When you fail, you learn what doesn’t work and possibly why it doesn’t work. So, trying various techniques is the only way to discover what works best for you and that process involves some level of failure. This is a philosophy that educational providers like Venture Lessons embody, interactive lessons that you can fail in will teach you so much more than lecturers.

I imagine that my answer frustrates a lot of people because they don’t want to fail at something, so they ask what works best for me. Mind you, what works for me probably won’t work for you. I personally learn best by working through examples written by other people. When it comes to programming, I rely on application examples written by other developers and scrutinize them intensely using the debugger so that I can see precisely how they work. Then I create applications of my own that use those techniques to ensure I actually do understand how things work. Likewise, I use examples from other woodworkers, gardeners, or other professionals as a basis for my own hands on learning experiences. In addition to these hands on techniques, I also read a large number of books and articles every year. Often, all I really need to learn a new technique, is a good explanation of it. I read books and magazines in every area that interests me-everything from application development and computer hardware to new gardening techniques and animal husbandry. In some cases, I also attend lectures and seminars to augment my learning, but given that lectures and seminars tend to be expensive, I focus on my primary means of learning new things whenever possible.

Don’t limit yourself to what I use though. There are many other ways of learning that are just as viable and just as important. The only requirements of learning is comprehension (the ability to understand what you’ve learned) and retention (the ability to remember what you have learned). How you achieve your goal is up to you. Here are a few other methods you might consider trying in addition to those that I commonly use.

 

  • Instructor Led Training: There is a good reason that children go to school. An instructor (teacher) can answer questions about a particular skill immediately and fully. The interactive communication that occurs helps the student learn faster and with fewer problems.
  • Tutorials: A tutorial is essentially a set of precisely written procedures meant to guide the student along a particular learning path. It’s a combination of reading and doing that helps someone develop a skill quickly.
  • Interactive Media: This is a newer form of the tutorial that relies on sight and sound to convey meaning. Interactive media includes animations and graphics that help a viewer visualize the content better. Hands on exercises included with the interactive media help the student know when a particular training goal is achieved.
  • Observation: The subtle art of observation isn’t mentioned very often anymore-probably because people are too busy or impatient to use it. I know that I’ve learned more than one new task though simply by watching someone else do it. Observing someone means watching and thinking about what they’re doing. You don’t necessarily ask any questions (and may annoy the person you’re observing when you do).
  • Experimentation: Of all of the methods used to learn, this method provides the highest gains when successful, but also incurs the greatest amount of failure. It’s a matter of asking a question, deciding on how best to answer that question, and then creating an environment in which to determine the answer. In order to ensure that the question is answered correctly, you often have to repeat the experiment a number of times in various environments. Experimenters often discover new knowledge or rediscover lost knowledge, but at the cost of failing a lot.
  • Cooperation: A cooperative learning environment is one in which two peers have part of an answer and choose to share their part with someone who has another part of the answer. The exchange benefits both parties because both now have two parts of the answer. Of course, a cooperative learning environment requires trust on the part of both people.
  • Dissection: When I was younger, I couldn’t be bothered to keep anything in one piece. I dissected everything in an attempt to discover how it worked. Often, that meant not putting the item back together because the dissection process is destructive. Even so, you’d be amazed at how many things you can learn by dissecting an object to see how it’s put together.


This list is incredibly short. Over the years I’ve seen people learn an amazing array of knowledge using all sorts of techniques that boggle the mind. In every case, the successful learner has experimented with various techniques until he or she finds the techniques that work best. These techniques won’t work best for someone else, but they work best for you. I encourage you to fail in order to learn. Don’t be afraid of trying something and then discovering it doesn’t work because that’s the only real way to learn anything. Let me know about your favorite learning technique at [email protected].