[Developer] Software for beginners

One of the interesting things about the Apache Derby database is that it’s often the first database that a beginning programmer is exposed to.

One of the reasons for this is the wide distribution of Derby:

• It’s free, and open source
• It’s the most prominent database in the Apache Software Foundation (although it may be losing that place as other databases are added to the Apache umbrella
• It’s included as part of the JDK download from Sun/Oracle
• It’s bundled and embedded inside the NetBeans IDE from Sun/Oracle
• It’s bundled and embedded inside the Glassfish application server from Sun/Oracle

For whatever reason, it seems quite common that new programmers, just beginning to get into the “serious” phase of the programming education, often come across Derby very early in their exposure to databases.

For this reason, I think that it’s a very good thing that Derby is quite careful about the database implementation that it provides.

The Derby implementation of SQL is very traditional; it conforms quite tightly to the international SQL standards and behaves in the most correct manner in its implementation.

This gets programmers off to a good start.

Later, when they are more fluent in database concepts, have built some database applications, and are no longer struggling with the basic ideas, they can move on to other database implementations and start experimenting with variations and embellishments.

But there is a very long ways you can go while still adhering to the core SQL standards, and the knowledge you gain while working with Derby will be transferable to all those other wacky not-quite-standard databases you’ll meet out there in the real world.

So the next time you wonder why the Derby developers are a bit touchy when they get asked why Derby doesn’t implement your favorite database’s Wacky Feature #39, remember that Derby is often software for beginners.

And beginners need to get off to a good start.
Author: Bryan Pendleton
Source: bryanpendleton.blogspot.com

[Tech] JSpeak - The Ultimate in Linux Text-to-Speech Software

JSpeak is a FOSS (Free Open Source) Application I created for Linux, the only of it’s kind. 

It’s full of features. It’s primary feature is it’s ability to read text copied to the clipboard. It also can use Mbrola voices. It expands and retracts to a smaller graphical user interface that is perfect for hovering over your ebooks, websites, etc. while reading from them. It’s located on Github at 
https://github.com/BullShark/JSpeak under the GPLv3 and above, free of charge. 
The full instructions on getting it running and how to use it are there on that github link. There is also a wiki there on Github.

Please check it out. I would really appreciate it as well as any feedback and/or support through donations. If you like this software, please make a donation to help further development here on my blog. Thank you.

A few screenshots running under Fedora with Gnome3

Author: Christopher Lemire
Source: linuxinnovations.blogspot.com

[Tech] Bodhi Linux gets E17 Stable Packages

Less than two weeks ago the E team finally had its stable E17 release. The Bodhi team and I have been working hard to deliver this release to our users in its best possible form in a timely fashion. Today we are happy to announce that these stable E17 packages have made their way into Bodhi’s main repo. Existing Bodhi users can upgrade their systems to these latest packages by following the instructions detailed here.

Please be aware of a few things when upgrading to these packages:

First, since this is a major E17 release all current user configurations have to be reset. This means all of your current custom E17 profiles will need to be recreated starting with one of the Bodhi default profiles.

Second, the terminology terminal emulator has been having some stability issues with its most recent release. Because of this, I would highly recommend installing a secondary terminal emulator before installing these upgrades.

Finally, all of our wonderful E17 themes need updates to function with this latest E17 release. Currently we have around twenty themes that function well with the latest release. You can find them on our brand new art page.

Enjoy this fantastic new E release, folks! Also, please remember do NOT post support request on this blog post! We have a forum for that.

Also - for those wanting a brand-spanking new install with E17 stable - our Bodhi 2.2.0 discs should be out of testing by the end of this week.

Almost forgot! Happy 2013, folks.

Cheers,
~Jeff Hoogland
Author: Jeff Hoogland
Source: jeffhoogland.blogspot.com

[Developer] Enterprise admins: here’s how to help your software be better

Here’s a great short list of smart ideas from Bruce Momjian of the Postgres project:

Users must also provide a reliable platform to run database software. Postgres can’t maintain high reliability if it is dependent on an unreliable platform. Here are some of the things users can do to provide a reliable platform for Postgres:

• Choose an operating system whose focus is on reliability, rather than desktop user experience or supporting the latest hardware or software
• Choose hardware designed for 24-hour operation in a demanding environment, not desktop hardware
• Use hardware that reports errors, like ecc memory and smart storage
• Make sure your storage system performs reliable writes
• Have on-site and off-site backups for cases when disasters happen
• Educate administrative staff so mistakes don’t cause downtime

It’s just amazing to me how many times I hear of sites that tell me about their great new server, but have no idea:

• What sort of memory they are installing into their machine
• How the machine’s power consumption and heat output compares with the provisions they’ve made for power and air conditioning in their machine room
• Whether they have a UPS system, and how it’s configured, and whether they’ve tested how their operating system responds to a UPS-initiated power emergency
• Whether they know how to read their RAID system’s reports, and whether they know what a “disk failed” alarm would look like, and what they’d need to do when one occurred.
• what their backup policy is, and when they last ran a full test of restoring from and failing over to their backup.

As Bruce said, don’t depend on your server software to solve all these problems for you.

As is the case with systems software, systems administration has evolved considerably over the years. The Usenix organization runs a great annual conference called LISA; the 2012 meeting just wound up, and there’s a great set of materials on the LISA web site. If you don’t ordinarily pay much attention to system administration, it’s worth checking out the LISA conference site periodically, to keep abreast of what the world’s sysadmins are spending their time worrying about.
Author: Bryan Pendleton
Source: bryanpendleton.blogspot.com

[Solved] msmtp – a (fairly) simple mail submission program

As an oldtime Unix guy, I’ve always been used to having the BSD mail utility to hand, and a suitably configured mail system, so that I can script jobs to run and email the results back to me. I use mail as a sort of glorified syslog facility. With smaller single board Linux computers we don’t always want to install a full mail setup – resources often tend to be limited. A few years back I discovered msmtp http://msmtp.sourceforge.net/.

This utility is an smtp client that submits a file in standard mail format to a mail server. It can submit plain text email or use TLS/SSL etc. I use a couple of script wrappers to emulate, sort of, sendmail and the sending part of the BSD mail utility.

Of course to use msmtp you need a mail server to which you can submit email for delivery. My home server is my mail server, but you could use your ISP’s smtp server. Another problem is that msmtp just fails if it can’t connect to the mail server – it’s up to you to handle that and do something else with that precious message you can’t mail just now! My sample scripts do not deal with that situation.

This very simple script I call sendmail, and it will need customising for your setup…

#!/bin/sh
#

# set these for your setup...
MailServer=mail.server
Domain=MachineName
From="me\@my.domain.com"

exec msmtp --host=$MailServer --domain=$Domain --from=$From $*

This is my simple script to emulate the simple parts of the send functionality in the BSD mail utility. It has many shortcomings, but it has served me well…

#!/bin/sh
#
# A sort of shell replacment for the send functionality of
# the standard "mail" utility.
#
# mail [-s subject] recipient(s)
#

u=`id -un`
d="my.email.domain"
r=""
s=""
v=""

while [ $# -gt 0 ]; do
 p="$1"
 shift
 case "$p" in
 -s)
        s="$1"
        if [ $# -gt 0 ]; then shift ; fi
        ;;
 -v)
        v="-d"
        ;;
 -*)
        echo 1>&2 "Option \"$p\" not recognised."
        exit 1
        ;;
 *)
        r="$r , $p"
        ;;
 esac
