Shuttleworth Proposes Overhaul of Desktop Notifications
"Notifications are only for things which you can safely ignore or miss out on." Fred explains well -- do not display anything that nobody needs to see.
The best portion of this proposal is everything using Mark's API can be safely disabled completely. The bad is wasting effort on something completely useless. The worst result is splitting the interface for applications communicating with people. This interface does not allow actions, therefore any communications requiring actions must use a different interface so using this project requires multiple interfaces for communicating with people.
Programmers were (and most are still) not trained about usability. A good interface for a messaging system would have been easy if dialog boxes with standardized buttons had not become common. Windowing systems also kept the modal model from the single-thread paradigm. Multi-threading has been used for performance rather than interfacing with people.
Specifications: Only the front-end application can force message window to front. Applications can check whether a message was answered and receive the answer, preferably asynchronously, but people can switch applications freezing the current application if the response was mandatory and urgent. System may limit frequency of additions and checks by applications to prevent overloading. Every message appears in list interface and log(s). Reactivating a message moves to the top of list. List remembers first time, last time, and number of appearances. People can remove messages from list without using application-defined actions (to prevent fear that application dialog box's close action has other consequences.)
The new API is simple. Only the first string is required in each function. Answers are the text of the parameter (so changing the order has no other effect.)
Synchronous (application waits for answer, gaining focus automatically reopens message):
action = ask_wait("Question", "Action1", "Action2", "Action3");
Asynchronous (application can continue):
ask_log("Question"); - Add to list without move messaging to front, and continue.
id = ask_new("Question", "Action1", "Action2", "Action3"); - Add question, move to front, and continue.
ask_again(id); - Move question to top of list and move messaging to front.
action = ask_get(id); - Empty string if no answer.
Should be easy to create library for use with Gnome, KDE, and Win32. Simplification includes:
- Window title cannot be specified.
- One standard font without decorations. This avoids Gnome's practice of using bold for the first line so the critical question at the end is less visible.
- No images. Some systems add icons to indicate type of dialog. These types are unnecessary. People only care if they need to choose an answer.
- Text is required for actions, hopefully ending the reign of OK|Yes|No|Cancel dialogs.
Future possibilities include:
- Filter/sort list by application and whether actions exist.
- Incorporate the messaging system as a status bar in applications.
An early version of this text was posted on the original article. The comment either will not appear until moderated or failed moderation. My website contains an expanded version.
Firefox 2.0 Update To Remove Phishing Detection
People do not change until a reason exists.
I support five PCs with 512MB RAM and ~2Ghz CPU built 1999-2002 running Windows 98SE. These PCs will be used until the hardware fails. Windows XP is very slow on this hardware and still has critical security holes seven years after release. The users have not been happy with my attempts to convert them to Linux. The users are happy with the current (old) software so the lack of upgrades is not a problem.
The default Internet Explorer 6 was designed to ease virus distribution; alternate browsers such as Firefox 2 are critical to keeping these PCs secure. Firefox 3 refuses to install on Windows 98, probably more to reduce support than any technical requirement. Vendors encouraging upgrades by disabling features or refusing to install just causes these users to stop updating software. These users already abjure iTunes, Vonage, and ZoneAlarm.
IT Job Without a Degree?
My story might help the OP.
Background: Playing with computers since very young. Started an information publishing business before the Internet was ready (wrong partner.) Used the experience to consult buiding database applications. Almost took a job programming C++, but returned to college (wrong move.) Dropped out for finances (poor loans and grants advice and policies.)
No degree; want job in IT.
1995: Joined cattle call for Windows 95 call center. Over 200 people; very few with computer experience. I bothered the best technician with questions. The current best technician would leave for a non-support job about every two weeks. Repeated until I was the best technician.
1996: Used that reputation to land job as "Lotus Notes Administrator" answering support calls. Learned administration. Also learned LotusScript and the rest of Lotus Notes. The development group would call me for help when they could not read their own code. Several of the developers were consultants from one company.
1997: Joined the consulting company. Would try me as a developer, but threatened a long-term administration position if I did not produce. I produced. Became certified as both administrator and developer. Built reputation for completing the impossible in very little time.
2000: A large consulting company recruited me for contract work. That company has provided about half my work since. Also working for other consulting companies and on my own startup.
2006: Decided to try being an employee. Gained position that required Masters degree; I was the only applicant with the required experience. Need a degree to be promoted and a B.S. before a Masters so college while working full-time.
2007: Left company just before completing B.S. Management. Returned to consulting.
The first goal is to enter the field. Support centers always need people. Do not work phone support more than one year. Use the experience to learn everything and make friends to land the next job. Since the OP's goal is to be an administrator, the next job will likely be a junior administrator. Get promoted if possible, otherwise wait a year and move to an administrator position.
Reuse Code Or Code It Yourself?
Actually, the trick is knowing that you _aren't_ a great programmer (honestly what are the odds that you are a great programmer?), and thus choosing to reuse code from better (and hopefully great) programmers.
There's no such thing as a "great programmer" in the sense that one individual excels in every aspect of software development.
1. Being a great programmer is overrated. Producing more than 10 times faster does not result in earning 10 times faster. The pay rate for the great programmer is rarely double the rate for the normal programmer. The benefits of using a great programmer are reluctantly taken by customers. Projects budgeted for one year costing over $100,000 are completed in one month for $20,000, are better aligned with the business, provide more functionality, and are easier to maintain; customers still complain about the higher rate.
2. Great programmers could excel in every aspect of software development. That stated, we are humans with personalities including individual preferences. In the late 1980s, I thought about creating a Unix-like OS, but decided I would dislike creating and maintaining the project. Luckily, others with different preferences had similar plans resulting in Linux and the BSDs. My preference is application platforms, one level below building applications. My chosen specialty requires being expert at building applications and integrating with many systems (operating systems, databases, and clients e.g. browsers.) Does anybody think that RMS or Torvalds would have difficulty programming games? Their specialties derive from personal preferences, not abilities.
3. Great programmers will join existing projects. Using a popular project removes the work of creating and marketing early versions. A great programmer focuses on fixing problems with the software, including redesigning and rewriting whatever is needed to make the project do what the great programmer wants.
4. The OP has discovered that new specifications are difficult with the chosen framework. A normal programmer starts looking for a new framework. A great programmer has more choices:
- Work around the problems without discarding the current framework.
- Fix the current framework to handle the new requirements.
The former is possible because the great programmer does not accept the limitations of the framework. The latter is possible because the great programmer can quickly rewrite the framework without adding much to the project's budget. Normal programmers are more accepting of limitations, less likely to design workarounds, and cannot rewrite the framework in a reasonable timeframe.
5. Almost nobody builds "from scratch." Even if the OP discards the current framework, he will still use existing Java Web servers and operating systems. The choice is not whether to use others' code, just how much.
6. Solutions include:
- Building a new framework.
CONS: High maintenance, less expertise, future requirements may still exceed the capabilities.
- Switching frameworks.
CONS: Future requirements may still exceed current capabilities.
- Fixing the current framework.
CONS: Need to have improvements accepted by framework project to avoid upgrade issues.
- Redesign application to workaround framework.
CONS: Project is less maintainable as different functions use different methods.
No good recommendation is possible without knowing more about the OP's resources and problems.
- Can Hibernate be fixed to handle the new requirements?
- Is the Hibernate team already working to add these abilities?
- Can new functionality use JDBC directly without interfering with the existing code?
I would not discard the proven working code until the new methods have been proven stable and maintaining two systems requires more effort than replacing one.
Fuel Efficiency and Slow Driving?
I was going to post almost the same information. I was surprised another car also receives the best fuel economy at 85mph; most cars seem to like less than 60mph. Then I found your post mentioning you have a '00 TransAm WS6. My numbers are from a '99 TransAm and an '02 TransAm WS6; both 6-speed manuals. (I upgraded because they were being discontinued.) Like yours, 85mph is best; over 90mph starts eating fuel, and under 80mph loses at least 2mpg. My WS6 has never beaten 24mpg. The '99 reached 26mpg going downhill south from Harrisburg, PA to Charlotte, NC for over 400 miles without refilling -- cruise control and standing on the clutch to slow entering town areas with lower speed limits.
It is because our cars are cooler. The low drag is because we are not driving a block on wheels. The V8 engine and 6-speed transmission allow us to accelerate well and coast without going over 2000rpm.
Do you get better mpg because the West Coast is flatter? In the Philadelphia area, we rarely see a half-mile of road because a hill blocks the view.
In 2007, I did little highway driving and averaged 16mpg, never 280 miles between refills. In 2006, I almost reached 23mpg for a few tanks, but still only averaged 17.5mpg for the year. TransAms are not good if you care about fuel economy. [I don't. The '99 was traded after 3.5 years with 54K miles -- much driving for well-paid consulting work. The '02 is 6.5 years old and just passed 50K miles -- much working from home. I still enjoy all-day pleasure drives.]
solprovider hasn't submitted any stories.
solprovider has no journal entries.