Pool coping project underway

Today I officially got the pool project underway, after 6 weeks or so of procrastination. After a week of foul weather, I finally got a decent day, so I took off work and rented the concrete saw. It did the job quite nicely, and quickly enough that I only needed a 4-hour rental.

It took a bit of time to get the hang of the saw, but it was very easy to use. The blade had no problem cutting through the entire slab. The water feed did a great job of keeping the dust to a minimum, and it probably sped the job up by keeping the blade cool. I was not able to cut any of the curved areas, which I sorta expected. Not sure how I would handle these. A 7″ angle grinder might work for the area around the steps, but the corners are a little too tight for any kind of rotary blade.

Next I need to clear the joint and clean up the mess, which figures to be more time consuming than the cutting. The wet concrete dust forms a kind of pasty mud, which sticks to the deck and won’t fully vacuum up. I’ll probably end up using my pressure washer to clean it off the deck.

With the joint partially cleared, I can see that a lot of the fill around the pool has eroded over the years, from water seeping into the joint. I’m not planning on doing anything about it, as I’d need to demolish the deck (that’s a job for the next owner of the house). But, once I caulk the joint it’ll stop any further erosion.

Once I’ve cleaned the joint I may go ahead and fill it (at least partially) with backer rod, to keep junk from falling into it before it’s caulked. Hopefully I’ll be able to finish prepping the joint over the long weekend; then I can focus on re-mortaring the loose coping stones.

Oh, and the stupid Tulip Poplars have already started dropping leaves, and it’s not even July yet. It’s going to be a long summer..

The paradox of pool solar covers

We have a solar cover for our pool. It’s essentially a big, plastic sheet of bubble-wrap that sits on the pool surface. To remove it, we crank it onto a big reel — it’s pretty much a necessity to have a reel for these things, particularly with a large pool like ours.

After 5 seasons of dealing with solar covers, I’ve learned quite a bit about them. Contrary to what one might initially think, they don’t increase heating during the day when the pool is exposed to sun. In fact, they actually reduce daytime heating by blocking sunlight. There’s a bit of a greenhouse effect that heats the top foot or so of water, but the rest of the water sees less sun so doesn’t heat up as much. One desirable side effect of this is that it reduces chlorine usage during the day. So.. if you’re going on vacation and want to cut down on chlorine demand, put the cover on.

The biggest benefit of a solar cover is that it reduces heat loss and evaporation at night. So for the warmest water, you want to cover the pool in the evening and uncover it during the day.


The drawbacks of solar covers are subtle and a bit paradoxical (hence the title of this post). The biggie: You’d think that using a solar blanket to cover a pool would keep the pool cleaner, but it doesn’t. In fact, you could argue that it actually makes the pool dirtier. It’s true that when the pool is covered, stuff will fall on the cover instead of into the water. And sure, you can even use a leaf rake to clear the larger debris off the cover before you remove the cover. But when it rains, the dirty and untreated rainwater will collect around the folds and creases of the cover, and then when you remove the cover, the dirty water (along with whatever debris is still there) all falls into the pool and fouls the clean water. Then, because most of the debris is already waterlogged, it immediately sinks down to the bottom of the pool. Contrast this to when the pool is uncovered: the skimmers collect all the debris before it sinks, and the rainwater immediately mixes with the treated water rather than puddling up on the cover.

Solar covers (like any cover) also encourage neglect of the pool. When the pool is covered, I find myself more likely to skip chores like adding chemicals, brushing, emptying skimmer baskets, running the automatic cleaner, etc. When you combine this with rain and extra organic debris, it can lead to an algae bloom pretty quickly.

Conclusions: Unlike conventional covers, these things really are not meant to keep stuff out of the pool. Use them only for their thermal properties (chilly nights etc), and keep them off during the day and in particular, when it rains. If you must use the cover when it’s raining to conserve heat, uncover the pool as soon as possible after the rain stops.

I’ve often thought about getting a leaf net cover to keep out debris. I think it would complement the solar cover nicely, and in certain instances the two could be used at the same time. I hesitate because I’m not sure how much trouble it would be to put on and take off, and how I would anchor it down to keep it from blowing away, falling in the pool, etc. When you think about it, another tradeoff with covers in general is that they are an impediment to getting in the pool. It’s much easier to go swimming when the pool is uncovered and ready to go. No one wants to spend time fumbling with a big, unwieldy cover beforehand. Still, in the late summer and early fall, when we’re swimming less frequently anyhow, the leaf net may be worth the hassle.

