demallien

The people over at Microsoft are not idiots - even though Microsoft is no longer the new hotness, they still pay developers well, and have some pretty tight engineering going on. So when you say "The Event constructor is broken out of the box", my first instinct is to assume that the Microsoft engineers have implemented the constructor in their way for reasons that you're not smart enough to have grasped.

But, as I said, I know that you aren't a young inexperienced programmer, so you probably have some good reasons to make the claim, which leads me to the point of this rambling post - why is the Event constructor broken in IE? I'm curious to know what specific problems you have with it.

Divers attaching charges to the hull would be another low-tech way to take a vessel like this down. Low tech mines would probably do a pretty good job too.

Take a concrete example. Let's assume that I have a recording in PCM at 44.1kHz, and I want to see all of the frequencies present, to a resolution of 10Hz. Nyquist tells us that we only have 22.05kHz of signal present in the sample (well, one can hope, otherwise if the recording didn't filter out everything above that when coding to PCM, we're going to have a mess of aliasing going on, which is outside the scope of this post - just assume the person doing the encoding knew what they were doing, mkay...). So, 22.05kHz. And we want a resolution of 10Hz, so we're going to need 22.05kHz / 10Hz = 2205 samples. Of course, we actually need double that in the time domain (we throw away the phase information remember), so we need 4410 samples in the time domain to get our 2205 samples in the frequency domain. 4410 samples at 44.1kHz sampling is equal to 0.1 seconds.

If I decide that I want a better frequency resolution, say down to 1Hz, then you quickly arrive at the conclusion that you will need a full second of samples. In other words, your resolution in the time domain has decreased as you improve the resolution in the frequency domain.

You can improve a bit on this situation by using a sliding window with a carefully chosen windowing function. The frequency information will still be smeared out in time, but the windowing function reduces the amplitude of a frequency the further it is from the centre of the sampling window, which sharpens up the smear a bit.

Which is not to say that there aren't shenanigans going on, but there's a reason that consumers really like MasterCard and visa, they both look after customer interests, sometimes at the expense of merchants.

Or, maybe just maybe, it might lead to less deaths by shooting if there were less guns floating around to do the shooting with?

There's a reason for that. Getting software onto an iOS device other than downloading it from the App Store is really difficult, and that goes for viruses too. Put that together with the fact that you need to provide apple with authenticated identity to get things into the App Store, and you end up with quite a secure platform

Sure, that security comes with some restrictions. For you that might not be the right choice, but for many people it absolutely is. The Mac provides a platform somewhere in between the two. You can load software from unapproved places, but the system warns you. I think this is a reasonable trade off. Most people do need to be made aware that such actions are risky. They may decide not to load that software after all, and that's a good thing! If you're unsure of the risks involved with loading a piece of software, then you probably shouldn't be loading it.

Finally your point about loading test versions of software on iOS is out of date. This is one of the many major improvements Apple delivered for developers at this years WWDC. The procedure is much more streamlined than previously. At this point it's debatable whether it's easier to manage testers using ad-hoc APKs on android, or using Apple's test deployment system.

If you go back 18 months or so there where a whole slew of articles describing peoples experiences trying to go iPad-only for trips. They all ran into problems caused by the lack of direct access to the file system, making the sharing of content between productivity apps quite difficult.

With the release of ios8, Apple has addressed this problem. In particular, extensions are a potential game changer, making it easy of apps to work together. For the time being I'm holding off on predicting the iPad's demise - I'm going to wait and see how the market responds to these new capabilities in ios8. For now it's an open question as to the iPad's ability to replace a normal computer for many people. Last year the answer was no, this year I'm not sure.

I just noticed though, as I'm writing this reply, that most of these flaws come out in the second book, not the first. Maybe you need to stick with the series a bit more before making up your mind.

Well, you might accept that I'm "idealizing" Access because, you know, I had a decent experience with it 20 years ago, as described in my first comment. No need to go searching for mysterious ulterior motives when they're explained in the post!

For what it's worth, I do remember significant flaws in Access. For one thing, it was an absolute pain when we wanted to modify the database - we had to get everyone to log off, and then upgrade all of the clients at once. This is one of those problems that the web solves elegantly. Also, Access had major issues with concurrent users. Performance fell off a cliff, and from memory, certain operations were unsafe (I think you could set up a SQLServer which would address the concurrency problems, but we never bothered).

But these days we have better options available to us - app stores fix the updating problem, without introducing the css + html + javascript mess. We have decent, free web servers, and web application frameworks such as Django and Rails that make writing the server side code that drives the RESTful APIs used by the client relatively easy. But what we don't have is:

a) an easy way to create a server (this needs to be as easy as sharing an Excel spreadsheet) b) a coherent development environment from client to server code. Something that allowed you to write apps purely in Javascript (no css or html) with a GUI editor, and which also let you write the server code in node.js would be a close match to what I'm thinking of. Bonus points if most of the node.js code is derived from the client-side code, so that the novice programmer doesn't need to be aware that a server even exists, it just works.

The problem is, that's the kind of application that's really hard to write. It's big, an IDE in fact, and really Microsoft is the only game in town for making that sort of stuff. But they won't write Android / iOS / Mac clients, so it doesn't happen.

I keep thinking back to an Access application that I threw together in a couple of days, back in the 90s for managing a team of about 40 technicians. It was being used for task tracking, and had some wiki-like features as well. When I started that project I knew nothing about Access or VB, and yet in two days I had a bunch of forms and tables that allowed managers to get a quick feel for what their staff were up to. The thing ran over the LAN, and could handle 10 simultaneous connections without any dramas. If I were to try the same thing in the web world, I might lose myself in getting just one table view working correctly for a week. Getting an http server configured and up and running, and talking to a db server would be at least two days. And there would be many potential roadblocks just waiting to trip me up along the way.

These days, rather than dealing with that mess, many companies just go for an off-the-shelf hosted solution that sort of fits their needs, such as Basecamp, or Jira, or Igloo. The existence of these products is a sign that we've gone off in the wrong direction somewhere - the sorts of products they make are very similar to that online apps you could make with Access 20 years ago.

Actually, just reading through the list, I was a little disappointed. Yes, there are some great classics, but Timeline" by Michael Crichton as the "time travel" sci-fi novel of reference. No, just no.

For time travel based sci-fi, Timescape by Gregory Benford is my pick of the lot. Bedford is actually an astrophysicist, so his version of time travel actually make sense. Plus, the characters in the books are scientists. It's a very thought provoking book. He has a second book along those lines, Cosm, which I loved as well, for it's portrayal of the lives of scientists.

This was actually quite a reasonable sailing simulator if I remember correctly. Good enough that when I finally got a chance to sail for real a few years later, I knew what I needed to be doing in terms of positioning sails to obtain various points of sail. Of course, navigating without an overhead map being available, and knowing about ropes were two things that I still had to learn the old-fashioned way :)

It didn't gave the drawing mode you mention, but u did actually write a program that did exactly that. It also had a print function - only worked with the Epsom dot-matrix printer we had, as I used a special control mode. Basically a character was an 8x8 array of dots drawn one column at a time by the print head. You could manually control the print head though by putting the printer into a special mode through escape codes, and then just sending binary 8-bit numbers to encode pubs you wanted to print for each column.

Thinking back I can't believe I made it work - I was only about 10 at the time. I do remember facing to stick my nose in the printer's manual for a long time. Of course printers had manuals then, not like today...

There's a good online emulator of the CII here: http://compucolor.org/emu.html