done
if [ "$r" = "" ]; then
 echo 1>&2 "No Recipients."
 exit 1
fi
if [ "$s" = "" ]; then
 printf "Subject: "
 read s
fi

s="Subject: $s \n"

(echo -e "From: ${u}@$d \nTo: $r \n$s \n\n"
 cat ) | sendmail -t $v

So if you have a job to run on the platform, then this will email the output to you…

my_job | mail -s “my_job output” me@my.email.add

msmtp can be loaded from the package systems of most distributions, but I have had occasion to cross-compile the package for installing on a system without package management. I had only limited libraries on my cross compile system, and found that after downloading and extracting the sourcecode from sourceforge, I had to cross compile without some of the advanced features. I used

./configure –build=arm –disable-ssl –disable-gsasl –disable-nls

before doing the make to build the binaries. The resultant binary just submitted plain text email, but that was ok for my use – YMMV. The resultant binary, suitably stripped,is pretty lean.

I recently revisited using msmtp to pre-test a change to my ISP’s new smtp server, before committing the change to my mailserver’s sendmail setup. It can also be useful for testing security settings etc on mail submissions systems.

Jim

Author: Jim@TheDailyLinux
Source: www.thelinuxdaily.com

[Developer] The unfriendliness of software

John Battelle and Scott Hanselman wonder about software:

• AM I AN OUTLIER, OR ARE APPLE PRODUCTS NO LONGER EASY TO USE?

  I spent a few more fruitless hours trying to find another solution on the web. There wasn’t one that didn’t require pretty significant technical know-how (such as installing a utility, running it to reveal all files on the iPhone, then deleting each file one by one, even if you weren’t sure what the file did). The only option that was relatively straightforward and seemed to work, according to many forums, was to restore the phone.

  Which I did. And I lost all my apps save the ones that come preinstalled on the iPhone in the first place. And guess what? It didn’t fix the problem.

• Everything’s broken and nobody’s upset

  Software doesn’t work. I’m shocked at how often we put up with it.

Interestingly, although both Batelle and Hanselman fill their rants with a number of instances of actually buggy software, for the most part what they are complaining about is two things:

1. It’s hard to design a simple UI for feature-packed software, so you end up with powerful software that requires training, experience, and motivation to use efficiently

   You need a four-hour class just to understand all the contortions Apple seems to be doing in its attempt to make its desktop interface work the way the iPhone does. You know, pinch and swipe and app stores and mission controls and magic corners and all that.