Revisiting legacy myUMBC session management

Now that we’ve entered the brave new world of SSN remediation, it’s time to think about taking another step with myUMBC: We should stop using HP-ID as the primary key for legacy session management, and use UMBC Campus ID instead. Here’s why…

All of our web proxy channels which use the old portal as a back end, rely on the legacy code for session management and authentication. These channels, by design, often contain content above and beyond stuff that involves SIS. However, they rely on the SIS database, and the presence of an HP-ID, to work. Only a subset of people at UMBC have HP-IDs (at last count, there were 280,645 people in our directory, of which 274,244 had HP-IDs). People without HP-IDs have issues rendering these channels and taking full advantage of the portal. To get around this, I generate “bogus” HP-IDs for these folks to use as a primary key in the session management table. That makes things “sort of” work for them, but there are still problems — for one, the link ACL stuff in the legacy portal doesn’t fully work because it does LDAP queries against the HP-ID.

How do we address this? Well, the ultimate answer is to stop using HP-IDs as the primary key, and switch to campus IDs. On the surface, this seems easy. However, it’s actually a huge can of worms, because of sloppy development in the past. Rather than doing any code-sharing back then, our developers all wrote (or cut-and-pasted) their own code to manipulate the session table. As a result, we have 5,000 (slight exaggeration) apps that will each need to be updated to the new scheme. We’re paying now for cutting corners then.

I guess I should look at this as an opportunity to clean up some of this old code and get all the apps using a single library. But, that takes time, which means that this won’t be happening right away. In the meantime, I guess we’ll continue to limp along and deal with the no-HP-ID users as best we can.

Oracle SQL Developer

I’ve just discovered Oracle SQL Developer, and it looks like it’s going to really make my life easier. I’ve been using an old, crusty version of SQL Navigator for my SQL visualization needs, and it’s always worked, but I’ve never been crazy about it. For one, the UI is very klunky — the mouse wheel doesn’t work, and it doesn’t auto-scroll when I expand collapsible lists. So I end up doing a lot of click-and-drag scrolling, which is annoying (keep in mind this is a really old version of the software; hopefully these issues have been resolved in more recent releases). And, the software is Windows-only, so I have to remote desktop into my Windows box to run it. This gives it a cramped feel, because the remote desktop has a lower resolution than my main display, and I can’t resize it to be as big as I want. And last but not least, our firewall requires me to run it over a VPN connection, and the VPN kicks me off after 12 hours, fubaring my connections and requiring me to restart it daily. Extremely annoying.

Enter SQL Developer. It looks promising. It runs on Windows, Linux and Mac. The GUI is much slicker than the version of SQL Navigator I was running. At the same time, Rob gave me the tip to run it over an SSH tunnel to a machine on the DB server’s trusted network, which means I can bypass the VPN. Wins on all counts.

Installation was straightforward, after I figured out how to point it at the correct JDK. It requires Sun’s JDK1.5, but it initially was ignoring my JAVA_HOME environment variable and using an older version. I poked around the initialization script and found that it was using the directory search path to find the JVM. I added the JDK1.5 bin directory as the first thing in my search path, and then it worked. Then I set up the SSH tunnel:

ssh trusted-host.umbc.edu -L 1522:oracle.server.umbc.edu:1522

After that, I was up and running. It looks great. Stay tuned for further impressions.

myUMBC redesign coming along

What’s this… a rare work-related entry on a weekend??

