- Athens, Day One: https://photos.app.goo.gl/YjktFwVCySib7YI43
- Diakofto and Kalavryta, Greece day two: https://photos.app.goo.gl/VaSUUsK0QXYtmhFk1
- Athens Day 3, Archaeology Museum and Filopappou Hill: https://photos.app.goo.gl/S8JFW2XAwUkjx3G53
- Greece Day 4, Cape Sounion and the Acropolis Museum: https://photos.app.goo.gl/MXtSyJAZOjW2rTAg1
- Greece Day 5, Delphi: https://photos.app.goo.gl/TZrNQwLjavX0jmLI2
- Greece Day 6: the Peloponnese: https://photos.app.goo.gl/er24cvrbdGEcaAl12
- Greece Day 7: The Saronic Gulf: https://photos.app.goo.gl/CqGZAaHVBcDrKQkv2
Martes-Martes
Computing, Networks, Privacy
Friday, March 2, 2018
Our Trip to Greece, January 2011
Monday, February 26, 2018
Java's Stack Class and Queue Interface
Neither java.util.Queue nor java.util.Stack enforce queue or stack disciplines. As such they are unsuitable for teaching queues and stacks, and unsuitable for use in software engineering.
If I have a Stack that is shared among various modules, perhaps maintained by various people, I want to know that no one is accessing it beyond push and pop at the top. Otherwise, there is no way to have any confidence that any contract or class invariants are being maintained.
I have no issue with Stack methods empty(), peek(), pop(), or push(). My objection to search is minor: this isn't part of the idea of the stack, so it should not be in the public interface.
But Stack also inherits a number of methods from java.util.Vector, including removeElementAt() and insertElementAt(). This is not a stack. It can be used as a stack, but the programmer has no assurance that other pieces of code are treating it as a stack.
The Queue interface is not as bad. The interface's six methods make it look like the committees that added to it over time were a bit confused or at least not in agreement with one another, but, nonetheless, insertion is always at the tail, and removal is always at the head.
But Queue extends java.util.Collection, which adds a number of non-queue-like methods. Many of these methods allow treating a queue like a stream, which is more convenient than removing item-by-item, deciding if each item fits some criteria, and then adding those meeting the criteria back into a queue.
My main issue with java.util.Queue is shared with java.util.Stack: the is-a relation does not work. A subclass of either could satisfy the Liskov substitution principle, but the child would be neither stack nor queue.
One fix would be to define more reasonable Stack and Queue classes, and declare them final. What I really want is a way to declare an interface that restricts the addition of methods.
If I have a Stack that is shared among various modules, perhaps maintained by various people, I want to know that no one is accessing it beyond push and pop at the top. Otherwise, there is no way to have any confidence that any contract or class invariants are being maintained.
I have no issue with Stack methods empty(), peek(), pop(), or push(). My objection to search is minor: this isn't part of the idea of the stack, so it should not be in the public interface.
But Stack also inherits a number of methods from java.util.Vector, including removeElementAt() and insertElementAt(). This is not a stack. It can be used as a stack, but the programmer has no assurance that other pieces of code are treating it as a stack.
The Queue interface is not as bad. The interface's six methods make it look like the committees that added to it over time were a bit confused or at least not in agreement with one another, but, nonetheless, insertion is always at the tail, and removal is always at the head.
But Queue extends java.util.Collection, which adds a number of non-queue-like methods. Many of these methods allow treating a queue like a stream, which is more convenient than removing item-by-item, deciding if each item fits some criteria, and then adding those meeting the criteria back into a queue.
My main issue with java.util.Queue is shared with java.util.Stack: the is-a relation does not work. A subclass of either could satisfy the Liskov substitution principle, but the child would be neither stack nor queue.
One fix would be to define more reasonable Stack and Queue classes, and declare them final. What I really want is a way to declare an interface that restricts the addition of methods.
Thursday, February 1, 2018
Firefox Minimum Print Font Size
I've
been frustrated with font sizes when I print documents and playing
games with zoom level, etc. But it turns out Firefox has a good, general
solution: no more playing around.
Firefox allows one to set minimum print font size. In limited testing, it works well, as it
should, since the browser should be able to re-flow text for changing
font sizes. Other browsers probably have some similar mechanism, but
this is for Firefox:
Preferences | Content | Fonts&Colors | Advanced | Minimum Font Size
I set mine to 11. It does sometimes use more paper, but several times I've seen a printout, and tossed it directly into recycling and tried again.
Sunday, June 18, 2017
Futility of Tweeting on Politics
People who know me or follow me on twitter know that I am unhappy with Trump's performance as president, and reluctantly voted for Hillary Clinton in the fall though I viewed her as too conservative herself. I've tweeted often on this.
Recently I've decided that retweeting NY Times and Washington Post articles and editorials and the like does little good: it's mostly a contest to see who can shout the loudest, though I found some interesting reading based on other peoples' tweets and can hope others read some of the articles I tweeted about and found them interesting or useful.
But, if my political tweeting has done no good, then maybe actually attempting constructive engagement with pro-Trump folks might be more constructive. In one of those threads, I asked for the source of an implausible quote attributed to George Soros. I got a series of increasingly more disappointing responses:
Recently I've decided that retweeting NY Times and Washington Post articles and editorials and the like does little good: it's mostly a contest to see who can shout the loudest, though I found some interesting reading based on other peoples' tweets and can hope others read some of the articles I tweeted about and found them interesting or useful.
But, if my political tweeting has done no good, then maybe actually attempting constructive engagement with pro-Trump folks might be more constructive. In one of those threads, I asked for the source of an implausible quote attributed to George Soros. I got a series of increasingly more disappointing responses:
- It doesn't matter if Soros really said that; he's a bad person, so it's okay to attribute things like that to him.
- So, I asked if it's okay to make stuff up (I may have used the word lie) about a person just because you don't like his politics. Then the person said that Soros really did say these things, just Google it. I did Google it, and Google led to pages attributing the quote to Soros, but none of the websites were an established (read: credible) news source.
- I decided not to continue in the thread, though others persisted, and in a non-sequitor the discussion turned to President Obama, but by the name Negrobama. I blocked a few people in the thread so I wouldn't have to read this ignorant and racist tripe in my notifications. In the past I've rarely blocked accounts.
- So I wanted constructive dialog, and just now ended up (above, not in the Twitter thread) describing people on the other side as ignorant and racist. This is not a productive way to build dialog.
I have not found politics on Twitter to be a constructive use of my time, though often entertaining. For functional programming, mathematics, networking, teaching CS, and the like, twitter still seems fine, though many people, like me, tweet on one or more of those topics and on Trump's kleptocracy. To help me reduce the temptation to tweet on politics, I guess I will unfollow people who tweet largely about politics. It's not that I disagree with them, but that I don't think it's useful on the whole.
Labels:
futility,
kleptocracy,
New York Times,
Politics,
Trump,
Twitter,
Washington Post
Saturday, September 17, 2016
Saturday, March 26, 2016
Trying to be a Mac User--Decision to Give Up
In November I went all-in on switching from Linux to the Mac. Linux quality is ever-declining, and I had a laptop on which Linux Mint was almost completely unusable. But Mac usability is surprisingly poor, and I expect to return to Linux, mostly completely.
This is the first of a series of short articles on Mac usability deficiencies. From Wikipedia, https://en.wikipedia.org/wiki/Point_and_click#Fitts.27s_Law:
------------------------------------------
where:
This is the first of a series of short articles on Mac usability deficiencies. From Wikipedia, https://en.wikipedia.org/wiki/Point_and_click#Fitts.27s_Law:
------------------------------------------
Fitts's Law
Fitts's law can be used to quantify the time required to perform a point-and-click action.
is the average time taken to complete the movement.
represents the start/stop time of the device and
stands for the inherent speed of the device. These constants can be determined experimentally by fitting a straight line to measured data.
is the distance from the starting point to the center of the target.
is the width of the target measured along the axis of motion.
can also be thought of as the allowed error tolerance in the final position, since the final point of the motion must fall within
of the target's centre.
------------------------------------------
Why is this important? Regardless of where a window is on the screen, OS X places the menu in the far upper left. Mousing to the menu is more time-consuming than if the menu were attached to the window itself, putting OS X at a disadvantage compared to other popular desktop operating systems, especially those with large screens.
Labels:
Fitts's Law,
Linux,
Linux Mint,
Mac,
OS X,
usability,
UX
Thursday, April 30, 2015
Considering a Chromebook? Get Something Better
This is a draft in progress.
The old Samsung netbook I'd been using for delivering lectures recently died, and I replaced it with an Asus C200 Chromebook with 4 GB RAM and 32 GB flash. For a week or two, I thought I just had to acclimate. Since then, I've known it was simply a mistake.
The C200 itself is a nice piece of hardware. Chrome OS is a bad idea poorly-implemented.
What I like:
The old Samsung netbook I'd been using for delivering lectures recently died, and I replaced it with an Asus C200 Chromebook with 4 GB RAM and 32 GB flash. For a week or two, I thought I just had to acclimate. Since then, I've known it was simply a mistake.
The C200 itself is a nice piece of hardware. Chrome OS is a bad idea poorly-implemented.
What I like:
- Long battery life.
What I dislike:
- Storage management is inflexible. I wanted to store a bunch of documents on my machine prior to a long meeting in a room with questionable Wi-Fi. Chrome OS does not support storing files locally in anything resembling a modern file system. Flash is treated as a cache, and does not preserve directory structure.
- In said meeting, I discovered that I was unable to open a number of DOCX files and any RTF files. Some DOCX files opened fine. So, in the middle of the meeting, Chrome was suggesting that I install extensions. Seriously?
- No Java SDK, so I cannot run simple programs from the command line. I need to ssh to a remote server and run them there. This is an extra time step I'd rather not take at the beginning of class each day. And it presupposes network connectivity.
- The provided command line has none of the standard Unix network tools, making another class of examples I often give in class awkward at best.
- There is no good PDF viewer. I want to go full screen and advance a page at a time. Is this so hard or unusual?
- There is no way to modify the screen timeout. Sometimes in the middle of a lecture, the machine will go to sleep. Then, unless one is quick, it may be necessary to log back in to the machine. In the middle of a lecture. There is an app, Keep Awake, that can keep the screen on, but one has to remember to enable it at the beginning of a lecture and disable it at the end. Forgetting to disable Keep Awake can result in a very low battery the next day. Can't they automate this?
- Google loves light characters on gray backgrounds. Very often from an angle or at a short distance, items on the screen are much less readable than they could be.
- No Haskell or Scala, meaning the Chromebook is useless for simple software development. Somehow when I heard it was based on Linux, I didn't investigate further--I was in a hurry.
- The charger runs very hot. This is an Asus C200 issue, though, and not specific to Chrome OS.
My path from here (probably after exams end and post-LamdaConf 2015):
- Blow Chrome OS away and install Linux.
- Problem: if I'd bought a cheap laptop, I'd have a hard drive much bigger than 32 GB to work with.
Labels:
asus,
Asus C200,
Chrome OS,
Chromebook,
Keep Awake,
UX
Saturday, October 4, 2014
December 2013 Trip to Nicaragua
Went to Nicaragua with friends last December. Here are links to the various (incomplete) photo albums. One more will be added soon.
- Nicaragua Day 1: BWI and León's Parque Central
- Nicaragua Day 2: León
- Nicaragua, Day 3, León, León Viejo, and Las Peñitas
- Nicaragua Day 4, Granada & Baseball
- Nicaragua Day 5: Lago Nicaragua
- Nicaragua Day 5: Parque Nacional Volcan Masaya
- Nicaragua Day 5: Apoyo Lagoon and Evening in Granada
- Nicaragua Day 6, Granada and Butterfly Preserve
- Nicaragua Day 7, Convent San Francisco and Granada Waterfront
- Nicaragua, Day 8, Managua
Tuesday, July 8, 2014
HTTPS Everywhere Rule Sets for UMBC, tools.ietf.org
The server tools.ietf.org supports TLS, but my browser's HTTPS Everywhere seems unaware of this fact. So I wrote a rule set for that server. I have previously posted here an HTTPS Everywhere rule set for an oft-used (by me) server at UMBC; for convenience, this is reproduced below.
<ruleset name="tools-ietf">
<target host="tools.ietf.org" />
<rule from="^http://tools\.ietf\.org/" to="https://tools.ietf.org/" />
</ruleset>
<ruleset name="tools-ietf">
<target host="tools.ietf.org" />
<rule from="^http://tools\.ietf\.org/" to="https://tools.ietf.org/" />
</ruleset>
<ruleset name="userpages-UMBC">
<target host="userpages.umbc.edu" />
<rule from="^http://userpages\.umbc\.edu/" to="https://userpages.umbc.edu/"/>
</ruleset>
Where do these rules go? See the EFF docs or my prior description.
Sunday, May 18, 2014
Geek Clock: They can do Better
- tan π/4 would be cleaner.
- round(∏) is fine, but how about ⌊π⌋ instead?
- Log 55 is ambiguous, misleading, and inexact--and who capitalizes a log function? Most people will assume the base is 10, except computer scientists might first think 2. But clearly this is intended to be natural log. So, why not say what you mean? ln 55. For precision, this could be wrapped in a floor function. So, my suggestion: ⌊ln 55⌋
- 16/2 is boring. How about 23 instead?
- Similarly, 3x3 would be better-written 32.
- g? Do they mean 9.8 m/s/s? How about 128?
- For 11, is that 0b? 06? Make it clear: 0xb or b_16. Add a leading zero if you want--I don't care.
- 11002 is fine for 12.
Labels:
time
Monday, February 17, 2014
Java's java.util.Date Class
Teaching Java programming to novices forces me to sometimes revisit the basics in my own understanding, or the edges of what I understand.
java.util.Date has come up a couple times this semester, and I thought I would verify the behavior of Date for dates at and before 1970-01-01. Here's my simple test code:
//Time-stamp: <2014-02-17 11:14:34 jdm>
import java.util.Date;
public class TimeZero {
public static void main(String[] args) {
final int yearsAgo = Integer.parseInt(args[0]);
final double msAgo = yearsAgo
* 365.25 // days per year
* 24 // hours per day
* 60 // minutes per hour
* 60 // seconds per minute
* 1000; // ms per second
final Date d = new Date((long) -msAgo);
System.out.println(d);
} // main()
} // class TimeZero
I'm neglecting leap seconds in my calculation of ms before 1970-01-01 (called msAgo). Assuming that a year averages 365.25 days is also not quite right, but since 2000 was one of those leap years divisible by 400, it's pretty close for recent years. Providing zero as input acts as expected (once one takes the time zone difference between here and Greenwich into account):
> java TimeZero 0
Wed Dec 31 19:00:00 EST 1969
Three years earlier seems to be about right, given that 1968 was a leap year:
> java TimeZero 3
Sun Jan 01 01:00:00 EST 1967
1000 years before 1970 looks good:
> java TimeZero 1000
Sat Dec 18 19:00:00 EST 969
Let's look around near the beginning of CE and the end of BCE (boundary conditions):
> java TimeZero 1967
Tue Dec 19 01:00:00 EST 2
> java TimeZero 1968
Sun Dec 18 19:00:00 EST 1
> java TimeZero 1969
Sat Dec 18 13:00:00 EST 1
This seems odd, but the Gregorian calendar does not have a year zero (see https://en.wikipedia.org/wiki/Gregorian_calendar) and Date.toString() does not include CE/BCE indication. I played around with calendars in my locale to get the era, but cal.get(Calendar.ERA) returns an int, which makes no sense whatsoever, and the problem isn't interesting enough to spend more time on.
However, I am willing to say the Java Date and Calendar hierarchies are entirely too complicated for day-to-day uses. This is one of the few places where I endorse using non-standard class libraries.
Sunday, September 8, 2013
Common Fate of Android Tablets, or a Quick 2013 Nexus 7 Review
I'm on my third Android tablet. Or fourth, but who's counting?
My first tablet was a Samsung Galaxy 5 bought in September 2012. This was mis-marketed as an MP3 player, which it did fine, but 5" was a great size for a handheld GPS device walking through cities, and fit easily into most pockets. It included an FM receiver, rear and front facing cameras, etc. I liked it. The big drawbacks were that it was too small for most reading or surfing activities, and it didn't have enough RAM to upgrade past Android 2.3.5. In December I managed to find the one place on Charles Ave where there was a drop-off between the sidewalk and the adjacent turf, stepped wrong, and fell, landing on my shoulder and on the Galaxy that had slipped out of my chest pocket. No Gorilla glass on this one.
I replaced it with a Nexus 10, decided that was too big, and replaced that immediately with a 2012 Nexus 7.
The Nexus 7 was overall fine, but the sound quality of the built-in speakers was terrible and produced insufficient volume to listen to podcasts or streaming radio from just a few feet away or with any background noise. The UI was sluggish. Touch a search area, and wait a few seconds before the keyboard appears. Type a key, and wait a few seconds before the character appears on the screen. No built-in FM receiver, but with TuneIn, this is not usually a big deal. Other than the speakers, the largest deficiency was the lack of a rear-facing camera. Got QR Droid? You won't be using it on this thing. I also found 16 GB to be slightly restrictive, but of course there is AndFTP's sftp feature, and my home desktop runs an sftp server, so moving stuff back-and-forth was a breeze--a great improvement over plugging in the USB cable and hoping Linux decides to recognize the device. Anyhow, I get around 20Mb/s between my Nexus and desktop via 802.11 (and an Ethernet hop). The one time I had two droids downloading from the server concurrently I got 30Mb/s measured at the server. Not bad.
I liked the size of the Nexus 7: fairly easy to hand-carry, and I picked up a small messenger bag that can carry that and a few other things while I wander about listening to podcasts.
Friday I dropped my Nexus 7. Even though it was in a decent M-Edge cover, the screen cracked, and much of the screen no longer behaves as a touch screen. No Gorilla glass on this one, either.
So I picked up a 2013 Nexus 7. I have not had it long, but my initial impression is that Asus did a great job. The sound quality is okay, but importantly it can kick out enough volume to be easily heard from several feet away. The UI is more responsive than the older Nexus 7. The rear-facing camera is a great addition. 32 GB of flash memory is a big improvement over my past 16 GB--I won't have to juggle among movies on the device.
I'll probably write more about the 2013 Nexus 7 later.
Aside: the guy from the Office Depot (la oficina de la marihuana) really, really wanted to sell me a protection plan for the Nexus. He went so far as to tell me I'd probably want to replace the battery in a year or so. Despite my tendency to break things, I never buy protection plans, as they are usually pure profit for the seller.
Sunday, August 25, 2013
Slightly Interesting Javascript Benchmark
I have an Asus CG5275 desktop, and decided to try out the Mandelbrot JavaScript benchmark at http://alexey.radul.name/ideas/2013/cleverness-of-compilers/ with the three browsers I use most, Chrome 29.0.1547.57, Firefox 23.0, and Opera 12.16. I expected Opera to be the slowest, and was not disappointed.
The mild surprise was that Firefox was almost four times as fast as Chrome. Here are my timings on the Asus with the above-mentioned URL and browsers:
Browser Size Time Relative
Chrome 29.0.1547.57 500x500 9562 ms 3.86
Firefox 23.0 500x500 2478 ms 1
Opera 12.16 500x500 19464 ms 7.85
Opera took just about twice as long as Chrome, and Firefox was almost 4 times as fast as Chrome. This is on an Intel i5 at 3.2 GHz running Linux Mint 15, Mate, kernel 3.8.0-29-generic. It's a 4-core machine, which makes me curious about the almost 4x speedup of Firefox vs.. Chrome.
[ Note added about 15 minutes after original posting: Mate's System Monitor makes it appear that all three versions use just a single core. No real surprise--this is JavaScript, after all. ]
[ Note added about 15 minutes after original posting: Mate's System Monitor makes it appear that all three versions use just a single core. No real surprise--this is JavaScript, after all. ]
Labels:
Chrome,
Firefox,
JavaScript,
opera
Tuesday, July 23, 2013
Scrollbars a page at a time, not a huge jump at a time
I've been really annoyed by Rhythmbox scrollbar behavior of late: when I click in the "trough" of the scrollbar, instead of moving the view by about a page up or down, it moves a distance corresponding to the point in the trough clicked. This is pretty bad for large text areas, such as a large music library. I complained to the Rhythmbox folks and Jonathan Matthew replied that this is default gtk behavior. This struck me as odd since I haven't noticed it in other applications, however Jonathan was right.
Google led me to a Gentoo site where ebichu was having the same issue, and posted the solution. I can't thank him there since I don't have a gentoo.org password, but he or she deserves thanks. The fix is to add a line to /etc/gtk-3.0/settings.ini:
[Settings]
gtk-primary-button-warps-slider = false
So they apparently call this slider warping. Very user-hostile.
Labels:
disable slider warping,
gtk,
rhythmbox,
usability
Sunday, July 21, 2013
Mindspring's 14 Deadly Sins
Worth keeping in mind and adapting for just about any business. From Wikipedia, http://en.wikipedia.org/wiki/MindSpring and credited to Mike McQuarry:
THE 14 DEADLY SINS OF MINDSPRING (or ways that we can be just like everybody else)
- Give lousy service--busy signals, disconnects, downtime, and ring no answers.
- Rely on outside vendors who let us down.
- Make internal procedures easy on us, even if it means negatively affecting or inconveniencing the customer.
- Joke about how dumb the customers are.
- Finger point at how other departments are not doing their jobs.
- Customers can't get immediate "live" help from sales or support.
- Poor coordination across departments.
- Show up at a demo, sales call, trade show, or meeting unprepared.
- Ignore the competition; they are far inferior to us.
- Miss deadlines that we commit to internally and externally.
- Make recruiting, hiring, and training a lower priority because we are too busy doing other tasks.
- Look for the next job assignment, instead of focusing on the current one.
- Office gossip, rumors, and politics.
- Rely on dissatisfied customers to be your service monitors.
I took the liberty of correcting the grammar in two places: 'jobs' in 5 was singular, and 9 contained a comma splice. Also, Wikipedia used a hyphen rather than a dash in 1; since it's unclear if this was Wikipedia's error or Mindspring's, I did not correct the Wikipedia page.
Subscribe to:
Posts (Atom)