'N Kort geskiedenis van SharePoint (Uit 'n relatiewe nuweling se perspektief)

Let daarop: Hierdie artikel is oorspronklik gepos word aan www.endusersharepoint.com. I forgot to post it to my own blog 🙂

SharePoint ontwikkel het 'n groot deel sedert sy vroeë dae as 'n soort van 'n inkubasie tegnologie by Microsoft –dit ontwikkel het amper soos 'n horror movie, waar die mal wetenskaplike se skepping neem op 'n lewe van sy eie, breaking free of its creator’s expectations and rules. The technical evolution is obvious – the WSS 3.0 voorwerp model is ryker en meer kompleks as WSS 2.0, which was itself an improvement over earlier versions. The next version will no doubt show tremendous improvement over 3.0. From an End User’s perspective, egter, SharePoint se evolusie is selfs nog meer betekenisvol.

In die vroeë dae, SharePoint didn’t offer much to End Users. They would have their usual functionality requirements, work with IT to define them well and implement a solution. IT would use SharePoint to solve the problem. The product wasn’t very accessible to End Users. I’ve thought threw a few analogies, but I decided to stick Venn Diagrams to show what I mean. When Microsoft first released SharePoint to the world as a commercial offering, Dit volg op 'n betreklik tradisionele patroon van eindgebruiker <-> IT relationship. A lot of End Users, kommunikeer en werk met 'n baie klein aantal mense Dit oplossings vir probleme op te lewer:

Die algehele probleem domein waarvoor SharePoint is 'n geskikte aflewering platform is 'n klein (especially compared to today’s SharePoint. End Users and IT worked in a more classic arrangement with IT: definieer vereistes IT, wag vir dit doen nie hul werk agter die gordyn en neem lewering van die finale produk.

As SharePoint ontwikkel om die 2.0 wêreld (WSS 2.0 en SharePoint Portal Server), several things happened. Eerste, the “problem domain” increased in size. By problem domain, I mean the kinds of business problems for which SharePoint could be a viable solution. Byvoorbeeld, sou jy nie dink te hard oor die implementering van 'n ernstige soek oplossing in 'n SharePoint omgewing tot SPS (en selfs dan, dit was nie so goed soos dit nodig is om te wees). Op dieselfde tyd, Einde gebruikers het 'n ongekende vermoë om nie net te definieer, but also implement their own solutions with little or no IT support.

Die 3.0 platform (WSS en mos) maintained and increased that momentum. The problem domain is enormous as compared to the 2.0 platform. Virtually every department in a company, wat wissel van die vervaardiging van gesondheid en veiligheid departemente tot bemarking, uit verkope aan gehaltebeheer - hulle kan vind 'n goeie gebruik vir SharePoint (en dit is nie 'n geval van Mais Chen 'n ronde pen in 'n vierkantige gat). Op dieselfde tyd, the platform empowers even more End Users to implement their own business solutions. I try to capture that with this diagram:

This has proven to be both a potent and frustrating mixture. Die 3.0 platform turns previously stable roles on their heads. Suddenly, Einde gebruikers is effektief regter, jurie en laksman sake-ontleder, application architect and developer for their own business solutions. This gets to the heart of the problem I’m writing about. But before I dive into that, Kom ons kyk na die olifant in die kamer.

Loer na die Crystal Ball

Hoe sal SharePoint 2010 invloed op hierdie patroon? Will it be incremental or revolutionary? Will more, minder of ongeveer dieselfde aantal End gebruikers hulself bemagtig om oplossings te bou in SharePoint 2010? Will SharePoint 2010’s problem domain expand even further or will it just refine and streamline what it already offers in WSS 3.0 / MOSS?

Daar is genoeg inligting "daar buite" om veilig te sê dat die algemene antwoord is:

• The problem domain is going to dramatically expand.
• Einde gebruikers sal vind dat hulle selfs meer bemagtig as ooit tevore.

The Venn Diagram would be larger than this page and cause some IT Pros and CxO’s to reach for their Pepto.

I believe it’s going to be a tremendous opportunity for companies to do some truly transformational things.

Geen Bulls in China, My Shop!