Well, it is the weekend, but I’m hacking on the portal anyhow, to get ready for our relaunch this August. It’s coming along marvelously, thanks mainly to Collier, but I’ve been busy with it too. The relaunch will include:

  • A complete redesign of the front end (users will think we did something 😉
  • Framework upgrade from uPortal 2.4.3 to uPortal 2.5.2
  • Switch layout managers from Aggregated Layouts (ALM) to Distributed Layout Manager (DLM)
  • A flexible development environment (built around CVS) that accommodates multiple developers and makes it easy to deploy from scratch

It’s an ambitious undertaking given the time frame, but it’s really coming together amazingly well. The new portal instance is up and running on our test server. Today, I got our “Local Connection Context,” (which provides connectivity to the legacy myUMBC perl codebase via web proxy channels) working. There were a couple “gotchas” with doing this. First off, I made the executive decision to point the test-instance web proxy channels at the production SIS data. Yeah, we do have a development SIS instance, but it’s a little too rough-around-the-edges to use for this purpose. For example, there’s no (reliable) FastCGI version running, and using the standard CGI stuff would absolutely kill the performance. And, we’re not really concerned with testing the SIS stuff on the test portal instance — we’re really more concerned with ensuring that the SIS stuff renders properly. To that end, it makes more sense to point to the stable, production SIS code, to get the closest approximation to what would be running in prod anyhow.

Doing this raises a problem, though — the portal is connected to the DEVL Oracle instance, but to render production content, I also need a connection to the PROD instance. In production, I only need one database connection; in devl/test, I’m going to need two. I handled this by adding an additional JNDI data source for the prod database, and adding code to the connection context to read the data source info out of a properties file. I called the data source ProdPortalDb (it’s defined in /properties/uPortal55.xml), and the properties file is /properties/myumbc.properties.

Stay tuned for more.

Pool coping project — getting started

Time to get started on the pool repair project.. better late than never I suppose. I’ve blocked off this coming Thursday to rent a concrete saw and cut back the expansion joint. Also, I’ve been thinking a lot more about what to use to mortar the coping stones in place. Terry Tamminen’s excellent book, The Ultimate Pool Maintenance Manual, includes instructions for making what he calls “patch mix”, using white portland cement and sand. He uses this same stuff (possibly with different ingredient ratios; I don’t have the book here to confirm) for patching plaster, anchoring coping stones, and grouting stones and tile. I think this might be the way to go, rather than buying premixed bags of mortar as I was originally planning. Just need to find a supplier. I’m not too confident that the big boxes will stock white portland. If not, I’ll try my favorite lumber yard. Will work on researching this over the next few days. (Update 6/22.. no sign of white portland at Home Depot).

Oh, and the loose strip of waterline tile in the deep end fell off all by itself two days ago. I had to dive in to fish it out. Remarkably, it stayed completely intact, leaving me with a roughly 2-foot strip of mortar and pool tile, and the beam behind it is fairly clean too. I need to decide if I want to try to re-attach it, or just start over and retile (I have plenty of extra tile, so either is an option). This is the last step of the project, and won’t be happening until fall when I can lower the water level, so I’ve got plenty of time to think about it.


6/21: Informative posting on poolforum.com about setting pool tile.

6/22: Well, I decided to scrap my plans for the day due to unfavorable weather. However, I did go to Home Depot to take a better look at the concrete saw. I found out:

  • They supply all the fuel mixture I need (it’s a 2-cycle engine as I suspected)
  • There is roughly 5-6 inches from the blade to the outer edge of the dolly wheel on one side. This should be sufficient clearance to run the dolly along the pool coping edge. It will be helpful if the wheel height can be adjusted independently on either side to accommodate uneven surfaces.. but, I didn’t think to ask.
  • The saw includes a water feed, which is great because it should really help cut down on dust.
  • I don’t think it’ll fit in my car, so I’ll need to borrow my parents’ pickup.

Now, I just need to wait for the weather to cooperate, so I can get this done. Based on the 5-day forecast, I might be waiting awhile..

6/28: The crappy weather is finally moving out of the area, so the job is back on the calendar for Friday. Fingers crossed.

SSN Remediation is here

Woo-hoo! SSN Remediation happened over the past weekend, and we’re back up and running. I really think this is going to be a big win over the long term.

On the myUMBC side of things, there wasn’t much I needed to do. Just update my code in two places (one on the uPortal side, and another on the legacy Perl side) to go after the new “HP-ID” instead of the SSN. Then there were a few minor tweaks to some wording and input fields, and that was that.

This morning we brought all of our services back online, and turned them back loose on the masses. There were a couple hiccups:

  1. It broke PlacePro (I guess the real question here is, what doesn’t break PlacePro). Quick fix: a couple extra lines of code to pass the real SSN to PlacePro, rather than the HP-ID. Since we’re abandoning PlacePro in favor of another vendor, I doubt we’ll undertake a wholesale remediation effort with them; we’ll just cut over later this summer, and then have them wipe their database.I thought that the National Student Clearinghouse stuff would be similarly broken, but it turns out I implemented that totally separately and it appears not to be affected.
  2. I missed a couple places in the code where I was explicitly going after the socialSecurityNumber LDAP attribute, which broke a couple of things in minor ways. Another quick fix.

Other than that, things have been relatively quiet, and I’m just sitting around here waiting for the axe to fall. Keeping my fingers crossed..

Finally got in the pool

Better late than never, we took our first swim of the season today. It’s nice to finally be using the pool, because it makes the hassle of maintaining it seem more worthwhile. It’s not quite worth all the effort and expense IMHO, but still, it is nice to be able to hop in the pool on a hot day. And when it’s not full of leaves and other assorted crap, it’s nice to look at too.

I got a pleasant surprise when I uncovered the pool this morning.. the algae clinging to the diagonal hopper walls was almost totally gone. So, it appears that repeated brushing and superchlorination is the ticket to getting rid of this stuff. Apparently I don’t need a steel-bristled brush after all (although it may hasten the process, so I may pick one up anyhow). In future years, I’ll try to be a little more faithful with the off-season chlorination so the algae won’t take hold like it did this year.

Also, I made a test cut in the pool deck with my new diamond blade. And I must say, it cuts very easily — much more easily than I expected. As I suspected, the circular saw doesn’t cut quite deep enough. However, I can now go ahead and rent a larger concrete saw with the confidence that it’ll do the job. The current plan is to take a day off this week (work schedule permitting) and do it. Still not quite sure how I’ll do the curved sections. I’ll figure something out I hope.

Student Parking Registration

I should have seen the writing on the wall 5 years ago..

I’m busy fixing the online Student Parking Registration app, which has been sorta broken ever since the uPortal launch. Student Parking is a unique application. It’s the only app we have here that:

  • Communicates directly with the HP3000 mainframe via TCP sockets, and
  • Is not part of the monolithic ‘myUMBC’ Perl codebase.

Combine these two, and you get “never-ending headache”. Five years ago, when the app was written, I had vague misgivings about it being developed this way, but due to a combination of laziness and busy-ness, I didn’t say anything about it. So it went up, ran for five years, and broke with the new portal. And now, I’m stuck doing what should have been done with it from the start: I’m essentially rewriting it and building it into the myUMBC Perl codebase. Once that’s done, it’ll be reliable, it’ll have better error handling, it’ll deal with mandatory PIN changes, it’ll have a UI consistent with the rest of the myUMBC SIS functions, etc. etc. In a nutshell, it’ll work the way it’s supposed to, and I’ll be able to stop treating it like some high-maintenance colicky infant.

It doesn’t help that there are like 10 copies of the code floating around in various places, either. Half the fun was tracking down the version that was actually running in production…

Out with GUIDs.. in with Campus IDs

OK, policy decision for our up-and-coming launch of uPortal 2.5.. I’m going to stop using the LDAP GUID as the uPortal ‘unique username’, and use the new UMBC Campus ID instead.

Background: Every uPortal user gets an entry in uPortal’s user table, UP_USER. This table contains (among other things) a numeric ID for primary key, and a text ‘username’. Username is what uPortal uses as its security principal. For our current production installation of uPortal, we’re using the user’s LDAP GUID as the security principal. This works fine, but it causes problems with things like the Groups and Permissions manager, which allows you to search for specific usernames. The GUID is a long, unwieldy string that isn’t really human-friendly, so it’s not really something we want people using as a search key.

Now, why don’t we just use the user’s UMBC username as the security principal? Certainly seems logical. But, down the road, we want to provide access to the portal for alumni, prospective students, parents, etc. These people will not necessarily have a UMBC username. If we use that as a security principal, we effectively lock these people out of the portal. We need a unique identifier that everyone in the directory possesses. Until recently, the GUID was the only thing that fit the bill. Now, we have the nifty UMBC Campus ID, which is a simple string of two alphanumeric characters followed by five digits. Unlike GUID, the Campus ID is intended for human consumption (we actually display it on our ID cards). So, while it may not be quite as search-friendly as a username, it’s much more so than a GUID, and everyone in the directory has one.

Yet another happy byproduct of SSN remediation. I’m sure I’ll be cursing it next week after the SIS cutover, but I’ll say it again: In the long run, it’ll be well worth the hassle.

Followup… looks like if I want to do this, I’ll need to do an extra LDAP call to pull the Campus ID out of the PersonDB record. Not the end of the world, but not a 10-minute change either as I had hoped. I’ll have to come back to this later.

6/22: Looks like Rob is now including Campus ID in the Webauth ticket hash map. So, no extra LDAP query necessary. Cool…