Tag: Windows

When doing usability testing of an alpha version of Dashman, one thing that I was strongly asked was to have the windows remember their sizes when you re-open the application. The need was clear as it was annoying to have the window be a different size when re-started.

The new version of Dashman is built using Java and JavaFX and thus I searched for how to do this, how to restore size. I found many posts, forums, questions, etc all with the same simplistic solution: restoring width and height, and maybe position.

What those were missing was restoring whether the window was maximized (maximized is not the same as occupying all the available space, at least in Windows). But most important than that, none of the solutions took into consideration the fact that the resolutions and quantity of screens could be different than the last time the application run, thus, you could end up with a window completely out of bounds, invisible, immobile.

I came up with this solution, a class that’s designed to be serializable to your config to store the values but also restore them and make sure the window is visible and if not, move it to a visible place:

I haven’t put a lot of testing on this code yet but it seems to work. Well, at least on Windows. The problem is that this snippet is interacting with the reality of screen sizes, resolutions, adding and removing monitors, etc. If you find a bug, please, let me know and I might release this a library with the fix so we can keep on collectively improving this.

Advertisements

Share:

Like this:

If I was in charge of GitHub, I would build a team of .NET Programmers and have them built an awesome UI for Git on Windows, bundle it with Git itself as well as other usually needed programs like an SSH client and release it for free. Well, as open source of course.

The reason for that is that almost everybody that I know that’s using Git is also using GitHub and the number one objection I get to Git is Windows support. I myself chosen Mercurial once before just to be able to cooperate with my Windows-using friends. I think it’s time someone fixes that and I think GitHub has the most to win.

I know Git can be installed on Windows and that it works. But you need more than that. You need on amazing user experience and Git on Windows doesn’t provide it.

There are several reasons for that. Running Git in Windows is not as nice as Linux or Mac OS X, period. Even if the support was realyl good, the command line itself in Windows is not on par with Bash… even when you run Bash itself on Windows (which the last time I checked, you had to do to run Git).

Most important than that is that the Windows crowd are just used to UIs, so the most amazing command line tool won’t stand a chance against the crappiest UI. Windows users just search for another tool when no UI is provided. Even myself when using Windows do that. It’s another world with another dynamic and you have to play by their rules to win their game. And I have to admit, if I had to stop using MacOSX I would miss my favorite Git UI a lot, GitX (L).

Share:

Like this:

Once again I hear Joel Spolsky saying the same thing about Linux that I consider wrong. I’m sure I’m not the only one thinking that and I’m sure I’m not the only one writing about it, but I’m going to do it anyway. Joel’s position is that administrating Linux must be harder because something like 70% of the support calls they handle for FogBugz come from Linux while it is less than 30% of its market.

I’d agree that for someone that doesn’t know anything about administrating, getting a Windows server running is easier than getting a Linux server running. I think that being an expert in both environments is equally hard. The sysadmin problems are hard and there are no shortcuts.

But Joel Spolsky point is wrong in one regard: Linux is not an operating system. I’ve said it before and I’ve got many negative comments, mails, messages about it but very few actually got my point. This is an instance where Linux being taken for an operating system is causing someone pain and thus causing that someone to say something that is not completely right.

Joel makes FogBugz for Windows and Linux. Does that mean that I can run it on my Windows CE phone? It is a Windows, isn’t it? It says Windows in the name! It has a start button! Well, of course I can’t run FogBugz on it. They ship it for Windows the PC operating system. Does it work on ReactOS then? In a sense it is a Windows PC operating system; an alternative implementation of one with all the same interfaces and libraries. Well, of course not. It work only in the Windows PC operating system produced by Microsoft. For example, Windows 7 Starter Edition, yes, that one that allows you to run only three apps at the time. Well, no!

All those things I mentioned are in a sense Windowses as well, yet they are not supported and probably FogBugz doesn’t work on them. Yet, he says he supports Linux. Saying you support Linux is like saying that you supports computers that have RAM. It’s too broad. Trying to ship something that should run on almost everything won’t work. Be it Linux or anything else.

