
Sharepoint is a neat product. It has the potential to help organizations do quite a bit as far as collaboration, managing data, etc. But for some reason, people talk about Sharepoint with slightly gritted teeth that only now do I fully understand.
What do I mean? Check out Todd Bleeker’s blog post from over a year ago trying to detail the terminology involved with Sharepoint:
I get odd questions like this all the time:
How is a “portal site” different from a “WSS site” different from a “site” in a SharePoint portal different from a Web different from a Subweb different from an Area? And by the way, what’s a Topic?
…
That said, when you see the term “portal site” in SPS administration, SPPT really means the Site Collection of Areas (think special Webs). An Area is just a WSS Web based upon a unique Site Definition that leverages special SPS metadata, SPS Web Parts, and SPS administrative screens.
So even though Todd does a good job trying to detail the terminology, he still ends up drifting back into dark regions just 2 paragraphs below a clear explanation of some of the terms.
Hopefully this is something that can get correct and perhaps we’ll all be able to understand what the heck a “site” is when talking about Sharepoint (and what Sharepoint is for that matter – SPS? WSS? MOSS? CMS? etc, etc)
Several months ago Vikram Goyal emailed me letting me know he had a new book coming out from Apress – Pro Java ME MMAPI: Mobile Media API for Java Micro Edition. Having done mobile device development using J2ME, I knew how difficult it can be to do – or explain – some of the tricks in device development. So I wanted to see if this book could raise up to the challenge.
Vikram quickly sent me a copy, which I started to look through. And then we moved. Somehow in the move the book got packed in a box that was marked “Garage Sale items” and promptly shoved into our garage of our new house. While looking for some other things for my trip to Budapest, I stumbled across the box, and the book.
And am I glad I did. I’ve noticed as of late that the quality of the technical books I’ve been reading has deteriorated. Misspellings, wrong calculations, grammatical errors – not the thing to inspire confidence in the subject. In addition, the content can be hard to follow, it’s hard to grasp where the author is going, etc, etc.
Not this book. I was immediately struck in the first chapter by how clearly written the book is. Yes, you need to have some knowledge of J2ME device development (specifically MIDlets), but Vikram does a great job easing you into the subject, and providing good, easy to follow examples.
The subjects he is covering – dealing with media on mobile devices (specifically phones) is a particularly tricky subject. The problem? Many device manufacturers implements standards – differently. They claim to support things they don’t. They ignore features you would expect. And worse, their emulators, the very thing you develop against, don’t always match the phone. In fact, very rarely do they match the phone.
Vikram tackles this by testing his code on several different types of devices, and clearly lists out the dangers of relying on just the spec, or the reference implementation, or the emulator. Heck, I’ve seen versions of the same phone work differently based on what the provider had done to the phone. Verizon will always be evil to me based on my experiences of porting code that worked great on Nextel to Verizon phones, but that’s another story.
Back to the book. The chapters are clearly laid out in an order I think provided a great learning roadmap. In chapter 1, he introduces the Mobile Media API (MMAPI) explaining what exactly it is, how it ties into things like MIDP 2.0 (Hint: MIDP 2.0 contains a subset of MMAPI functionality), and who supports it.
Chapter 2 provides an overview of the basics of the MMAPI. In particular, how to get data from a DataSource to play in a Player. Since the MMAPI is designed to be implemented by device manufacturers, it is a great read to see how an API can remain simple, yet cover a vast array of inputs and outputs. For example, Player instances can read files, streams, web sites, and a variety of other inputs. It can control audio, video, MIDI and tones. All of this using the same underlying API. Pretty good stuff.
Chapter 3 gets us diving into some code. We write a basic multimedia player, and then improve it to add functionality and increase performance by understanding what is involved in caching Players.
Chapter 4 continues on explaining the more about the underlying architecture, specifically the media player lifecycle and events. Since we are dealing with devices that generally have limited resources, the API provide a way to save claiming those resources until as late as possible. In addition, it provides ways to reclaim those resources, and Vikram covers some of those ways in this chapter. He then moves on to discuss the eventing architecture, and how to respond to custom events (he does briefly describe writing your own events – but I can attest that getting anything that low level on a device from US providers is usually pretty difficult).
It wouldn’t be a good programming book if we didn’t talk about threads at some point, and Vikram touches on it in Chapter 5. Specifically, we’re diving into accessing files over the network, and we don’t want to block the device while we are doing that. Yes, when you are running a MIDlet, the app thread is the main phone thread, so if it is waiting for network traffic, the phone is unresponsive to the user. So very wise use of threads is necessary. In addition, some security considerations start coming into play, and the book covers what to expect.
Now the fun starts. In Chapter 6, the book discusses Tone Control, the first of 2 entertaining chapters on making your device make noise. The chapter starts off with a very concise explanation of basic music theory to give developers an understanding of what they are going to need to do to generate tones of different pitches. It then moves on to the difference between Mono and Polyphonic notes, and how to create sequences of notes. By the end of the chapter, you too can have your phone playing “Happy Birthday”.
Chapter 7 continues on with the party, going into one of my favorite subjects – MIDI. Again, we get a good, concise introduction to the fundamentals of MIDI. We then get to see how to send raw messages to a device that understands MIDI, and how to use MIDI in the MMAPI.
Chapter 8 touches on the other aspect of media – Video. To do this, it first discusses sampled audio, and how to capture and control it. It then goes into capturing video, which many devices may not support, and how to capture snapshots for those devices with cameras. It also covers what to do with the file when you’ve captured it (for example, save it or display it to the user), and closes with a discussion on streaming media.
I was surprised when I got to chapter 9 because chapter 8 ended by saying what we were going to cover in the final chapter, and I hadn’t realized that I had read that much already! Chapter 9 is a great way to end the book – Vikram shows us how to implement our own mobile blogging website, complete with implementing uploads for Text, Audio and Video (if our devices support it). He even provides screen shots and full code, walking through it step by step to help us understand what is going on.
All in all I very much enjoyed the book. If you have a phone capable or supporting J2ME, this is definitely worth a read. The writing is very clear, and entertaining. If there is a downside, it the poor integration of J2ME in a lot of providers devices, and the inconsistencies in the implementations. But thankfully Vikram guides us through all that so we can quickly be up and running singing along to our favorite dance hit with the words on our phone, mobile blogging the whole thing.
So, in yesterday’s post, I mentioned a story that happened. Well, not so much happened, but I wish they had this in the states.
While I was out walking, I ran across what looked like a small collection of stores. Going in, I discovered it was a 5 story mall, complete with bowling alley and skyway to a second 5-story mall. Anyway, while walking around in there looking for something neat for my daughter, I came across a wooden toy that looked perfect – except it looked like it had little toys with it. Upon closer examination I discovered it was this:
Yes, “The Attacker & Viruses”, placed right next to, I am not making this up, “Emo’s Mail Hub”. Yes, folks, this is a playset which replicates our faithful network admin, Emo, defending his email hub against the nasty viruses riding in on a wooden worm.
But, if that’s not enough, they combine it into one easy to buy full playset!
I really, really, really almost bought this. Except that, being on the road all the time it would just sit in my office not getting the proper attention such a toy as this deserves.
I do know that I have got to find the company that makes these (Brio is my guess) and see if they sell these, or any other cool toys, state side.
And, for the record, I ended up getting a teddy bear for Annabelle. I figure I’m going to wait until she’s at least a year old before introducing the networking concepts. ;)
My customer has kept me very busy here, not to mention that it gets dark at around 4:30 pm and it’s been raining, so it was hard to go out and get some pictures.
Tuesday night, though, I had to go out to find something to eat, so I took my camera and grab some shots. Shooting beautiful buildings in the dark is difficult without a tripod – I wish I had brought one now.
Anyway, here goes, a collection of pictures from Budapest:
I don’t think I’ll have a chance to get many more – I fly out Saturday, so it would have to be tomorrow night, but at least I got to venture out a little. There’s a great story about what happened last night, but that will have to be saved for another post…
After almost 20 hours of traveling, I arrived in Budapest this morning to teach a Visual Studio Team System class to a company over here.
I’m getting the chance to stay right on the Danube river, and wanted to share some pictures before I collapse into bed. ;)
The hotel is in an old converted castle, and I’m overlooking the city and the parliament building.
Hopefully I’ll get some time to explore the city - there is a ton of things I want to see and capture.
So, one of the tough things about Ruby development has been lack of things like Intellisense and Debugging. There was always the Eclipse tools for Ruby, but for those who use Visual Studio – rejoice! Sapphire Steel Software has released Ruby In Steel, which lets Visual Studio users do all sorts of Ruby goodness – even Rails – right from Visual Studio. Definately worth checking out – the personal edition is free to download.
In my previous posts, I talked about improving performance of your XslCompiledTransform code, and working to compile XSL which might be cached.
These threads started because of some confusion around one of our MSDN docs – specifically this one on migrating code to XslCompiledTransform. Specifically it says:
The XslCompiledTransform class includes many performance improvements. The new XSLT processor compiles the XSLT style sheet down to a common intermediate format, similar to what the common language runtime (CLR) does for other programming languages. Once the style sheet is compiled, it can be cached and reused.
Implying that the style sheet was what needed to be cached and reused. This is a documentation bug and is in the process of being replaced. The only supported way to cache and reuse compiled XSL stylesheets is by caching and reusing the XslCompiledTransform object.
So there’s the good word. Eventually we’ll see it updated in the docs, but that is my experience, and what I tell my customers on-site.
I don’t think anyone can top the email that came across one of our internal mailing lists:
Please tell me how to install “agile software” in my machine
Michael Eakes has a great article up about the new iPod pea. Touting it as a major accomplishment to get the music player to just larger than the headphone jack, there isn’t much that I couldn’t see Apple really doing with that device. Great article!
So tonight I was switching around some windows, and accidently managed to delete (shift-delete nonetheless) all the emails from my inbox in one of my accounts. This is a lot of email, and while I had some older backups, I hoped that maybe I could restore them (even from a shift-delete).
The first thing that I hoped I had going for me is that generally when you delete an email, it really just flags it, not removes it. When you do a compact folder, it goes through and cleans up those deleted emails. So I immediately closed the application and dropped to a command prompt. This looked promising:
foyc@dilbert ~/.thunderbird/[account] $ ls -l Inbox
-rw-rw-rw- 1 foyc users 843590900 Jan 1 17:56 Inbox
Ok, it’s large enough to hopefully still have the emails in it. So I copy it out to a working folder. Now let’s see what is inside of it. I do a tail -n 1000 Inbox and see these interesting headers:
X-Mozilla-Status: 0008
X-Mozilla-Status2: 00010000
So off to the web I go. Christian Eyrich has a great page explaining the status codes. The relevant bit is that 0×0008 is “Already Gone”. Changing that to 0×0001 “Message has been read” should bring them back. Since it has been a long time since I’ve compacted, I’m probably going to undelete a bunch of email that I thought was gone, but that’s worth it here.
So, let’s make the change. Just to check myself, let’s see if the messages look to be deleted:
tail -n 50000 Inbox | grep 'X-Mozilla-Status'
X-Mozilla-Status: 0008
X-Mozilla-Status2: 00010000
X-Mozilla-Status: 0008
X-Mozilla-Status2: 00010000
X-Mozilla-Status: 0008
X-Mozilla-Status2: 00000000
...(etc)
Ok! sed should be able to help us out nicely here, so let’s try that out:
foyc@dilbert ~ $ sed 's/X-Mozilla-Status: 0008/X-Mozilla-Status: 0001/g' Inbox > FixedInbox
And let’s sanity check the change:
foyc@dilbert ~ $ ls -l FixedInbox
-rw-r--r-- 1 foyc users 843590900 Jan 1 18:41 FixedInbox
foyc@dilbert ~ $ ls -l Inbox
-rw-r--r-- 1 foyc users 843590900 Jan 1 18:17 Inbox
tail -n 50000 FixedInbox | grep 'X-Mozilla-Status'
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00010000
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00010000
X-Mozilla-Status: 0001
X-Mozilla-Status2: 00000000
...(etc)
Ok, so let’s see if this fixes it. I’m going to move the existing Inbox, copy the FixedInbox to the same location (renaming it Inbox) and fire up Thunderbird.
foyc@dilbert ~/.thunderbird/[account] $
mv Inbox Inbox-deleted
foyc@dilbert ~/.thunderbird/[account] $ mv ~/FixedInbox Inbox
and…viola! All of my emails (including *lots* I thought were gone) are back!
It’s times like this I am glad for open standards and the ability to look at things like the data file. If Thunderbird had stored the emails as binary, or some proprietary format, I probably would have either had to go buy special software, or just chalked it up to not being careful and backing up that file more often. But thanks to their willingness to be open, I was able to fix a stupid mistake myself.