2. In the attempt to design a simple UI, products often hide unimportant details that turn out to be important details, and then you find yourself at a dead end.

   The phone is pretty much useless now, because all of its storage is taken up. With what, you might ask? Well, it’s a mysterious yellow substance – found, in a masterstroke of intuitive design, in iTunes – called “other.”

   My iPhone 4s has 3 gigs of “OTHER” taking up space, according to iTunes. No one has any idea what other is and all the suggestions are to reset it completely or “delete and re-add your mail accounts.”

This is an interesting discussion, and not a new one. Let’s turn to Professor Tony Hoare’s brilliant Turing Award speech, now entering its fourth decade:

Programmers are always surrounded by complexity; we cannot avoid it. Our applications are complex because we are ambitious to use our computers in ever more sophisticated ways. Programming is complex because of the large number of conflicting objectives for each of our programming projects.

…

I conclude that there are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies.

This stuff is very hard; which is, of course, why we become obsessed with it and spend our lives doing it :)
Author: Bryan Pendleton
Source: bryanpendleton.blogspot.com

[Developer] Senior Software Engineers, Technical Leads and Architects !!!

Author: Yumani Ranaweera
Source: yumani.blogspot.com

[Developer] Simple hardware lessons for a software guy, part 3

Good things come in threes, right? So this poor software guy is happy that he’s had some great opportunities to learn about hardware over the last few days.

The third of three is Robin Harris’s fascinating article: The post-RAID era begins.

Harris starts out by pointing out that simple RAID 5 algorithms are failing to scale due to the immense growth in disk capacity.

He proceeds to discuss the substantial progress that is being made in “erasure coding”, which involves new ways of encoding stronger parity checks into your data.

In the ’90s a new form of erasure coding was developed that enabled developers to create codes with an arbitrary level of redundancy – survive 4 failures? 10? Pick a number! – called fountain or rateless erasure codes.

Harris suggests that in the (near) future, storage systems will no longer be using simple RAID techniques, but instead will be using the more sophisticated erasure coding technology, and references a number of startups who are active in this area.

Harris also links to a nice presentation by Professor Jim Plank of the University of Tennessee: Erasure Codes for Storage Applications.

The Point of This Tutorial

• To introduce you to the various erasure coding techniques.
  • Reed Solomon codes.
  • Parity-array codes.
  • LDPC codes.
• To help you understand their tradeoffs.
• To help you evaluate your coding needs.
• This too is not straightforward.

Professor Plank’s web site is loaded with lots of additional information about erasure coding.

Thus ends our short three-part series of the software guy learning more about hardware…
Author: Bryan Pendleton
Source: bryanpendleton.blogspot.com

[Developer] Simple hardware lessons for a software guy, part 2

It’s more than just networking hardware that mystifies software guys like me. Take, for example, the incredibly sophisticated memory caches that are found on modern CPUs.

I recently came across a superb paper by Paul McKenney of IBM’s Linux Technology Center: Memory Barriers: a Hardware View for Software Hackers.

McKenney’s paper sets out to teach software types like myself just enough about the design and implementation of cache coherency algorithms in modern multi-core processors so that we can write software that is both correct and efficient.

The hardware designers cannot help directly here, since the CPUs have no idea which variables are related, let alone how they might be related. Therefore, the hardware designers provide memory-barrier instructions to allow the software to tell the CPU about such relations. The program fragment must be updated to contain the memory barrier

The paper is clear and straightforward, with great diagrams and examples. I particularly enjoy the “quick quiz” format, in which McKenney intersperses review questions in the text, and provides answers at the end of the paper so you can periodically stop, take the quiz, check your answer, and keep going.

If you’ve ever wondered about the MESI protocol, or about store buffers, or about writeback, snooping, and invalidation, or how the DEC Alpha processor impacted the Linux kernel memory-ordering primitives, don’t hesitate, dig right in!

This is the sort of paper that every system software engineer should read, understand, and periodically re-read. Thank you IBM and Paul McKenney for making it available!
Author: Bryan Pendleton
Source: bryanpendleton.blogspot.com

[Developer] Simple hardware lessons for a simple software guy

Being a software guy, I don’t know much about the hardware that I use. Oh, I understand it at a conceptual level, but I sure wouldn’t know anything about how to choose the right line card for a Cisco 6500.

So I’m a software guy, I admit it.

But I still find it helpful to know something about hardware, and so I love to find useful helpful information like Greg Ferro’s great article: Top 20 Practical Cabling Tips for Network Engineers – Part One.

It’s easy to read, and full of obvious-in-retrospect-but-maybe-you-never-thought-about-it advice like:

Hanging cables within the rack means that means that gravity will induce physical stress on the copper core which will stretch and distort over time. A longer patch lead is heavier and will cause more shear stress on the cable. This will create signal degradation over time and leads to intermittent failures over time.

Greg Ferro is a great author to follow, if you aren’t doing so already; keep those tips coming, Greg!
Author: Bryan Pendleton
Source: bryanpendleton.blogspot.com