Linux is only a kernel. It’s a kernel used by many different operating systems. Some of them radically different (like Android or Chrome OS). If you are a company and make a product supporting it on Linux is crazy. What should Joel do then?

He should support operating systems, not kernels. What operating systems should Joel support? I don’t know, whatever is popular. I’d guess Red Hat’s RHEL, Ubuntu, Debian are probably popular operating systems. Once you start supporting operating systems instead of kernels the world looks differently. You don’t have to deliver a tar.gz (a compressed archive) that should compile and run everywhere. It’s insane to ship that and it’s insane to expect users to be able to install them. I administer various Debian and Ubuntu servers and workstations. Do you know how often I compile source code that I haven’t written myself? Never!

When you support an operating system like Ubuntu or Debian you can ship binaries. You build binaries in the form of debs or rpms. And you don’t build only one of them, you probably need one deb for Ubuntu, one deb for Debian and maybe even one deb for each version of Ubuntu if they vary enough. If you think this is a lot of work, then look at how much work is building a Windows installer that can work in any Windows from XP pre-SP1 without .Net to Windows 7. If it was trivial there wouldn’t be companies like InstallShield making money.

I’ve heard FogBugz comes with its own copy of MySQL and Apache. How Windowish! That’s crazy and meant to break. You don’t copy code, programs or libraries in the world of Linux-based operating systems. You set dependencies. You make a fogbugz.deb that depends on Apache and depends on MySQL and when fogbugz.deb is installed it will automatically install Apache and MySQL. It will install an Apache built, optimized and customized for that version of Apache that follows the Ubuntu guidelines for storing caches, config files, etc.

There’s more, since there are some pretty straighfoward guidelines where everything is installed, fogbugz.deb could work out of the box. In an Ubuntu box I can run

aptitude install phpmyadmin

and it works out of the box. And phpMyAdmin depends on Apache and MySQL. Of course I could break those services so that nothing works, but most people don’t. What the phpmyadmin package does is drop files in certain locations where Apache is going to pick them up. Apache as many other programs don’t have just one configuration files but directories of them, so you can drop another configuration file and it’s picked up.

I am very certain that if FogBugz was packaged in this fashion, then it would not generate as many phone calls as it does now. It is packaged and distributed like software in 1995 for Linux-based operating systems, when almost everything was a mess and chaotic and there were very few people putting it in production.

To close this post let me tell you something else to convince you that Linux is not an operating system. You can write a program for Linux, but then it runs just fine in OpenBSD. And then you find out that it also runs just fine in Solaris. Well, but you wrote it on a Debian box, which is Linux. Did you know that there’s a Debian kFreeBSD (or something like that)? which is Debian running the FreeBSD kernel. Debian kFreeBSD is more similar to Debian than to FreeBSD. Nexenta is Ubuntu with the Solaris kernel, and it’s more similar to Ubuntu than to Solaris. Android is Linux, yet almost none of the software that runs on Debian, FreeBSD, Nexenta, Solaris runs on Android.

You see, Linux is just one component, and not even the biggest component, of an operating system. It is not the component users interact with when using a computer and it is not even the component programmers interact most of the time, when writing a program. It makes almost no sense to say “I make this program for Linux”.

Share:

Like this:

NetBeans could make the Ruby on Rails experience great for the vast majority of developers who are using Windows, where installing Ruby, Rails, PHP, MySQL, Python, etc is always a pain and the end result is ugly. But it falls short in some important ways which turned my experience with it into a nightmare.

The reason I say “for developers using Windows” is because I believe that for everybody else, the experience is great already. Or as good as it can be and NetBeans can be an excellent IDE, but not improve the installation and managing experience.

This is my story, my rant.

I downloaded the latest NetBeans and installed it. When creating my first Ruby project, I encountered the first problem. Ruby chocked on my username, which was “J. Pablo Fernández”. You could say it was my fault. Windows 7 asked for my name and I typed it. I wasn’t aware it was asking for my username. Even then I would have typed the same, because Windows 7 doesn’t distinguish between usernames and names, and in the 21st century, computers should be able to deal with any character anywhere.

