Some people reading this post will already know about the bug of which I speak. For those of you who are unaware, I give you Eclipse bug 8009. This is the Eclipse Bugzilla entry for the absence of split editor windows in the popular IDE. The bug is now over 10 years old. The bug has a very rich history, and I encourage you to read through at least a portion of the thread. One of my favorite parts is at the very end of the comment history, where folks raise a glass to toast the 10 year anniversary of the bug. I also enjoyed the attempt to fill a virtual tip jar with money to bribe the developers to implement this feature. It looks like they raised at least $270.

I recently had the unfortunate experience of revisiting this bug (hadn’t seen the thread in a while) because of the newly released Eclipse 4.2 (Juno). At SlickEdit, we are currently working on our next version of the SlickEdit Core for Eclipse plugin, which will be built on Eclipse 4.2. In Eclipse 4.2, the split editor window problem has again become a major hurdle. I’ll refrain from voicing any dissenting opinion about the new UI released in Juno, though all the criticism seems to be warranted, and focus on the issue at hand. Several plugins, ours included, have implemented their own ways of providing split editor window capabilities within Eclipse. These implementations may have relied on internal APIs (bad practice), but there was no publicly available way to go about providing this feature. So we did what we had to do to provide what our customers wanted. Eclipse sure didn’t seem interested in actually providing a way to split an editor window in their IDE (remember, 10 years). And please don’t say, “Click and drag the window.”

Enter Juno, the new Eclipse workbench UI, and API changes which have broken these implementations. Of course there is no guarantee that internal Eclipse APIs will not change or break between releases, so this to no fault of Eclipse. Although maybe if the bug was addressed sometime in the last 10 years this wouldn’t be such a problem in the first place.

For now we are left searching for another workaround, and checking the status of this epic bug. The comment history has gone through a civil phase, a nasty phase, and then what seems to be phases of disbelief, and now acceptance. I really just wanted to share this thread to some who might not have seen it before. Maybe now you feel a little bit better about some of the long-standing bugs in your code. I hope we don’t ever have to toast them.

I can’t be the only person who is very disappointed with the new iPhone 5 screen size. If you are too and are considering an alternative like the Samsung Galaxy S3, this article may help you.

After using an iPhone for about 3 years I decided to switch to the Samsung Galaxy S3. I loved my iPhone but the new iPhone 5 screen size simply is not wide enough for me. I couldn’t believe Apple wouldn’t make the screen wider. Choosing the right smart phone depends on what features are most important to you. For me, I was in desperate need of a bigger screen so I could read more on my phone and the S3 seemed like it would be worth the effort of switching.

The tasks I use my smart phone for

Most important:
email, phone calls, calendar, browsing

Some must haves:
camera, notes, weather, movie show times/reviews, stock quotes, stock trading, YouTube, Engadget (yep, I like to read about gadgets!)

Some nice to haves:
sports scores, live sports videos, TV Guide, calculator, poker with computer, black jack with computer

As you might have guessed, my smart phone is primarily used for work. I removed the Facebook app I had because there were too many notifications. I don’t have much time for games, something I suspect the iPhone is better at. While I listen to some music on YouTube, I haven’t purchased much music from iTunes. I did buy a ring tone as well as create one from a song I purchased. As far as apps go, I purchased two apps, one of which is now free. Hah, I’m not locked into Apple (“you will not assimilate me”).

Configuring the Samsung S3
I spent at least 12 hours configuring my phone. That should give you an idea of how bad I wanted to benefit from my new 4.8 inch screen. My time was spent finding and configuring apps, and learning how to be productive on my new S3. I wasted a lot of time getting my email to work well. Thankfully someone else took care of rooting my phone and installing CyanogenMod. I didn’t have to root my phone but I decided I wanted to be on the bleeding edge so I could have the latest greatest android features and fixes. I love the new default keyboard and the ability to configure my home screen icon grid to 5×5 instead of 4×4.

I highly recommend changing your font size and choosing something smaller if you have good eyes. I set the font size to “small” and this allows me to view more text in the apps that matter to me. If you don’t do this, you might as well be using an iPhone because the default fonts on the S3 are pretty large.

Email is not so great on android
The iPhone has one email app which works well with Yahoo email, Gmail, and Microsoft exchange (ActiveSync). The S3 and most android devices as of this article ship with two email apps. The Gmail app only supports Gmail. The Email app supports all the other typical providers including Gmail. Sounds good right? Here’s the catch, the Email app doesn’t support push notifications with Yahoo email (it does for Gmail if set up using Google Sync). For me, having push email for Yahoo was a requirement. That way I get my emails very shortly after they are sent and conserve battery life. After trying some other email apps, I liked MailDroid the best for providing push notifications for Yahoo mail and Gmail. Unfortunately, it doesn’t support ActiveSync yet due to Microsoft licensing issues so I have to run two email apps. The Email app looks ugly to me especially when writing an email (I won’t go into details here). It’s not a perfect solution but it gets the job done. I needed to tweak more settings than I expected for the Email and MailDroid apps to behave the way I wanted. In addition, I had to download Adobe reader for reading PDFs. The iPhone email app just works. For me, the iPhone email app is better than any combination of email apps on Android but I do like Androids ability to operate on multiple emails at once (say to delete several emails).