Dit klink baie, maar uit my oogpunt as 'n SharePoint konsultant en om myself in die skoene van 'n IT-bestuurder, I see this vision. I own a China shop with beautiful plates, kristal, ens. (my SharePoint omgewing). I’ve rented a space, I’ve purchased my inventory and laid it all out the way I like it. I’m not quite ready to open, maar in afwagting, I look at the door to see if my customers are lining up and I notice an actual bull out there. I look more closely and I actually see twee bulls and even a wolf. Then I notice that there are some sheep. Sheep are so slegte, maar hulle is dalk verbloem wolwe? I don’t want bulls in my china shop!

Dit raak erger! When I rented the space, I couldn’t believe how nice it was. Wide and open, geweldige geriewe, very reasonable price. Egter, nou is ek besef dat die wye oop ruimtes en die groot deur is net perfek grootte vir 'n bul te kom dwaal in en afval te lê na my China.

Ek is besig om hierdie beeld te ver, natuurlik. End Users are not bulls (die meeste van hulle, in elk geval) en IT-afdelings nie (of sekerlik moet nie) view their user community with that kind of suspicion. Egter, daar is hierdie soort van volmaakte botsing plaasvind reeds in die die 3.0 platform that I expect will only get worse in SP 2010. SharePoint already empowers and encourages End Users to define and implement their own solutions.

Dit is groot en al, maar die feit is dat dit nog 'n baie tegniese produk en nog steeds oproepe vir die aard van die kragtige besigheid vereistes analise, design and general planning and management that technical projects require to be successful. These are not the kind of skills that a lot of End Users have in their bag of tricks, especially when the focus is on a technical product like SharePoint.

I’ve given this a lot of thought over the last year or so and I don’t see any easy answer. It really boils down to education and training. I think that SP 2010 gaan die spel verander 'n bietjie en dit gaan om te speel anders en in slow motion as maatskappye uitrol hul SP 2010 oplossings oor 2010 and beyond. In order to succeed, End Users will need to transform themselves and get a little IT religion. They’ll need to learn a little bit about proper requirements
analysis. They will need some design documentation that clearly identifies business process workflow, byvoorbeeld. They need to understand fundamental concepts like CRUD (skep, werk en te verwyder), dev / toets / QA / prod omgewings en hoe om daardie infrastruktuur te gebruik om behoorlik ontplooi oplossings wat leef 'n lekker lang tyd en draai (nie breek) in reaksie op veranderinge in 'n organisasie.

In die komende weke, Ek is van plan om te probeer en 'n paar van my eie nuwe idees, sowel as skakel na die groot werk wat gedoen word deur baie ander skrywers (op www.endusersharepoint.com en elders) so that interested End Users can learn that old time IT religion. Keep tuned.

</einde>

Skryf in op my blog.

Volg my op Twitter http://www.twitter.com/pagalvin

[Let daarop: Hierdie artikel kruis-gepos word aan End User SharePoint hier: http://www.endusersharepoint.com/2009/09/09/sharepoint-a-case-study-in-ask-the-expert/]

Soms, wanneer jy werk as 'n konsultant (as 'n professie, of in 'n adviserende rol binne jou maatskappy), you find yourself living in an Onion story. The Onion has a series of articles called “Ask an [deskundige] oor ['n probleem]". This follows the famous “Dear Abby” format where a concerned person is asking for personal advice. The onion’s “expert”, egter, is so focused on his/her area of expertise and current problems that the expert ignores the question entirely and rambles on about his area of expertise. As consultants, we need to keep that in mind all the time and avoid falling into that trap. It’s classically described like this – “when you use a hammer all day long to solve your problems, everything starts to look like a nail.” We professional consultants are always on guard against that kind of thing, maar ons in aanraking kom met mense wat ernstig is professionele in hul eie rol, but are not consultants. They don’t have the same need or training to do otherwise.

Verlede week, Ek het geskryf oor een van my maatskappy se kliënte en 'n deurlopende projek we have to enable high quality collaboration between various eye doctors in the US and Canada performing clinical research on rare disease. In addition to leveraging core SharePoint features to enable that collaboration, we’re also working an expense submission and approval process. It’s complicated because we have so many actors:

