In 2012 in St. Paul, Minnesota the Team One Club was founded for the exclusive developer of discerning taste. Membership includes nights out with Rocky Patel, Padrón, Doña Erô and Cohiba cigars and the finest of craft beer, scotch and rye whiskeys and of exceptional dining events.The content you are trying to access is only available to members. Sorry.
Check this device out: my old Palm M500. I dug it out of the boxes to see how it would work as a night bed reader, because it uses very little juice, you don’t need an overhead light (it’s backlit) and can do a reverse-color thing to keep the light wash down. Also, no internet so no temptation to suck my life away reading more Page 6.
Sure enough, the battery was dead.
Do you want one for Christmas?
On Amazon and EBay you can get a new battery kit for about $9 delivered. Excellent. So I ordered one up. You can also buy these Palms still for about $50 delivered. Some people I had read are using them for LCD interfaces for things like drone flying or Arduino projects. Maybe I’ll try that later on.
It also uses the Graffiti writing system, a short hand notation for writing in letters. Some of the newer generation probably never heard of it since Xerox held the patent for it and sued to have Palm stop using it and one. Xerox also produced the first marketable mouse computer in the early 1970’s and couldn’t market it like Apple later on in the 1980’s. I am guessing a lot of the newer generation never heard of Xerox either.
Here’s the kit, new batter on the left, and my opened Palm. I also have an aluminum case accessory you can see at the top. The kit graciously came with a new battery and little torx screwdrivers.
The Palm M500 cracked open.
The fix is relatively simple.
Check out the old battery that went bad (left) compared to the new battery (right) below.
The bad battery’s foil protective cover is puffed up. Lasted about 13 years, no bad. Cell phone batteries have this cover too, a great safety for your device against corrosion. Whoever thought of this cover was a usability genius.
Old battery (left) and new battery.
New battery installed.
Voilà.
I’m not quite finding the device an answer to my reading needs in bed, but it’s easy enough to load books with the SD slot. It’s just the resolution is too low. I do prefer it over my phone though.
I also pulled out my GPS unit that attaches onto the Palm. They thought of these kinds of accessories light years before Apple. This particular model works well — I used to use it mon my motorcycle in a tank bag and had music on it as well. Remember, at that time you didn’t have the all-in one phones. Stand alone GPSs still dominate as the usable way to go anyway (I have a Garmin wrist GPS and a Lowe GPS — both much better than a phone).
But I’m still going to have some fun with this Palm because I can program it. I will also pick up a GPS “shield” for my Arduino — maybe I’ll get on of those new mini-boards since I know some guys who do HAM/drones — and play around with that.
We’ll see. Lady Gaga is in the headlines again . . . .
Palm GPS unit on the color version (505) of the M500.
Our team had some of us working on master in our git repository, and a refactor was done in a branch so the team lead decided we should all move to from the master to the branch because the merge was painful for this particular feature. If you have this situation and a few commits in the wrong branch here’s a method that might help out using git reset and git stash. Reset can undo your last commit, and stash can save it off-stream to retrieve whenever you wish.
For this example I have several commits, not pushed, in the local repository already. Looking in Tortoise Git log you can see this state is three commits ahead of origin/HEAD.
The task here is to back out the commits from master, save them, then recommit them into the branch. There are several ways to accomplish this in git but I am showing the revert-stash methodology.
Before starting the process, my recommonedation (that you do not need to follow) is to make sure your stash was clear — I do so that I can just issue a series of pops to get back to my starting point easily on branch without worrying about mistakes.
git stash clear
Then clean up any other code/work in progress so that git status shows clean.
Next start backing out the commits back to the original HEAD. Each commit should be backed and saved atomically as a separate entry to your stash. For instance in this example, start at Commit 3 and work back to Commit 1.
git reset HEAD~1 //back out current top commit; 1 every time
git status //check and see what files you have to stash
git add -A :/ //stage all the files listed
git stash save Commit# //save the commit to whatever name you choose
git status //a good place to check status and Tortoise log
….repeat.
Now when you do git stash list you can see all the commits ready for moving to the branch, and Tortoise shows master at origin/HEAD so you know that all changes were removed.
Time to switch branches.
Issue a git branch -a to list all the remotes as well. Switch to your branch:
git checkout remotebranch
Now you can just pop your first stash right off the stack, confirm it works, check it in and move onto the next stash item:
git stash list //just checking
git stash pop //takes first one off list and deletes from stash list
git add -A :/ //stage everything
//--> do some merging/work as needed
mvn clean install //whatever build process you do to test and check
git commit -c "Commit#" //commit your code
git status //always check your state!!
….repeat.
Now sync it up with remotebranch HEAD:
git pull --rebase //just checking that I'm up to date
git push //send those commits to the homeworld
All done!
If you shift-ctrl-f or have a save function set to reformat your code in Eclipse, you stop it from formatting a java comment by using a “-” at the top:
/*- * Ignore Formatted Code Block * * myMethod() * * Main Point * sub point * * @method * @paramater * @exception */
If you don’t do this you may end up with something undesirable like:
/** * Ignore Formatted Code Block * * myMethod() * * Main Pointsub point * * @method@paramater@exception */
“Dang it, Walter, this isn’t a First Amendment issue!”
– The Dude to Walter Sobcek in “The Big Lebowski”
April 4, 2014 author’s note: A short time after I posted this a story broke on JavaScript inventor and Mozilla chief Brendan Eich related to this topic. I have a comment at the finish of this article.
It was some years ago when I worked on a project at a business that specialized in one of the myriad of health care services and after talking with many of my coworkers was quite surprised that about 80% or so — most of them — had a philosophical problem with what we were doing and did not believe in our product at all. Their actions outside the company were in direct conflict with our mission.The content you are trying to access is only available to members. Sorry.
I saw a weird usage of SQL in a Java application. Apparently whomever had written the code did not understand how to generate a new Entity with Hibernate and retrieve it’s primary key, and created a pkey field on a table that was, sometimes, string + integer. And sometimes just integer. In the test code though was needed to figure out how to get the maximum integer from that field to increment the next index (instead of letting Hibernate/database (MySQL) handle it. OK, the code is total B.S. but they had this little SQL novelty buried in the code to figure out it a field was a number or a string + number.
select * from table where concat('', pkey * 1) = pkey
I’m totally serial.
Started with a quick SQLite test. Say you have a table like this:
CREATE TABLE "badindex" (
"tkey" TEXT NOT NULL,
"tdata" TEXT
)
where tkey is the primary key. But its a string + integer, or an integer.
select * from badindex where concat('', tkey * 1) = tkey
OK, now note the concat operator — MySQL does not have a || operator (or + for that matter) for concatenation by default. I guess you need to be in ANSI mode and set PIPES_AS_CONCAT=true in the config. Whatever. So you need the concat() function.
I whipped the table up in SQLite and used this data:
| tkey | tdata |
| ss123 | test 123 |
| tt456 | test 456 |
| 789 | test 789 |
SELECT * FROM badindex WHERE ('' || (tkey * 1)) = tkey
Answer: I got the record back for tkey=789. In SQLite I also get the same answer back for this:
SELECT * FROM badindex WHERE (tkey * 1) = tkey
SQLite has no concat() operator so I used the pipes. When I looked at the SQL put in the code for MySQL, I became a bit suspicious that MySQL was doing a little more with concat() than just ANSI SQL. The man behind the curtain at work.
First, doing a little test in MySQL where tkey = ‘string1’:
SELECT concat('', tkey * 1) = tkey
Answer: 0.
BUT . . . .
SELECT (tkey * 1) = tkey
Answer 1.
Yikes. If I set tkey = ‘1’ then I get 1 back for both results. The concat() with a null string makes a difference.
I put the badindex table into MySQL, and here are my results:
SELECT * FROM badindex WHERE ('' || (tkey * 1)) = tkey
Answer: I got the record back for tkey=789.
Now this in MySQL:
SELECT * FROM badindex WHERE (tkey * 1) = tkey
Answer: I get ALL records back.
In MySQL, string * integer = 1 (true)
In SQLite, string * integer = 0 (false)
IN MySQL, concat('',string * integer) = 1 (true);
(note: implicit value of an integer -i.e. '789' becomes 789 - occurs when string = integer in both databases)
—
Personally I think using little tricks like this is not a good thing, especially if one doesn’t know how to use Hibernate in Java. I’ve spent many an hour pouring over Oracle code trying to figure out the man behind the curtain; a time waster. So I’d likely remove this, fix it proper so others can support it without the time waste, and go home.
Here are two techniques for debugging tests for Java Maven applications running Tomcat as you work in Eclipse. There’s usually a problem with having two processes running — your test and then your production code (Tomcat) in two different processes.
These tests are integration style tests that run code against something running in a Tomcat container that is started by Maven (along with a database). Throw your breakpoints in your test code AND your production code. Also, during the debug process you might have to attach your source code for your production code; it’s not difficult. You might have to restart the test after that . . .
Method One — Everything in One Process
You can run everything with a Maven configuration in eclipse, but it takes a bit longer for it to run. Setup a new Debug Configuration–>Maven Build in Eclipse. Mess around with the setup, but this works for me:
Notice in the goals I have
-Dtest=IntegrationTest_1_Test -DfailIfNoTests=false clean install
If you have a more complex parent/submodule Maven pom setup like I do, you’ll need the failIfNoTests so that the entire thing can build before Tomcat kicks off. (Also depends on your project setup in the pom).
Method Two — Remote Process
This method has a few steps but works a bit faster.
1. Start up your maven tomcat process in DEBUG mode from a command line. You used to have to set a bunch of MAVEN_OPTS (and still can), but i Maven 3.0.5 and higher you can do this easily with a default port of 8000 by running mvnDebug instead of mvn:
start mvnDebug compile tomcat7:run
You get something like this as it waits:
2. Create a DEBUG configuration for the remote port in Eclipse with port 8000, then start it with the Debug button:
3. Run your test like you would in the IDE normally — no need to run it via Maven. If you Debug your test — then you can throw breakpoints in the test and the code running in Tomcat. If you just Run your test you will only hit the Tomcat breakpoints.
(On my local I’m running Groovy 2.1.9 on Java/JDK 6).
Was having a Discussion of final and static, and decided to try something in groovyConsole. In the Java world, a final variable cannot be reassigned a value once initialized.
Groovy Code:
final String i = “test”
println i
i = “red”
println i
Output:
groovy> final String i = “test”
groovy> println i
groovy> i = “red”
groovy> println i
test
red
Interesting — Groovy completely ignored final. If I plug the code into a Java compiler I get a compilation error — can’t reassign.
I sent this off to a buddy of mine who teaches Groovy to corporate and he found it odd, and said this behavior happens for this example as well:
Groovy Code:
def junk() {
final int a = 42;
a = 99;
}
println junk()
Output:
groovy> def junk() {
groovy> final int a = 42;
groovy> a = 99;
groovy> }
groovy> print junk()
99
The discussion is a little extended, found this though — the issue for final is still open as of this date (March 12, 2014):
http://jira.codehaus.org/browse/GROOVY-4681
Staging in git is when you gather all the files you want together, new, deleted, and unchanged — for a commit. Once you commit them they are tracked as a commit with a message and a number, and then available to push to a central repository or where ever.
I use the Tortoise Git GUI before I check in that can add/stage in one commit action, then a separate push action. It’s because I need a graphical view of everything to eyeball before committing. The command line doesn’t really do it for me, especially if I have a large commit.
But the question often comes up – how to stage manually in git?
Here’s staging from the command line as I do it. There are two methods that I know of right now.
Navigate to your directory – I usually do this from “parent pom” directory so I can also maven build (for us java developers). But somewhere in your local repository.
Git’s “add” is a bit dual-meaninged, like many git commands (merge for example which is different for branches versus clones). It can mean “track me now and stage me” and it can mean “just stage me.” This idea can be confusing — for instance with a new file why not “add” then “stage”? But it’s all one execution in that case.
Generally there are three states to “add” to a stage —
Atomic Staging
First, I use “git status” to see what’s up. It lists everything changed and everything not tracked by the repository yet.
What I usually do is this for the atomic method:
git status //see what’s up
git add <new file>
git add <changed/deleted file>
To unstage your changes use
git reset
Recover a deleted file with
git checkout — <file>
Be sure to use the full path from git status
After staging –> commit, push.
Interactive Staging
You can also do this same thing interactively, which is what I use – git add interactive.
git add -i
Command 4 let’s you stage the new file by its number, and command 2 let’s you stage a changed file by its number in a list that is presented to you in both cases. Command 3 let’s you revert from stage very easily.
You can check it out more in depth here:
http://git-scm.com/book/en/Git-Tools-Interactive-Staging
https://www.kernel.org/pub/software/scm/git/docs/git-add.html
After staging –> commit, push.
I do not do blanket adds, like git add –all because one never knows what file is NOT ignored that may pop up into the directory! Like a new .project file or some funky log file.
I *always* diff all files before I check in.
I *always* eyeball my file collection before I stage.
I *always* eyeball my commit before committing.
A few weeks ago I attended a nice little presentation about GIT at our local Chippewa Valley Developers Group meeting. After the show, and discussing the presentation over a couple of brews with a configuration manager and a low level C++ engineer — we thought that a lot of things weren’t clear like release strategy.
I remember when Subversion came out, I was really keen on it because it had a very loose workflow, easily adaptable to many technical processes. In fact if you’ve ever kan-banned, the board *really* starts to look like a release process especially if there are different server environments for say Java web apps. Won’t get into just how bad those environment columns can get – I’ve even seen a board with at least 20 columns of tasks taking up an entire 10X20 ft. wall! A wee bit too much. Git is also loose in this manner, and in my use of Git — I have more experience in Hg and Darcs — and talking with a lot of different points of view I think a pattern emereged that is a great practice for developers.
Festus says — “Why don’t you just go on an Git?”
Here are the two revelations about Git I’ve arrived at:
The first revelation led to the second revelation. But for some reason, in the merge/rebase wars — it was forgotten that a loca branch/master merge was quite differnt than a master/origin merge.
The question that led me to this was, I thought you applied a typical master/origin workflow to a branch. That is, that the realtionship between branch and master was the same as master and origin, such that in branch you would pull –rebase to sync up with master. Not so. There is no pull activity, unless you wish the branch to pull from origin.
The second question was, discussing with the config manager — how to bundle features in such a way that it’s useful to them. It’s a matter of “repository scope.” So this came out of that discussion:
Hence, the branch/master merge creates that package whilst retaining those atomic commits.
For the my developers my workflow is now this when I am assigned work, for a branch named topic:
git checkout -b topic
do a bunch of work . . . .
git commit -m "topic commit 1"
git commit -m "topic commit 2"
now update master from origin . . . .
git checkout master
git pull --rebase
sync my branch to master. . .
git checkout topic
git rebase master
merge into master . . .
git checkout master
git merge topic
and (after checking for changes) push . . .
git push
Onto solving the second part, making commit’s for a config manager.
Note that Git implicitely does a “fast forward” merge for master/branch that plays my commits on top of the master, but there’s never a record of the merge. IN a lot of cases this might be OK, but in many cases we may want a *real* feature branch to retain its unit of checkin. For instance, say the branch was a whole new package, in which case for the config manager we want to do a non-fast forward merge that will remember the commits, but also retain the branch information.
git merge --no-ff topic
Some utilities like “squash” seem like a bad choice for this because they toss the history out — bad for the developer. But this no fast forward merge can do the trick; retain history in all scopes.
(From nvie.com, Vincent Driessen, post “A successful Git branching model“)
The impact of doing development like this is far reaching. For the last years I have been on Subversion checking directly into trunk; and Hg managed a lot of merge and commit history with less work than Git. But the Git community has brought it to my attention — ALWAYS CREATE A BRANCH before you develop.
I wonder how this will impact code writing. Making a feature being aware that it should be able to be reverted when you check it in is WAY different than checking in non-accessible work-in-progress or hard coding out features.
My personal feeling is that to some extent this is a pipe dream. Many projects have some developers changing underlaying libraries while the rest build on top of them — the unit of a “feature” does not sit at the checkin level. So more hands on and use cases are needed to improve what we do, no doubt.