Advantages of S3 over the iPhone:
(keep in mind, this is based on my needs and not necessarily yours)

  • Big screen so you can read more. By far, this is the biggest benefit.
  • Pictures and Videos look better due to the larger screen.
  • More icons per home screen.
  • Back button at the bottom of the phone. The iPhone really needs this for better one handed phone use.
  • Widgets (like contacts and weather) can be placed on the home screen just like apps!
  • Menu button at the bottom. The iPhone needs this too but since many apps have buttons at the bottom, it’s not that big a deal.
  • Better keyboard enhancements. With CyanogenMod or the Swiftkey app, hold the period to get a menu of common punctuation characters.
  • Good support for multiple browsers or email apps.
  • Easier to configure home screens. I especially don’t like how iOS auto arranges icons!
  • Many more configuration options. I’m starting to really like this.
  • Easier to root phone. This provided me with a better keyboard and more icons on the home screen.

Advantages of iPhone over S3

  • Easier to use and configure. More things just worked for me with less or no configuring (visual voice mail, email, iCloud).
  • Security. Arguably better because apps go through an Apple review.
  • UI experience. More of the apps I’ve seen have a consistent look and feel with good looking graphics.
  • Apps. This will be very different for everyone. For me, the following apps are slightly better on iPhone: email, ScoreMobile, calendar, TV Guide, and WeatherBug. Although, Mobi Calculator Free is better than any iPhone calculator app I tried.
  • Touch screen. I find the iPhone screen slightly more accurate/responsive.
  • More pixels per inch so you can read smaller fonts. This is valuable when the browser displays something very small.  The whole Retina display thing has value but I’d rather have a larger screen so I can read more.
  • Cut/paste is slightly easier on iPhone because the popup is closer to your finger. There is also a problem on Android if you want to select and copy text from the first line of the screen (Yes, I ran into this problem).
  • Bluetooth for car just works. Like many, the S3’s Bluetooth for my car has problems.

This was my experience switching from the iPhone to the Samsung Galaxy S3; while it may not completely match your’s, there will probably be some overlap. If you’ve been using your iPhone for a long time, it will take you a while to make the switch. In general, the S3 is better suited for users interested in fine-tuning their environment and who do not mind spending the time to do it. Android has come a long way and I can definitely say that I’m enjoying my S3. Android needs to continue to improve the apps ease of use and automation (reducing setup time). For me, I would like the features for some of my favorite apps improved. Apple had better come out with a larger phone than the iPhone 5 soon because Android has a significant edge with so many form factors. Its a bit like TVs where a lot of the value comes from the size and quality of the screen. Like I said, one size doesn’t fit all.

I like to open with a joke.  I won’t this time, I’ll close with one.  And then I will let Bob Newhart make it funny.

I have spent my entire professional career at here at SlickEdit, and almost from the start, I have handled our version control support.  This means a couple of things:

  • I have only used (on a day-to-day basis) the version control systems that we have used here at SlickEdit.  In the early days we used our mutli-file diff feature.  I prefer to think of this as a testament to how good our diff feature is rather than what you are thinking – which is probably “that is pure insanity”.  In later years we used CVS.  Eventually we moved to Subversion.  A little sooner than we wanted because of how it handles branches – this is another story.
  • Because I have to handle supporting them in SlickEdit, I have tested most of the free and commercially available version control systems (and a few that are no longer commercially available) on small source bases.  I have not actually used all of them, I have some experience with them.  The technical term for this in our industry is, “I know enough to be dangerous”.

We have 3 kinds of version control support in SlickEdit:

  1. Basic “command line” support, where we will run your checkin command according to a specified command line where the file name is filled in.
  2. SCC support – For version control systems that have an SCC provider, we will communicate with it and provide the level of support that SCC allows for.  This can be frustrating because if an SCC system crashes, it will cause SlickEdit  to crash.  This happens occasionally because SCC providers tend to do their testing with Visual Studio, and not other systems.
  3. “Specialized Support” – This is what we provide for CVS, Subversion, git, and now Mercurial.  We provide a GUI for viewing what files you have modified, what files are out-of-date (where possible), and a nice history dialog, among other things.  Initially we did this sort of support for CVS because it was a different animal than the systems supported by 1 and 2.  CVS is more directory oriented, rather than file oriented.  This is true of all of the systems that have this kind of support.
Unfortunately, none of our support is a replacement for a basic level of understanding of  how to use your version control system.  This is increasingly true as time goes on.  If you do not understand how Mercurial works, even though we provide some nice GUI interfaces, using Mercurial through SlickEdit will still prove confusing at best.  For Mercurial specifically, I would recommend the Joel Spolsky tutorial, especially if you are an experienced Subversion user, as it is tailored for that.  Joel’s assertion is that Mercurial is better.  As of this writing, I still prefer Subversion, but he makes some interesting points.  Either way, it is an excellent introduction to Mercurial.

So, now SlickEdit supports Mercurial, which a little different from git, which is a little different from Subversion, which was a little different from CVS.  So, if you’re sitting at home in your basement (excuse me, “office”) writing a version control system that is going to solve the issues with Mercurial that weren’t solved in git, that weren’t solved in Subversion, that weren’t solved in CVS, I would like to say (politely):


Enough already.  The next version control system released needs to offer some real improvements over what is currently available.  Since I have to support it, I’ll be the judge of what is a real improvement.  Just contact me here… I’m easy to find.  I’ve been here my entire adult life, integrating version control systems, comparing files, and working on my manifesto (no, this isn’t it.  This doesn’t even scratch the surface).

P.S. The last couple of paragraphs are supposed to be funny.  I understand the differences/advantages of  these different systems, you don’t need to leave me nasty comments.

P.P.S. If you didn’t find any of what I wrote funny, take a few minutes and allow Bob Newhart to make you laugh.

If you don’t find this funny, I can’t help you.

« Previous PageNext Page »