• 'N handvol van individue op verskillende dokters se praktyke wat kan inskryf uitgawes op die lyn.
  • Daar is meer as 40 dokterspraktyke.
  • Op 'n sekere praktyke, Die dokter maak gebruik van die stelsel direk.
  • By baie van die praktyke, die dokter se personeel gebruik maak van die stelsel direk.
• 'N finansiële bestuurder (wat werk vir my direkte kliënt) wat die uitgawes resensies vir akkuraatheid en relevansie, goedkeuring of ontken hulle op organisatoriese vlak.
• A 3rd party accounts payable group. These people pay all of the bills for out client, not just bills coming out of the rare disease study.

The Accounts Payable group has been a challenge. Working with them yesterday reminded me of the Onion series. In my role as business consultant, Ek het verduidelik die behoefte om die rekeninge betaalbaar maatskappy:

• Kliniese studies webwerwe (dokterspraktyke) aangaan studie-verwante uitgawes.
• They log onto the “web site” and enter their expenses using an online form. In hierdie geval, the “web site” is hosted with SharePoint and the expenses are entered into an InfoPath form. Expense receipts are scanned, foto's en regstreeks aan die vorm.
• 'N outomatiese workflow proses poog om die goedkeuring van die toepaslike finansiële bestuurder.
• Jy, dear 3rd party AP company – please review and approve or deny this expense. I’ll send it to you any way that you want (binne perke).Op hierdie punt in die bespreking, I don’t really care how it needs to be bundled. I want to work with the AP group to understand what they need and want.

Toe ek verduidelik die behoefte, die 3rd party het 'n diep duik in hul interne Mumbo Jumbo lingo oor koste goedkeuring prosesse, Oracle kodes, vise-president handtekeninge, 90 dag beurt-arounds, ens.. And panic. I shouldn’t forget about the panic. One of the bed rock requirements of the consulting profession is to learn how to communicate with people like that who are themselves not trained or necessarily feel a need to do the same. Among other things, it’s one of the best parts of being a consultant. You get to enter a world populated with business people with completely different perspectives. I imagine it’s a little bit like entering the mind of a serial killer, behalwe dat jy nie verwoes die lewe ná die ervaring (though entering the mind of an AP manager isn’t a walk in the park 🙂 [Sien belangrike nota hieronder ***] ).

One of the great things about our technical world as SharePoint people is that we have ready-made answers to many of the very valid concerns that people such as my AP contact have. Is it secure? How do I know that the expense was properly vetted? Can I, as die finale betaler, sien al die besonderhede van die koste? How do I do that? What if I look at those details and don’t approve of them? Can I reject them? What happens if the organization changes and the original approver is no longer around? Can we easily change the process to reflect changes in the system? Kan ek weer hierdie uitgawe 'n jaar later, indien en wanneer ek geoudit en nodig het om die betaling te verdedig?

As SharePoint mense, we can see how to answer those questions. In my client’s case, ons antwoord hulle meer of minder soos hierdie:

