At least three times this year, I have found myself suggesting that perhaps it would be better to teach component-based software enginereing to young undergraduates using C# (via Mono, of course) as opposed to the more-restrictive Java. I feel a little like Nixon going to China when I say this...
Having said that, it's probably better to use Java for production code. But I almost think that you need flexibility to experiment at the educational level, and Java has no flexibility (because it is so tightly crafted for security, portability, and stability). C++ has a lot of flexibility, but no one wants students learning C++ anymore (a comment on that in a bit). C# (under Mono, of course) has more flexibility than Java but less than C++. It's relevant, as it is relatively easy to move from C# development to Java develpoment (and there are plenty of companies (or at lest one gigantic one) that are looking for C# developers too). It has preprocessor directives (even though it has no preprocessor), which gives it a customizable presentation for the classroom environment. So it feels like it would be easier to start with C# and then "graduate" to Java (and go to graduate school for Lisp? I dunno. And where does Python fit in? Maybe it takes the place of Logo in 4th grade).
Regarding the note above about no one wanting students to learn C++ anymore, it is interesting that software interviewers are typically of the age and rank where most of their experience is in C or C++. I was at an interview recently where the interviewer asked questions contrasting addressing individual bytes of a 4-byte unsigned integer using pointers or bitmasks; such a question does not belong in any discussion of Java. Moreover, I heard someone in a nearby cubicle on a phone interview being asked about static variables in C and C++ programs. The graduate student was more familiar with "static" in the context of Java, and so I think he worked htings out sufficiently well, but most students have never heard of this term (likewise, they don't even think to look up "persistent" in their MATLAB documentation). So it seems unfair that undergraduates are being switched over to Java... and will be asked about pointers in some of their first technical interviews. Oh well...
Personal weblog of Ted Pavlic. Includes lots of MATLAB and LaTeX (computer typesetting) tips along with commentary on all things engineering and some things not. An endless effort to keep it on the simplex.
Friday, March 11, 2011
CS Education: C# in Mono / Java
Labels:
.NET,
C#,
Computer Science and Engineering,
education,
Java,
jobs,
Mono,
opinion,
programing
Tuesday, March 08, 2011
Installing Adobe Digital Editions on Linux with Wine
UPDATE: I have not had time to address the download issues some people have had when trying to install ADE. However, see the comments on this post for some additional tips on where to find an ADE installer download that you can run inside Wine.Unfortunately, Adobe does not provide a simple download link for the Windows version of Digital Editions, and so if you want to purchase a PDF or ePub e-book with Adobe ADEPT DRM protection, it is very difficult to get up and running on Linux even if you have Wine installed. Here's how I did it.
- Install Wine on your system. Most Linux distributions provide Wine as an optional install (e.g., sudo yum install wine from the command line on Fedora).
- You will need Gecko extensions available to run the iexplore.exe web browser that comes with Wine. Visit the Wine Wiki's Gecko page for information on how to install Gecko. Your Linux distribution may have a "wine-gecko" package. If it doesn't, then follow the simple instructions on the Wine Wiki.
- You will also need Adobe Flash installed on your Wine system, and so you should visit the Wine Wiki's Flash page to get the install_flash_player.exe download link. Download the exe and run it in Wine (e.g., wine install_flash_player.exe from the command line).
- Now, start the iexplore.exe browser bundled with Wine. After I ran Wine for the first time, it setup a .wine directory in my home directory (i.e., ~/.wine). I found the iexplore.exe in ~/.wine/drive_c/Program Files/Internet Explorer. Change to that directory and run iexplore.exe (e.g, wine iexplore.exe from the command line).
- Now you can visit the Digital Editions installer (which is written in Flash). From the Wine Internet Explorer, enter in the URL:
That should startup a little installer. Follow the prompts to download and install Digital Editions. You will even be able to launch it from there.http://www.adobe.com/products/digitaleditions/ade_web_library.swf
- The installer will install the single Digital Editions executable to ~/.wine/drive_c/Program Files (x86)/Adobe/Adobe Digital Editions as digitaleditions.exe.
- You can run it again but executing that file through wine (e.g., wine digitaleditions.exe from the command line in that directory)
- Alternatively, you can use the "Digital Editions" shortcuts that the installer probably placed on your desktop.
- Once Digital Editions is started, you should be able to drag-and-drop ACSM files you've downloaded from e-Book commerce sites (like Google Books), and it should download the Adept-DRM'd version of your media.
- DRM'd books are stored in the My Digital Editions folder that will be created in your home directory.
- If you want to put them elsewhere, you need to edit the symbolic links in ~/.wine/drive_c/users/USERNAME where USERNAME is your Linux username. The My Documents folder was symlinked to my home directory by default. I got rid of the symlink and created a real directory there instead, but you could point the symlink somewhere else if you'd rather. Regardless, the My Digital Editions folder will reside inside the My Documents folder (alongside a My Books folder, but I don't know what gets put in there... maybe non-DRM stuff you put into ADE?).
Monday, March 07, 2011
MATLAB script to prove to you that the perfect squares are the switches that are toggled
Evidently, this problem exists in both "switch" and "locker" forms. Assume that there are 100 switches are initially off and numbered from 1 to 100.
Examining the problem, you notice that switches are toggled the same number of times as they have unique factors. For example, switch 6 is toggled 4 times, which corresponds to its unique factors, 1, 2, 3, and 6. However, switch 4 is toggled only 3 times, which corresponds to its unique factors, 1, 2, and 4 (i.e., even though 4 = 2 × 2, the factor 2 is only represented in the list once because it is duplicated). Moreover, it is only the perfect squares (1, 4, 9, 16, 25, 36, 49, 64, 81, 100) that will have repeated factors (i.e., their whole square roots), and so it is only those switches that will be flipped and odd number of times. Furthermore, it is only those switches that will be "on" after this game.
To verify this to yourself, use a MATLAB script:
Of course, you could also keep track of how many times you made a flip. XOR can help with this too.
- First, you toggle multiples of 1 (i.e., every switch gets turned on),
- and then you toggle multiples of 2 (i.e., every even-numbered switch gets turned off),
- and then you toggle multiples of 3 (i.e., switches 3, 6, 9, 12, ... are toggled),
- ...
- and then you toggle multiples of 99 (i.e., switch 99 is toggled),
- and then you toggle multiples of 100 (i.e., switch 100 is toggled).
Examining the problem, you notice that switches are toggled the same number of times as they have unique factors. For example, switch 6 is toggled 4 times, which corresponds to its unique factors, 1, 2, 3, and 6. However, switch 4 is toggled only 3 times, which corresponds to its unique factors, 1, 2, and 4 (i.e., even though 4 = 2 × 2, the factor 2 is only represented in the list once because it is duplicated). Moreover, it is only the perfect squares (1, 4, 9, 16, 25, 36, 49, 64, 81, 100) that will have repeated factors (i.e., their whole square roots), and so it is only those switches that will be flipped and odd number of times. Furthermore, it is only those switches that will be "on" after this game.
To verify this to yourself, use a MATLAB script:
Running the script results in:% All switches initially off switches = zeros(1,100); % Toggle multiples of the current switch, including the current switch for i = 1:100 % These are the switches to toggle ivec = i:i:100; % xor'ing them with 1's toggles them switches(ivec) = bitxor(switches(ivec), 1); end % Show the indexes of the switches that are "on" after this process % (expect perfect squares: 1 4 9 16 25 36 49 64 81 100) find( switches )
which is what we expected.ans = 1 4 9 16 25 36 49 64 81 100
Of course, you could also keep track of how many times you made a flip. XOR can help with this too.
Then, from the console, we can issue commands like:% All switches initially off switches = zeros(1,100); new_switches = zeros(1,100); num_flips = zeros(1,100); % Toggle multiples of the current switch, including the current switch % (gratuitous use of bitxor as a demo) for i = 1:100 % These are the switches to toggle ivec = i:i:100; % xor'ing them with 1's toggles them new_switches(ivec) = bitxor(switches(ivec), 1); % count the flips % ( num_flips(ivec) = num_flips(ivec)+1 works too) num_flips = num_flips + bitxor( new_switches, switches ); % commit new_switches to switches to maintain invariant % (can omit new_switches by not using second bitxor above) switches = new_switches; end % Show the indexes of the switches that are "on" after this process % (expect perfect squares: 1 4 9 16 25 36 49 64 81 100) find( switches )
So that's fun.num_flips( find(switches) ) % shows number of flips for switches ending "on" num_flips( find(switches==0) ) % shows number of flips for switches ending "off" find( mod(num_flips,2)==1 ) % verifies odd-count flips have perfect-square indexes
Labels:
code,
math,
mathematics,
MATLAB,
perfect square,
puzzle,
puzzles,
scripts,
xor
Sunday, March 06, 2011
Another rant on the supremacy of rolling release cycles for OS distributions (why Arch beats Fedora and Ubuntu)
As I sit here right now, I notice that my Arch Linux package manager ("pacman") is downloading KDE 4.6.1. KDE 4.6.0 was released at the end of January, and it was automatically installed on my system shortly after it was released. I don't notice a lot of new features, but there is one feature that I now use all the time. For a long time, dragging a KDE window to one of three edges of the screen would cause it to either be maximized (top) or resized to fill either the left half (left) or right half (right) of the screen for easy side-by-side tiling. This feature exists in Windows Vista, and I know a certain fiancée who uses it all the time. In KDE 4.6.0, they've added more granularity – the left and right edges of the screen are now partitioned into thirds. Dragging a window to the top or bottom third causes it be resized for a quarter of the screen as opposed to a half of the screen. The middle third resizes for half of the screen as before. So now it is easy to do even more sophisticated tiling by dragging, and I use it all the time.
But I can't use that feature on my machine at the office (Fedora 14) nor the HTPC connected to my TV (Ubuntu 10.10). That's because both Fedora and Ubuntu are on 6 month release cycles, and KDE is also on a 6 month release cycle. Consequently, my Fedora office machine is stuck back on some KDE 4.5.5 components, some 4.4.10 components, and some KDE 3.5.10 components, and it seems arbitrary which components are which KDE version. More importantly, it may be another year before I can ever expect to get quarter-window tiling on these machines (enterprise distributions, like RedHat EL, are even worse; you may wait a decade for features to trickle down the official release path). There are ways in which these distribution gatekeepers try to get around this delay by supporting auxiliary repositories of updated software, but then that is a whole other mess I would have to cover in another rant.
It's frustrating to me that these Linux "distributions" take on a release cycle that elevates them to a level on par with the software that supposedly is the sole driver of their value. It is one thing to wait for the next release of Windows to come out because Windows is a product itself; however, Ubuntu or Fedora is just a distribution – a glorified collection of independent software components that are possibly rapidly evolving and have some dependency structure on each other. Arch Linux recognizes this. It recognizes that a good package manager trumps a great "distribution" any time, and pacman is a great package manager (and it doesn't have a stupid name, like "yum" or "apt-verb", and isn't just a wrapper for yet another silly-named package manager (like "rpm" or "dpkg")). In doing so, it allows for everything from minimal Linux installations to maximally bloated Linux distributions, with the distinction that every package is truly up to date (and not just up to date relative to some arbitrary collection of version numbers). Arch Linux is not the only distribution with this nice feature. Gentoo, for example, also uses a rolling release cycle... and Gentoo is also well-known for its excellent package manager "emerge".
[ ...and on the subject of package managers, the pacman-wrapper yaourt augments the terrific pacman with the ability to automate building packages from source, even when you want to both customize your build environment and automatically build updates when they are available... so yaourt brings some of the nice features of Gentoo's rolling release cycle directly to Arch Linux's rolling release cycle ]
Frustration is certainly not the only feeling I can associate with the Fedora and Ubuntu distributions forced on me (by my employer in the former case and Boxee in the latter case); there's also fear. Every six months with Fedora or Ubuntu, you have to go through the horror of upgrading the entire distribution at once. I'd rather tackle upgrading problems with one package at a time as opposed to the entire OS twice a year. Not to mention the psychological trauma that upgrades cause – regardless of how nice the system works, I always have in the back of my head that maybe it would be better if I just formatted and installed fresh right now (but then the fear of the next upgrade prevents me from doing that). An operating system should not be a major cause of distress, but I find nothing but distress in Ubuntu, Fedora, and the other deleterious distributions in that pernicious pack that do not adopt rolling releases.
So there you go. I just quarter-window tiled this window, and it saddens me that when I go back into the office on Monday, I will lose half my day to half-window tiling and resizing... and then I'll lose a day or two later this year when FC15 comes out. Stupid six-month distribution release cycles...
But I can't use that feature on my machine at the office (Fedora 14) nor the HTPC connected to my TV (Ubuntu 10.10). That's because both Fedora and Ubuntu are on 6 month release cycles, and KDE is also on a 6 month release cycle. Consequently, my Fedora office machine is stuck back on some KDE 4.5.5 components, some 4.4.10 components, and some KDE 3.5.10 components, and it seems arbitrary which components are which KDE version. More importantly, it may be another year before I can ever expect to get quarter-window tiling on these machines (enterprise distributions, like RedHat EL, are even worse; you may wait a decade for features to trickle down the official release path). There are ways in which these distribution gatekeepers try to get around this delay by supporting auxiliary repositories of updated software, but then that is a whole other mess I would have to cover in another rant.
It's frustrating to me that these Linux "distributions" take on a release cycle that elevates them to a level on par with the software that supposedly is the sole driver of their value. It is one thing to wait for the next release of Windows to come out because Windows is a product itself; however, Ubuntu or Fedora is just a distribution – a glorified collection of independent software components that are possibly rapidly evolving and have some dependency structure on each other. Arch Linux recognizes this. It recognizes that a good package manager trumps a great "distribution" any time, and pacman is a great package manager (and it doesn't have a stupid name, like "yum" or "apt-verb", and isn't just a wrapper for yet another silly-named package manager (like "rpm" or "dpkg")). In doing so, it allows for everything from minimal Linux installations to maximally bloated Linux distributions, with the distinction that every package is truly up to date (and not just up to date relative to some arbitrary collection of version numbers). Arch Linux is not the only distribution with this nice feature. Gentoo, for example, also uses a rolling release cycle... and Gentoo is also well-known for its excellent package manager "emerge".
[ ...and on the subject of package managers, the pacman-wrapper yaourt augments the terrific pacman with the ability to automate building packages from source, even when you want to both customize your build environment and automatically build updates when they are available... so yaourt brings some of the nice features of Gentoo's rolling release cycle directly to Arch Linux's rolling release cycle ]
Frustration is certainly not the only feeling I can associate with the Fedora and Ubuntu distributions forced on me (by my employer in the former case and Boxee in the latter case); there's also fear. Every six months with Fedora or Ubuntu, you have to go through the horror of upgrading the entire distribution at once. I'd rather tackle upgrading problems with one package at a time as opposed to the entire OS twice a year. Not to mention the psychological trauma that upgrades cause – regardless of how nice the system works, I always have in the back of my head that maybe it would be better if I just formatted and installed fresh right now (but then the fear of the next upgrade prevents me from doing that). An operating system should not be a major cause of distress, but I find nothing but distress in Ubuntu, Fedora, and the other deleterious distributions in that pernicious pack that do not adopt rolling releases.
So there you go. I just quarter-window tiled this window, and it saddens me that when I go back into the office on Monday, I will lose half my day to half-window tiling and resizing... and then I'll lose a day or two later this year when FC15 comes out. Stupid six-month distribution release cycles...
Labels:
apt,
Arch Linux,
distributions,
dpkg,
emerge,
Fedora,
Fedora Core,
Gentoo,
Linux,
operating systems,
pacman,
rants,
RedHat,
RHEL,
rolling release,
rpm,
Ubuntu,
yaourt,
yum
Wednesday, March 02, 2011
These continuous enrollment policies remind you that schools are in the business of making money
This memo below was sent out to all department chairs, graduate studies chairs, and graduate program administrative support staff at OSU. I don't think it was intended to be read by students or anyone else, but it got forwarded to the student list, and they haven't taken me off of that list yet. For brevity, I'm omitting the PDF that was attached to the memo.
I have always thought these continuous enrollment policies (and limits on funding based on a credit hour ceiling) were slimy. It's even slimier when you read this memo which initially says it is in the benefit of the student to finish their doctorate quickly but then at the end says that it ensures the college is making money.
I have always thought these continuous enrollment policies (and limits on funding based on a credit hour ceiling) were slimy. It's even slimier when you read this memo which initially says it is in the benefit of the student to finish their doctorate quickly but then at the end says that it ensures the college is making money.
Patrick S. Osmer, Vice Provost and DeanCurrently, students get into their post-candidacy period as soon as possible and must keep 3-hour enrollment per quarter. Before that, students were urged to do their candidacy a year before defending their dissertation (so the candidacy started the "writing year"). In general, students were asked to maintain 15-hour enrollment (because it was good for individual department budgets). But then the state got involved and started to crank down on the maximum number of hours a doctoral student could accumulate... and things went down hill from there. So now we have early candidacies and lots of mandatory 3-hour enrollment. By the way, if you didn't get the hint, students don't actually take any classes during these 3- or 15-hour enrollment periods; they take (and someone pays for) "research hours". "Research hours" are usually not given letter grades (although some universities give them letter grades, which helps graduate students to buffer their GPA's against some classes that they actually do have to take), and they rarely require any deliverables to pass them. They are throw away classes invented by bean counters.
February 28, 2011
TO:
Department Chairs
Graduate Studies Committee Chairs
Graduate Program Administrative Support Staff
Colleagues:
I am writing to remind you of the Continuous Enrollment Policy that is in effect for all students who were admitted to the Graduate School autumn quarter 2008 and after. We are receiving petitions for exemption from the policy, which we need to have approved by the college before we can consider them, as I explain below.
Simply put, this policy requires all post-candidacy students to be enrolled for a minimum of three credit hours every quarter (excluding summer quarter) until graduation. I am including a copy of the policy for your convenience. Recall that the policy is an outcome of the process that led to the reduction of full-time enrollment for post-candidacy students to three credit hours. One specific goal of continuous enrollment is to reduce time to degree for doctoral students by having them formally engaged with their program and the university. Going away to teach somewhere else with the intent to finish the dissertation off campus, for example, is not in the student’s best interests or the university’s.
A student may apply for a leave of absence due to extenuating circumstances such as the birth or adoption of a child or a serious medical condition, but a leave will not be granted with the sole reason of financial hardship.
If a student is requesting an exemption from continuous enrollment due to circumstances not covered by the leave of absence as stated in the Graduate School Handbook, I am asking that he or she direct that petition to the dean’s office for your review. The college may choose to cover the cost of the post-candidacy enrollment for an individual student and we will work with the college to manage that process. I remind you that according to the current budget model, the net marginal revenue to the college will be positive for a student who enrolls for three hours and for whom the college covers the (standard) fee authorization.
We continue to communicate this policy to students and to graduate programs and appreciate your assistance with that process. Please let me know if you have further questions.
Sincerely,
Pat
250 University Hall
230 N. Oval Mall
Columbus, OH 43210-1366
PH:(614) 247-7413
FAX:(614) 292-3656
Subscribe to:
Posts (Atom)