I know it’s not NetBeans’ fault, it’s Ruby’s. But! Can you imagine a Software Engineer telling Steve Jobs “oh, copying files in a Mac behaves weirdly because it uses rsync and that’s its behavior, you see, it makes sense because…”? Of course Steve would have interrupted: “You’ve failed me for the last time”. The next developer would have patched rsync, trying to get the patch upstream, or creating an alternate rsync or stop using rsync.

I’ve spent many hours creating another user, migrating to it, which in Windows is like 100 times harder than it should.

Hours later, as soon as I created a project I got a message saying that I should upgrade gem, Ruby’s package manager, because the current version was incompatible with the current Rails version. By then I had already played with NetBeans’ gem interface telling it to upgrade everything, it should have upgraded gem as well, not just the gems. Every single developer out there running NetBeans must be encountering this error, and indeed there are quite a few threads about it on forums.

Trying to upgrade gem with NetBeans was impossible. I think what they did to install and upgrade gems in NetBeans is excellent, but failing to upgrade gem itself was a huge drawback. This one was NetBeans’ fault. Neverfear, let’s do it from the command line.

When doing it from the command line I encountered another error:

\NetBeans was unexpected at this time.

Looking around it seems it’s because of the spaces in “Program Files (x86)”. That means that the command line environment for Ruby that NetBeans installs is broken for everybody. I repeat: everybody. The answer: install it somewhere else.

Well, I have two things to say about it: first, fix the freaking thing, Ruby, gem, whatever. Paths can have spaces and all kind of weirdness. It’s a big world full of people speaking languages that can’t be represented with ASCII and people that believe computers should do our bidding, instead of the other way around. “If I want spaces you better give me spaces, useless lump of metal and silicon”.

Second, if you know one of your dependencies is broken, try to avoid triggering the broken behavior or at least warn the user about it. “We see you picked C:\Program Files (x86)\ to install NetBeans, which is pretty standard, but you know, Ruby is broken and can’t work in there, not even JRuby, so if you plan to use those at all, please consider installing it somewhere else.”

I uninstalled NetBeans, or tried to. The uninstaller didn’t work. I deleted it and tried to install it on C:\ProgramFilesx86, which failed because some other directory created by NetBeans somewhere else existed from the previous installation, which halted the installation. I started a dance of run installer, remove dir, run installer, remove dir, run installer… until it worked.

Once I finished I found out that NetBeans installed in C:\ProgramFilesx86\Netbeans 6.7.1. Yes, that’s a space. Oh my…

As a bonus, NetBeans can’t automatically find Sun’s JDK in its default directory. I had to point to it by hand. Sun was, as usually, absolutely disrespectful of the platform conventions and installed its crap in C:\Sun. I would have picked another place but I thought “I’m sure some stupid program will want to pick that shit from there”. Silly me.

12 hours have passed and I still haven’t been able to write a single line of source code. I contemplated installing Ruby by hand, but it’s so ugly that I decided I’m not going to use Windows for this. I’m going to work on another platform where installing Ruby is trivial and where I would probably never touch NetBeans because I have other editors.

I know there’s a lot not really related to NetBeans here, for example, the fact that working with Python, or Ruby or MySQL in Windows is a pain; but it’s a great opportunity for NetBeans. There are developers wanting to use those languages and environments and if NetBeans makes it easy for them, they will pick NetBeans not because of its editor, but because of everything else (which is what I was hoping to get out of NetBeans).

Aside from doing some usability tests, the people working on NetBeans should learn from the people working on Ubuntu (not the people working on Evolution) and instead of asking me for debugging traces when I report a simple obvious bug and then tell me it’s not their fault, they should submit those bugs upstream, to Ruby, gem, or whatever. Whenever someone like me submits that bug to NetBeans they should mark it as duplicate of an existing open bug that points to the upstream bug. I would have followed that link and told the Ruby developers “wake up!”. As it is, I didn’t. It’s too much work for me.