Monday, June 9. 2014
hmmm, just got an email about a USPS delivery, need to print a label and take it to the post office.
but hey, the mail from domain is buran7.beget.ru, and the payload or link i need to click on is missing from the message.
whew, guess i dodged a bullet there.
Deferring again talking about implications of online content...
There are two different ways to play a Networking course. Is the room full of potential Network engineers, or is it full of potential application developers? It makes a difference.
In the case of UAlbany, the course is offered in the framework of the Computer Science department, and the students tend to be mostly software oriented. This means that I should be trying to make them comfortable with socket programming paradigms, which are a bit different from straight line single threaded development exercises. Socket programming is also what many (most?) of the full time faculty think the course is supposed to be about.
But this doesn't excuse me from teaching a lot of the lower level stuff. I've encountered a few too many software developers, who while competent on the development side, are more than a little vague on how some of the networking stuff actually operates. You can write a socket program without understanding how the client side determines a port number, but you may find yourself at a loss when trying to use tools like nmap, tcpdump and wireshark to poke at your application with a stick, and may be pretty clueless about firewall setup as well. So at the bare minimum we need to talk about IP and friends, and it makes little sense to leave out layers 1 & 2 (ISO model) when talking about everything above them.
So the future evolution of the course will need to improve on the socket programming side while still providing the students with a solid foundation in how the various layers in the reference model work.
And there will always be a need to cover things like clocks and NTP because I can't see them encountering that stuff anywhere else before they graduate and move out into the real world.
Sunday, June 8. 2014
I'm going to defer the promised posting about the implications of the online content of some of the Pearson books for now, in part because I'm going to be getting evaluation copies of some Morgan-Kaufman books and they have online content as well, best to go through both sets of terms and conditions and think about what they mean first. In the meantime, here's the Syllabus from this past spring - one task will be to compare the syllabus with the content of each book to compare coverage.
Saturday, June 7. 2014
So I have a number of textbooks in front of me, with at least one more coming. Four of the six are straight up networking textbooks, the fifth is a classic on Unix socket programming that would be a supplemental text, and the one coming is an O'Reilly book on Java Network Programming that would also serve as a supplement.
Where do these evaluation copies come from? I actually paid cash for my Kindle edition of TCP/IP Illustrated, Volume 1 a year and a half ago as I jumped into the course with very little notice. O'Reilly has an ebook based evaluation program, and I expect to receive a link for a copy of the ebook version of Java Network Programming "any day now". The remaining books all came from Pearson, who provide a choice - either a traditional paper copy, or web access. No ebook option is offered. I would have preferred ebooks, and selected the paper book option as otherwise I would only be able to access the books when I had an internet connection.
The first thing to note is that of the 6 books, 5 are from Pearson, who have acquired Prentice-Hall and Addison-Wesley and thus moved into a dominating position in publishing for the college and university marketplace. So while there is certainly textbook choice, there isn't much publisher choice. Another element to consider is that ebook editions are available for all of these books except for the Unix socket programming text, although the price break for the Kindle editions is around 10%, so that $124 networking text doesn't get a whole lot cheaper in Kindle form.
Of the four networking texts from Pearson, two have "premium content" online. For both books, there is a scratchoff strip inside the front cover with a code that is good for 6 months of access. Presumably Pearson wants the instructors to use the online material in support of their courses. I considered this, and realized that it represents a fairly naked attempt to kill off the used textbook marketplace - the codes are onetime use and if used, the value of the used textbook drops rather sharply. I'm not playing that game. While I might adapt one of these texts, the course will not require that the students access the premium material.
In the case of one of the "premium content" books (Stallings, Data and Computer Communications, 10th edition) the two chapters on computer security are behind the online premium wall. I find this particularly egregious, and so the Stallings book is DQ'd from consideration from the very start.
Now I'm down to 3 straight up networking textbooks. The other book with premium content (Kurose & Ross, Computer Networking: A Top Down Approach) doesn't hide critical material in the same manner, so it remains in the mix for the time being. The premium content is related to class exercises and I can manage that on my own. It will be the student's choice whether they scratch off that strip.
The other two that are in the mix are Fall & Stevens (TCP/IP Illustrated Vol 1, 2nd Edition, the text I've been using), and and the 5th edition of Tannenbaum & Weatherall's classic Computer Networks.
So what are some of the differences and things of note?
Stevens and Tannenbaum both start from the bottom with layer 1 (the physical layer) and work their way up through the network stack. If I use one of these, I have to tinker with supplemental material so that I can get socket programming assignments going early on during the class. Neither of these books really pretends to deal with network programming anyway, but it's good for students to have at least some understanding, however cursory, of UDP and TCP before you tell them to start coding.
Kurose & Ross is structured very differently (It's that "Top Down" part of the title.) In looking it over, I can't help but think that this approach is a really good idea for several reasons. It puts me in a better place to give out assignments early on, and I think it's probably easier to motivate students by starting with applications, which is something they've already seen even if only as black boxes (e.g., web servers and mail servers.) Additionally, they do cover network programming - but they use Python (previous editions used Java). So if I go with this text, I'd want to have the supplemental textbooks available as I'm not inclined to dump a new language on students who are already dealing with lots of other things.
The fifth book is Stevens' Unix Network Programming, Volume 1 which would be a supplemental text for the C developers, and the sixth is the aforementioned O'Reilly book on Java Network programming. I will probably look for one or two other supplemental texts, but this is really the least of my concerns.
So basically, I am leaning towards Kurose & Ross despite the premium content issues because I like the order of presentation better. Now to start really looking at the books hard to see what's what. The next blog posting will discuss some of the challenges I perceive to exist given the online content.
Thursday, June 5. 2014
I've taught the Spring course in Computer Networking at UAlbany for two years now. The first year, it was a bit of a surprise and I was playing catchup from day one. The second time, it was a little less of a surprise, but I still spent a lot of time playing catchup. One of the results of this was that for a textbook, I defaulted to using the 2nd edition of Steven's classic TCP/IP Illustrated, Volume 1, because I was familiar with it and liked it. But I've become concerned that there was a bit of divergence between the course syllabus and the book, so I decided to check out some of the alternatives. I now have copies of 4 other text books to review, and have found a large can with many worms inside. Since it's tolerably certain that I'll be teaching it again, I was going to work steadily on improvements over the next 8 months in any case, but just the quick once over of the textbooks suggested other things I should look at.
But first, I should describe the basic course parameters. It's offered by the Computer Science Department, so the presumption necessarily is that the average student will have experience in writing single threaded programs that run on a single computer, and limited knowledge of the hardware side of things. My observation on the student mix is that, having been given the choice between writing projects in C, and writing projects in Java, the class splits fairly evenly, so I expect to continue to accept projects in either language. I also note that student choice of OS on their laptops varies, which is ok with me, but does mean that if I want them to install any particular software, I need to keep that in mind. I can in theory go with Un*x/Linux only software given that all students have accounts on a University Solaris system, so I can make them ssh into it and work with a text based system, which the Windows types may find annoying, but I assert that it's good for them.
As the syllabus has evolved, I've found myself adding lots of stuff that's not in Stevens (and Stevens isn't really a programming text anyway, so the Socket Programming API has always been supplemental material), and I've been using my own ordering of presentation, which has gradually improving. I have leaned on some lectures written by a prior instructor for subjects like queuing theory. The projects to date have been socket programming exercises. A prior instructor used one of the ns series of network simulators for exercises, but I haven't had a chance to really look at how I might integrate such a thing.
From the perspective of ordering of material, I need to get them doing some socket programming early, so at least a cursory outline of TCP functionality needs to be done very soon after the course starts, to provide a framework for understanding why the Sockets API is what it is. If I add network simulator exercises, I may (depending on the ordering of course material) be able to delay the first socket programming exercise a little.
So these are the sorts of things I have to consider as I go forward. Next posting will be a little bit about the 5 textbooks I have in hand right now.
Saturday, May 31. 2014
by way of introduction, i am both an enthusiastic driver (who had a brief career as a mediocre club racing driver) and an enthusiastic cyclist (who will probably never race, but does enjoy long rides). i tend to ride on bike paths or out in rural areas where i know the roads well. urban cycling scares me, as way too many drivers are not paying attention.
so yesterday i found myself on NY 155 heading north, and then taking the short slip ramp onto Washington Avenue Extension (this is in Albany, NY, for those of you who aren't from around here.) A cyclist was crossing 155 from my left to my right and our paths were about to cross where the slip ramp merged into Washington Avenue Extension.
so what did i do? well, being a cyclist myself, i recognized two things - first of all, that per the rules of the road, he had the right of way and i was obligated to yield it. and second of all, that most drivers don't really get this and he was probably going to be very concerned about my intentions and my attentiveness.
so as i came around the slip ramp, i deliberately hung back and paced him, while looking straight at him. when he looked over at me to see what i was about to do, we made eye contact. this turns out to be enough information for him to decide that we are actually going to follow the correct rules of the road, so he signaled that he wanted to move across to the shoulder. i waited for him to do so and then gave him plenty of room on my right as i accelerated by. and he was apparently very appreciative of the fact that it was all done correctly and waved at me as i moved on.
what can we do to teach every one, drivers and cyclists alike, to do these things properly?
Monday, May 26. 2014
Decoration day being the original name for the holiday we now call Memorial Day.
Earlier today I shared this link on G+ and Facebook: Frederick Douglass on Decoration Day 1871. I've been pondering somethings about this address, and the context in which he gave it, since.
In 1871, Reconstruction was in what passed for full cry. Ulysses Grant had been president for 2 years. It was Grant's avowed goal that he would accomplish two things - reconciliation, and protection of the rights of the former slaves. The great tragedy of Grant's administration doesn't have anything to do with political cronyism or corruption. It has to do with the fact that Reconstruction succeeded in bringing the ex-confederate states back into the Union, while failing to do very much to protect the Freedmen.
At the time of Douglass's speech, many still had hope. They believed that Grant, still a popular hero, could pull it off. The problem was that the best opportunity to take care of the former slaves came at the end of the war in 1865, and and it was already gone, lost in the disputes between Andrew Johnson and the Radical Republicans. Civil government was being restored to the southern states too quickly, on terms that were too easy, resulting in political and racial violence that was very difficult to deal with.
So when I read Douglass's speech, I think about the hope for the future he had at the time, and I am saddened for all the death and destruction of the Civil War, and doubly saddened that the opportunity to provide protection and justice to the Freedmen, gained at such a terrible cost, was fumbled.
Tuesday, February 11. 2014
There's been a bit of talk about how Sochi might be the worst Olympics ever. I've been half jokingly saying that this is impossible, while thinking about the 1936 olympics.
But the more I think about it, the more I have come to understand that there are two Olympic games that stand out, and the reasons they stand out are geo-political in nature, and no matter how many defective toilets and nonexistent hotel rooms turn up in Sochi, Sochi will never be able to match up to the awfulness of 1936 in Berlin and 1972 in Munich.
In 1936, of course, the Olympics had Hitler. Do I need to say more?
In 1972, Munich had the tragic "Munich Massacre".
So a bunch of broken and incomplete facilities make the worst ever? Not even close. I hope that we never again see an Olympics so bad as 1936 or 1972.
Thursday, December 12. 2013
Tuesday, December 10. 2013
While I appreciate all the tributes to Rear Admiral Hopper on what would have been her 107th birthday, I'm disappointed in the superficiality of most of them. Usually they mention her naval career and COBOL, but that's about it. She was actually quite a bit more than that.
Before WWII, she earned a PHD in Mathematics from Yale and became a faculty member at Vassar.
During the war, she joined the Naval Reserves and found herself assigned to work at Harvard on the Mark I, where she became one of the first programmers.
After the war, she wished to remain in the Navy, but they declined because she was too old (38). She remained at Harvard until 1949, when she joined the team developing the UNIVAC I. It was while she was there that she developed the concepts of higher level languages and compilers (the first actual compiler was developed by Hopper, 1952.)
She returned to active duty with the Navy in the 60s, and retired and unretired several times until her final retirement in 1986. She was a strong advocate in the Navy for a move to smaller, distributed, networked computers instead of large centralized ones.
Her career spanned academic, commercial and military worlds, and she was very accomplished in all of them. Just referring to her involvement in COBOL isn't giving her nearly enough credit.
And I think she really liked being in the Navy.
Sunday, December 1. 2013
...aren't necessarily useless after the contract is over and you've acquired the new one...
i have recently repurposed an old iPhone 3GS as an iPod touch, something it does pretty well. and my wife's retired HTC Android is now serving as a GPS, thanks to OsmAnd, an OpenSource GPS program for Androids that uses OpenSreetMap data. so don't assume that the old phones don't have a purpose any more, they can still slurp up and export data via wifi, and can run useful programs.
what i have learned, though, is that usually they won't come up unless they have a sim. the good news is that any sim will do, even old ones that have been deactivated by the carrier. put the sim in, "activate" the phone, take the sim out and put it in airplane mode. this works similarly on iphones and on androids in my experience.
Wednesday, November 20. 2013
this spammer does not appear to have fully mastered their comment generation scripts:
can we get some better quality spammers please?
Jimapco is kind of a legend in the Capital District of New York. For the longest time, they have been a notable supplier of maps of very good accuracy (not perfect, but very good). They are under copyright, of course, and so are not acceptable sources for OpenStreetMap, but I have always respected the quality and when I used to put on TSD rallies I would always buy a couple of the relevant county maps each year and hand them out to my checkpoint crews so that they'd get to the right places.
So last night I was at Tech Valley High School for a chain of meetings involving various combinations of parents and students, and opted out of the social committee meeting (as that was really my daughter's gig). I found myself looking at a 2008 version of the Jimapco greater capital region map which happened to be posted on the wall, and decided to look at one or two spots where I knew where there might be issues. I was more than a little surprised.
There were three specific areas where I caught things that were significantly out of date. The first has to do with a cluster of town roads at the Sand Lake/Nassau town border on the east side of Burden Lake. If you look at this link (http://www.openstreetmap.org/#map=14/42.5916/-73.5414&layers=N) to OpenStreetMap, you can see CR 20 and CR 47 just kind of end, connecting to town roads. At some time in the past they certainly extended further, but today they just end. The 2008 Jimapco map shows them continuing - but I've lived in the area since 2000 and I'm quite sure that it's been a bit longer than that since these county routes were through. Being an OSMer and a local, of course, I've visited these roads and taken GPS coordinates at the exact spots where county maintenance ends; there is no doubt about this.
The second is the routing of NY 338. Originally NY 338 was a very short highway in Saratoga County, a bypass around Schuylerville. In 1980 it was turned over to the county and was redesignated Saratoga County CR 338. NYS then reused the designation across the river in Washington County for a short state route that passed through the hamlet of Cossayuna on Cossayuna Lake, connecting with NY 29 on one end and NY 40 on the other. The 2008 Jimapco map shows this alignment. The problem that NY turned the road back over to Washington County in 1996 and it's been Washington County Route 49 since then: http://www.openstreetmap.org/#map=13/43.1635/-73.4490&layers=N. So that's an update that's 12 years overdue in 2008. I was putting on Road Rallies in this area back in the '80s and I certainly remember when this was NY 338 - but I've been back since and it's definitely not NY 338 today.
The third is the routing of NY 66 in the vicinity of the hamlet of Averill Park. This link to OpenStreetMap shows the modern routing, which passes east of Averill Park, through the hamlet of Sand Lake (all of this is contained within the Town of Sand Lake): http://www.openstreetmap.org/#map=14/42.6403/-73.5544&layers=N. This particular routing dates from 1980. The 2008 Jimapco map, however, shows the pre-1980 route, where NY 66 passes through the center of Averill Park. The modern CR 45 is Old Route 66, which meets NY 43 in the center of the hamlet. In the old routing, 66 and 43 overlapped from this point east to Sand Lake, where both then turned south (right). So in 2008, this update is 28 years over due.
So this is really a very disappointing performance from a highly regarded map provider. I suppose I should run up to their retail map store and see if the current version of their map still has these problems, and maybe look at some of their more detailed maps (say, the county maps) to see if they share the problems.
Friday, October 11. 2013
i've decided to start using my OSM diary for a lot of the mappy stuff. When I post new articles there, i'll provide links here.
My latest, on the progress of Highway Shields in NY, is Shields Up. a list of all diary entries may be found here
Tuesday, September 17. 2013
(boy, i seem to be blogging a lot today)
the relationship between drivers and tech can be a touchy one. lots of drivers really don't like interacting with tech inspectors, they just kind of assume that it means trouble. and i have, at times over the years, seen incidents that would seem to justify this sort of reaction. but there's another type of driver and tech interaction that i'm blogging about today.
giving tech a heads up
from time to time, drivers will tell a tech inspector what they think is going on in their class. this can be pretty interesting, and usually happens at the beer party after the day's activities. i kind of like hearing this stuff - but drivers need to understand certain things about how i might (or might not) respond to their information. and it's rarely personal, unless something comes up that spins it that way. and the spin usually comes when the driver is being disingenuous about something.
years ago, an ITS driver who is no longer active came up to me at the beer party and told me about all the stuff that he was sure the RX-7 ITS drivers were doing. i listened carefully, but didn't commit to a response (i generally don't). the funny part was that when i did impound ITS to check for the (mandatory) window glass and ride height later that season, this very driver had substituted plastic windows for glass windows in his doors - which is not permitted. this driver was clearly trying to use tech to go after other drivers in his class, and this is the sort of situation where if that is discovered, i might just take it personally - because i feel like someone is trying to play me for a fool.
more recently i recall a National race where two drivers in showroom stock kept showing up in tech to describe bad things the other driver was doing that we should check. Really Guys? if you think he's cheating, file the protest and post the bond. or maybe get a room - either way, just leave tech out of it. we are not going to respond to this.
what may happen
If you do come up to me and suggest something that might be going on, I will probably not do anything right away. I may want to research, and may want to talk to other drivers in the class to get their take on things. I may need to take steps to get certain tools to the track. Even bringing something up a couple of days before a race is likely to not get anything done promptly. Tools may not be easily accessible. Two weeks is way more time than 3 or 4 days if you need something shipped or have to buy something. And I need to be careful about appearances; tech should not be perceived as responding to any particular driver's agenda, unless the agenda is clean racing. If you do contact me 2 weeks before a race to arrange equipment, you should be planning to file the mechanical protest, and not be trying to get me to impound someone you don't like.
Also, if you do decide to actually file a mechanical protest, a couple of suggestions:
1) file it early in the race weekend. that gives us time to decide how we're going to approach it. once the protest is filed, we can take steps to secure the vehicle and prepare for whatever is needed. for intrusive things, we might seal the engine and plan for disassembly after the race. and by the way, be aware that mechanical protests filed in the last hour before the race are not timely and won't go anywhere.
2) don't offer us tools. the protested party will use their own tools for any disassembly, under supervision of a tech inspector. after disassembly, tech can't use measurement tools supplied by a party to the protest. on one occasion, a bunch of drivers got together to file a protest of one of their competitors, and since they'd planned well in advance, they brought some very nice tools to the track for the needed measurements. they were very offended when we told them we couldn't use them - but if we had, there would have been nothing but trouble down the line. i seriously doubt we would have made it past the committee at the track if we'd used the protestor's tools to measure the protested engine.
what's in the toolbox
There are some useful things in NEDiv that can be at the track, but they won't necessarily spontaneously appear.
1) bore and stroke gauges for center plug engines. yes, we can bore and stroke some cars without pulling heads, but not all of them. but we won't necessarily have these tools at every race.
2) there is a whistler which can be used to measure compression without pulling a head
3) some regions have puff testers, which can be used to measure displacement in some motors - in particular, american pushrod v-8s are candidates for this measurement.
If I knew in advance I might need this stuff, it can certainly be at the track.
(Page 1 of 9, totaling 127 entries) » next page
Syndicate This Blog
right side networked blogs