• Path vorm te laat terreine hul uitgawes aan te teken en dit vir goedkeuring.
• Webwerwe kan terugkeer na die terrein van die status van hul koste verslag te sien op enige tyd.
• As belangrike gebeure plaasvind (bijv. die koste goedgekeur word en ingedien word vir betaling), die stelsel in kennis proaktief hulle per e-pos.
• Die stelsel stel die finansiële bestuurder van een keer 'n verslag ingedien vir goedkeuring.
• Finansiële bestuurder goedkeur of ontken die versoek.
• By goedkeuring, die koste is gebondel in 'n e-pos en gestuur word aan die 3rd party betaler organisasie.
• Die 3rd party betaler het al die inligting wat hulle nodig het om die koste te hersien en kan die SharePoint omgewing toegang te grawe in die details (hoofsaaklik oudit geskiedenis van die "waarheid" van die uitgawes te kontroleer).
• 3rd party payer can approve or reject the payment using their own internal process. They record that outcome back in the SharePoint site (wat snellers 'n e-pos aan geskikte mense).
• In die toekoms, dit sal lekker wees om te sny uit die kalm e-proses en in plaas daarvan voer die koste inligting direk in hul stelsel.

Ter afsluiting, daar is 'n lewe styl hier dat ek beskryf van die professionele konsultant se oogpunt, but which applies almost equally to full time employees in a BA and/or power user role. Work patiently with the experts in your company and extract the core business requirements as best you can. With a deep understanding of SharePoint features and functions to draw upon, meer dikwels as nie, jy sal in staat wees om kommer te beantwoord en maniere om almal se werk dag gebruik te maak van kern SharePoint funksies te verbeter bied.

***Belangrike nota: I really don’t mean to compare AP people to serial killers. Egter, I could probably name some AP pro’s who have probably wished they could get a restraining order against me stalking them and asking over and over again. “Where’s my check?” “Where’s my check?” “Where’s my check?"

</einde>

Skryf in op my blog.

Volg my op Twitter http://www.twitter.com/pagalvin

[Let daarop: hierdie blog post is oor gepos op Mark Miller se webwerf hier: http://www.endusersharepoint.com/?p = 1897]

Een van my maatskappy se meer ongewone kliënte is 'n New York City dokter wat is 'n leier in sy bepaalde gebied van medisyne (oogsorg). Like many doctors, he has a strong interest in research. He wanted to do some research on a rare eye disorder that affects a relatively small number of people in the U.S. and Canada. I don’t know the number, but it’s really too small for a large pharmaceutical company to invest its own private funds with an eye toward eventual commercial success. I’m sure large pharma’s do some amount of research into rare diseases, maar ek glo dat die U.S. government is probably the largest source of funding. Soos enigiets, resources are scarce. Many doctors across the country want to perform research and trials. As 'n gevolg, there’s more than a little competition for that government funding. This is where my company and SharePoint enter the picture.

The fundamental idea is that a master organization will recruit other doctors across the country and enlist those doctors’ practices in a particular research study. These individual practices must sign up with the master organization and then, daarna, sign up for a particular study. The relationships look like this:

• 'N meester organisasie.
• Baie verskillende dokter se praktyke teken met die meester organisasie.
• The master organization obtains funding for individual studies. At the outset, Daar is net die een studie oor 'n spesifieke seldsame oogsiekte hoewel ons reeds die aanloop tot 'n ander studie.
• Individual doctors’ practices sign up for specific studies. A specific practice could sign up for one or multiple studies.

Die meester organisasie self afgebreek word in groepe:

• Uitvoerende komitee
• Bestuurskomitee
• Individuele studie komitees
• Administrasie
• ander

Ten slotte, wanneer 'n spesifieke dokter se praktyk tekens aan om deel te neem in 'n studie, wat hulle nodig het om professionele bied 'n verskeidenheid van rolle te vervul:

• Ondersoekbeamptes (insluitend 'n primêre ondersoeker, gewoonlik 'n dokter, saam met een of meer bykomende ondersoekbeamptes)
• Koördineerders
• Tegnici
• Toelaes administrateurs
• ander

The above roles have very specific and highly proscribed roles that vary by study. I won’t get into more detail here, maar as jy belangstel, los 'n kommentaar of email my.

En nou kan ek die vraag beantwoord, SharePoint - Wat is dit goed vir? The answer – it’s really good for this scenario.

Dit intro is reeds langer as wat ek verwag, so ek sal die belangrike rol wat SharePoint speel in die oplossing en duik in die besonderhede op te som in 'n toekomstige artikel (as jy nie kan wag, email my of los 'n kommentaar en ek sal bly wees om te bespreek en dalk selfs probeer om 'n demonstrasie te doen). We are leveraging a wide array of SharePoint features to support this concept:

• Terreine vir komitees, individuele rolle (koördineerder webwerwe, ondersoeker webwerwe, ens.).
• Sekuriteit om seker te maak dat verskillende praktyke nie sien nie ander praktyke "data.
• InfoPath forms services for online form entry. This is a particularly big win. Gewoonlik, hierdie moeilike vorms gedruk, pos aan die praktyke, filled out and mailed back. The advantages to the online forms are obvious. They do introduce some complexities (lisensiëring en menslike) maar dis 'n ander storie.
• Uit die boks web dele, soos aankondigings (toe doen komitee [x] ontmoet?) en die vergadering werk ruimtes.
• Vorms gebaseerde verifikasie in kombinasie met 'n CodePlex instrument self-registrasie en wagwoord te verskaf vergeet funksies.
• Persoonlike lyste en lys vertoning vir sigbaarheid in die studie-aktiwiteite wat eenvoudig nie moontlik is nie met suiwer papier en potlood benaderings.

Met die uitsondering van die vorms gebaseerde verifikasie module en 'n handvol van Path vorms, hierdie projek is die gebruik van byna almal uit die box SharePoint funksie.

Voordat ek draai dit min-gevallestudie, Ek wil wys op iets baie belangrik - nie op by hierdie projek betrokke (Afgesien van my maatskappy natuurlik) has any idea that a thing called “SharePoint” is playing such a fundamental technical role. Nearly all of my end users view this as “the web site.” Our client values us because we’re solving their business problem. SharePoint is a great technical blob of goodness, maar gedoen wat reg, that’s irrelevant to end users. They need a problem solved, nie 'n wonderlike stukkie tegnologie.

</einde>

Skryf in op my blog.

Volg my op Twitter http://www.twitter.com/pagalvin

Of is dit net ek? I’ve received three or four calls at my house since late September looking for SharePoint work. I’m used to the email solicitations, but these phone calls are a little unnerving. I haven’t had an updated resume on a job site I(like Monster pr Dice) since almost two years ago exactly. And back then, my resume was all about BizTalk and MS CRM. That’s the only place my phone number appears on line anywhere, sover ek weet.

</einde>

Skryf in op my blog.

Volg my op Twitter http://www.twitter.com/pagalvin

Die sluitingsdatum gedink oor hierdie andersins dowwe artikel praat goed om probleme wat ons dikwels gesig in die tegniese gemeenskap:

"Such dreary developments, verwag met sekerheid, moet word filosofies gedra."

This puts me in mind of one of the presentations I gave at the SharePoint Best Practices conference last month. I was describing how to get "great" maatskappy se behoeftes en iemand in die gehoor gevra, in effek, what to do if circumstances are such that it’s impossible to get great requirements. Byvoorbeeld, 'n gegewe maatskappy se kultuur plaas dit in die voorkant van die vereistes versamelaar / sake-ontleder, preventing direct communication with end users. This is a serious impediment to obtaining great business requirements. My answer was "walk away." I’m not a big humorist, so I was surprised at how funny this was to the audience. Egter, I’m serious about this. If you can’t get good requirements, you can be certain that a dreary outcome will result. Who wants that? I’m a consultant, so dit is meer realistiese (alhoewel verskriklik pynlik en drastiese) for me to walk away. Egter, as jy verskans in 'n maatskappy en wil nie, Of kan nie, wegstap, George (for once 🙂 ) wys die pad.

</einde>

Skryf in op my blog.

Volg my op Twitter http://www.twitter.com/pagalvin

Hoe dikwels gebeur dit met jou gebeur? I’m sitting at my laptop, lees blogs, op forum plasings te reageer, 2 afskrifte van Visual Studio oop en na 'n ander bediener met sy eie Visual Studio VPN'd + 15 vensters ('n tipiese dag) en iemand met die naam Samantha (my vrou, glo) vertel my, "Ons is daar in 30 minute. Get dressed."

Ek kry in 'n dwaal, dwaal rondom die huis verward, kry in 'n motor en die volgende ding wat ek ken, Ek is by 'n partytjie met 'n bier in my hand en iemand my vra, "So, Wat doen jy vir 'n lewe?"

Hierdie gesprekke is nooit goed gaan.

Me: "Ahh … Ek is 'n oplossing argitek vir EMC."

Naamlose persoon: leë staar

Me: "Ek werk met 'n produk met die naam van SharePoint … dit is van Microsoft."

NP: "Aha! Ek het gehoor van daardie maatskappy! What is SharePoint?"

Me: "Umm … dit doen samewerking … mense dit gebruik om inligting te deel … Dit is 'n platform vir die bou van Besigheid Sol…"

NP: Oë glas.

Me: "Ek is 'n programmeerder."

NP: "Aha! I know people in my company that do programming! When I was in high school, Ek speel rond met die basiese."

En met daardie deel van die gesprek oor, ons wend ons tot iets makliker om oor te praat, soos politiek.

Enigeen sorg te beskryf hoe hulle dit hanteer?

</einde>

Skryf in op my blog.

Ek het al in klasse die afgelope twee weke en een ding wat lyk my is dat daar 'n baie bedagsaam, slim mense wat op SharePoint (as konsultante of IT-personeel) wat blog nie, Twitter, blyk bewus te wees van die openbare boodskap borde soos MSDN forum of SharePoint Universiteit, handhaaf Facebook of LinkedIn profiele, ens.. They are pure information consumers. Not bad, net interessant.

</einde>

Skryf in op my blog.

'N klomp jare gelede, my boss asked me to train some users on a product called Results. Results is an end user reporting tool. It’s roughly analogous to SQL Server Reporting Service or Crystal. Op die oomblik, dit is ontwerp om te hardloop op groen buise (bijv. Wyse 50 terminale) connected to a Unix box via telnet.

My default answer to any question that starts with "Can you … " is "Yes" en dit is waar al die moeilikheid begin.

Die kliënt is 'n chemiese maatskappy in die suide van Kalifornië en het net oor toegedraai 'n groot ERP implementering gebaseer op QAD se MFG/PRO. The implementation plan now called for training power end users on the Results product.

I wasn’t a big user of this tool and had certainly never trained anyone before. Egter, Ek het het 'n aantal ander opleiding klasse en was vinnig op my voete, so I was not too worried. Dennis, die werklike voltydse Resultate instrukteur, had given me his training material. As ons terugkyk op dit nou, it’s really quite absurd. I didn’t know the product well, had never been formally trained on it and had certainly never taught it. What business did I have training anyone on it?

Dinge om logistieke bemoeilik, I was asked to go and meet someone in Chicago as part of a pre-sales engagement along the way. The plan was to fly out of New Jersey, gaan na Chicago, meet for an hour with prospect and then continue on to California.

Wel, I got to Chicago and the sales guy on my team had made some mistake and never confirmed the meeting. So, I showed up and the prospect wasn’t there. Awesome. I pack up and leave and continue on to CA. Somewhere during this process, Ek vind dat die kliënt is minder as die leer 24 hours before my arrival that "Paul Galvin" word die onderrig van die klas, not Dennis. The client loves Dennis. They want to know "who is this Paul Galvin person?" "Why should we trust him?" "Why should we pay for him?" Dennis obviously didn’t subscribe to my "gee slegte nuus vroeg" philosophy. Awesome.

Ek kom op die lughawe en vir 'n paar ongelooflik dom rede, I had checked my luggage. I made it to LAX but my luggage did not. Vir my, verloor bagasie is 'n baie soos om deur die sewe stadiums van rou. Eventually I make it to the hotel, met geen bagasie, moeg, honger en die dra van my (deur die nou, baie opgefrommel) business suit. It takes a long time to travel from Newark — to O’Hare — aan 'n kliënt — terug na O'Hare — en uiteindelik na LAX.

Ek het uiteindelik vind myself sit in die hotel kamer, munching op 'n Snickers bar, exhausted and trying to drum up the energy to scan through the training material again so that I won’t look like a complete ass in front of the class. This was a bit of a low point for me at the time.

Ek wakker word die volgende dag, did my best to smooth out my suit so that I didn’t look like Willy Loman on a bad day and headed on over to the client. As is so often the case, in persoon sy was mooi, polite and very pleasant. This stood in stark contrast to her extremely angry emails/voicemails from the previous day. She leads me about 3 miles through building after building to a sectioned off area in a giant chemical warehouse where we will conduct the class for the next three days. Die 15 of 20 studente stadig vergader, most them still expecting Dennis.

Ek het altyd begin my opleiding klasse deur die instelling van myself, giving some background and writing my contact information on the white board. As I’m saying, "Good morning, my name is Paul Galvin", Ek skryf my naam, email and phone number up on the white board in big letters so that everyone can see it clearly. I address the fact that I’m replacing Dennis and I assure them that I am a suitable replacement, ens.. I have everyone briefly tell me their name and what they want to achieve out of the class so that I can tailor things to their specific requirements as I go along. The usual stuff.

We wrap that up and fire up the projector. I go to erase my contact info and … I had written it in permanent marker. I was so embarrassed. In my mind’s eye, dit lyk soos hierdie: There is this "Paul Galvin" persoon, last minute replacement for our beloved Dennis. He’s wearing a crumpled up business suit and unshaven. He has just written his name huge letters on our white board in permanente merker. What a sight!

Dit het alles geëindig gelukkig, egter. This was a chemical company, na al. A grizzled veteran employee pulled something off the shelf and, waarskynlik in die skending van die EPA regulasies, cleared the board. I managed to stay 1/2 day ahead of the class throughout the course and they gave me a good review in the end. This cemented my "pinch hitter" reputation at my company. My luggage arrived the first day, so ek was baie meer aanvaarbaar dae twee en drie.

Soos ek is die neem van die rooi oë terug by die huis, I was contemplating "lessons learned". There was plenty to contemplate. Communication is key. Tell clients about changes in plan. Don’t ever check your luggage at the airport if you can possibly avoid it. Bring spare "stuff" in case you do check your luggage and it doens’t make it. I think the most important lesson I learned, egter, was dit: altyd die toets van 'n merker in die onderste linkerhoek van 'n wit bord voor te skryf, in groot letters, "Paul Galvin".

</einde>

Due to some oddball United Airlines flights I took in the mid 90’s, Ek het op een of ander manier geëindig met 'n aanbod te transformeer "ongebruikte myl" into about a dozen free magazine subscriptions. Dit is hoe ek geëindig inskrywing wetenskaplike Amerikaanse tydskrif.

As sagteware / raadgewende mense, we encounter many difficult business requirements in our career. Most the time, we love meeting those requirements and in fact, it’s probably why we think this career is the best in the world. I occasionally wonder just what in the world would I have done with myself if I had been born at any other time in history. How terrible would it be to miss out on the kinds of work I get to do now, at this time and place in world history? Ek dink: pretty terrible.

Over the years, some of the requirements I’ve faced have been extremely challenging to meet. Complex SharePoint stuff, building web processing frameworks based on non-web-friendly technology, complex BizTalk orchestrations and the like. We can all (hopefully) kyk met trots terug op ons loopbaan en sê, "yeah, dit was 'n harde een om te los, maar in die einde het ek pwned dat sumbitch!" Beter nog, selfs meer interessant en pret uitdagings wag.

Ek persoonlik dink dat my CV, in hierdie verband, is redelik diep en ek is baie trots op dit (al weet ek my vrou sal nooit verstaan ​​1/20th van dit). But this week, Ek was die lees van 'n artikel oor die Large Hadron Collider in my Scientific American magazine and had one of those rare humbling moments where I realized that despite my "giant" status in sekere kringe of hoe diep dink ek my goed ondervinding, there are real giants in completely different worlds.

The people on the LHC team have some really thorny issues to manage. Consider the Moon. I don’t really think much about the Moon (though I’ve been very suspicious about it since I learned it’s slowing the Earth’s rotation, which can’t be a good thing for us Humans in the long term). Maar, the LHC team does have to worry. LHC’s measuring devices are so sensitive that they are affected by the Moon’s (Earth-rotation-slowing-and-eventually-killing-all-life) gravity. That’s a heck of a requirement to meet — produce correct measurements despite the Moon’s interference.

I was pondering that issue when I read this sentence: "The first level will receive and analyze data from only a subset of all the detector’s components, from which it can pick out promising events based on isolated factors such as whether an energetic muon was spotted flying out at a large angle from the beam axis." Really … ? I don’t play in that kind of sandbox and never will.

Volgende keer as ek uit met 'n paar vriende, Ek gaan 'n heildronk in te samel om die goeie mense wat op die LHC, hope they don’t successfully weigh the Higgs boson particle and curse the Moon. I suggest you do the same. It will be quite the toast 🙂

</einde>