Rýchle & Jednoduché: Vytvorenie priečinka a priradiť typ obsahu (Alebo, Majú vašich indikátory KPI a jesť príliš)

S cieľom obísť problém indikátora KPI Napísal som o tom tu., Robil nejaké testy a zistil, že KPI pracovať proti priečinky s meta dát rovnakým spôsobom, že pracujú proti dokumentov alebo zoznam položiek. Som dokázal to vytvorením nového typu obsahu založené na type obsahu priečinka a potom pridať niekoľko polí. Vytvoril niektoré ukazovatele a dokázal sám, že indikátory KPI fungovať podľa očakávania. To bola vítaná správa. Nie je to dokonalé, pretože vrták-down, dostanete od KPI proti priečinky nie je presne to, čo chcete. To nie je moc nevýhodou, v mojom prípade, pretože 1) koncoví užívatelia nepoznajú nič lepšieho a 2) Vrták-dole ide do priečinka. Oni kliknite na názov priečinka a v položke. Je to dve kliknutia nie jeden, čo nie je koniec sveta.

To plynuli pekne s prácou som robil. Som vytvoriť priečinok pre každý dokument, ktorý dostane nahrané. Toto je robené cez príjemca udalosti. V dôsledku, je to kúsok torte udržať nadradený priečinok meta dáta v synchronizáciu s KPI-riadený meta dáta zo súboru, sama o sebe, pretože práve prebieha inštalatérske. This allows me to have my KPI’s and eat them too 🙂

Som upravil príjemca udalosti pridať priečinok a potom nastaviť typ obsahu tejto novej zložky na môj vlastný typ obsahu KPI-priateľský. Tento kus kódu urobil trik:

 SPFolderCollection srcFolders = targetWeb.GetFolder("Dokumenty").Podpriečinky;
  SPFolder addedFolder = srcFolders.Add(vlastnosti.ListItem.ID.ToString());
  SPContentTypeId kpiCT = nové SPContentTypeId("0x0120002A666CAA9176DC4AA8CBAA9DC6B4039F");
  addedFolder.Item["Identifikáciu typu obsahu"] = kpiCT;
  addedFolder.Item.Update();

Ak chcete vyhľadať skutočný identifikáciu typu obsahu, Prístupná cez stránku nastavenia typu obsahu a skopírovať a vložiť to z adresy URL, ako je uvedené:

obrázok

</koniec>

Vyberajte môj blog!

Rýchle a jednoduché: Dostať SPFolder SPListItem príjemca udalosti

Nesnáším to priznať, ale som bojoval s týmto všetky deň. Moje udalosti prijímač potrebuje aktualizovať pole jeho nadradený priečinok. Toto trochu ukazuje, ako na to:

súkromné neplatné UpdateParentFolder(SPItemEventProperties vlastnosti)
{

SPFolder thisItemFolder = vlastnosti.ListItem.File.ParentFolder;
thisItemFolder.Item["Stav schválenia ZZ"] = "Dobrá správa, Všetci!";
thisItemFolder.Item.Update();


} // UpdateParentFolder

V tomto prípade, Ja pracujem s knižnicou dokumentov a vlastnosti sú posielané z ItemAdded udalosti.

Trik je, že nemôžete dostať SPFolder položky priamo zo samotnej položky (tj. vlastnosti.ListItem.Folder má hodnotu null). Namiesto toho, Prejdite k položke zoznamu priradený súbor a získať súbory v priečinku.

</koniec>

Vyberajte môj blog!

Technorati Tags:

Ešte ďalší príjemca udalosti ladiť trik

Som si istý, že nie som prvý, kto prišiel s týmto. Avšak, Nevšimol som si niekto zverejniť trik ako je tento, pretože som začal venovať osobitnú pozornosť spoločenstva vlani v júli. Takže, Som myslel, že to tento tip rýchly a jednoduchý ladenia.

I 'm working on udalosť prijímač, ktorý začal vytvárať túto chybu v 12 úľ:

Chyba pri načítaní a beh udalostí prijímač Conchango.xyzzyEventReceiver v xyzzy minového, Verzia = 1.0.0.0, Kultúra = neutrálne, PublicKeyToken = blahbalhbalh. Ďalšie informácie sú pod. : Odkaz na objekt nie je nastavený na inštanciu objektu.

Nevedel som, kde mal zaviesť túto chybu, pretože mal urobiť príliš veľa vecí v jeden môj kód/nasadiť/skúšobných cyklov.

Snažil som sa Toto riešenie získať moje PNR tam s nádejou, že SharePoint 12 úľ by Zobraziť trasovanie zásobníka, ale nie šťastie. Neviem, ak je to možné, a ak niekto nemá, Dajte mi prosím vedieť 🙂

Viem, že je možné Napíšte svoj vlastný denník správ 12 úľ. Úprimne povedané, Chcel som niečo trochu menej desivé a rýchlejšie na vykonávanie.

Napadlo ma, že som mohol aspoň dostať niektoré základné stopových informácie chytať a re-hádzanie všeobecných výnimiek takhle:

  skúste {
    UpdateEditionDate(vlastnosti);
  }
  chytiť (Exception e)
  {
    throw nové Exception("Dispečer, UpdateEditionDate(): Exception: [" + e.ToString() + "].");
  }

To ukázal v 12 thusly úľ:

Chyba pri načítaní a beh udalostí prijímač Conchango.xyzzyEventReceiver v xyzzy minového, Verzia = 1.0.0.0, Kultúra = neutrálne, PublicKeyToken = blahblahblah. Ďalšie informácie sú pod. : Dispečer, UpdateEditionDate(): Exception: [System.NullReferenceException: Odkaz na objekt nie je nastavený na inštanciu objektu. v Conchango.xyzzyManagementEventReceiver.UpdateEditionDate(SPItemEventProperties vlastnosti) v Conchango.xyzzyManagementEventReceiver.Dispatcher(SPItemEventProperties vlastnosti, Reťazec eventDescription)].

To mi dal všetky detaily som potreboval vypátrať tejto konkrétny problém a očakávam používať to veľa do budúcna.

</koniec>

Vyberajte môj blog!

Nedeľa Funny: “NIE NA VÝVOZ”

Späť okolo 1998, spoločnosť som pracoval v čase dostal časť finančných prostriedkov na vytvorenie nového elektronického výrobku. Mali sme plné spektrum obchodných požiadaviek na splnenie. To muselo byť rýchlo, ľahké pre koncových užívateľov, honosné, multi-jazyk, atď. Smutné, Asi som nemal ako ambicióznych práce dosiahnuť od tých opojné dni.

Toto úsilie pred dátumom Microsoft.NET. Rovina vanilka ASP bol stále niečo nové (alebo aspoň veľmi oboznámení s moju spoločnosť). "Tehál a Malty" spoločnosti boli odsúdené. Odsúdená! Jedná sa povedať, že to bolo priekopnícke práce. Hadrónový urýchľovač priekopnícku prácu, ale pre nás v našom malom svete, to bolo priekopnícke práce.

Sme blázon zaneprázdnený. Sme robili mini POC je takmer každý deň, zisťuje, ako sa zachovať stav v podstate príslušnosti médiu, zisťuje problémy s multi-jazyk, zabezpečenie na úrovni riadok. Dokonca mal vytvárame slovník definovať základné pojmy (Radšej štátu-perzistentné, ale z nejakého dôvodu, trápne statefull"" vyhral deň).

Ako sme boli šialene vymyšlený tohto výrobku, marketing a predaj ľudia boli sa snaží predať. Nejako, sa im podarilo predať náš scenár nočná mora. Aj keď sme boli navrhovaní a vykonávaní podnikové riešenie, naozaj nečakali sme prvý zákazník používať každý posledný prvok sme zabudované do výrobku deň nula. Tento zákazník potreboval multi-jazyk, radikálne odlišné užívateľské rozhranie z "štandard" systému, ale s rovnakým obchodnej logiky. Multi-jazyk bol obzvlášť ťažko v tomto prípade, pretože sme vždy zameraná na španielsky alebo francúzsky, ale v tomto prípade, to bol čínsky (ktorá je dvojbajtový znak set a vyžaduje osobitné zaobchádzanie vzhľadom na technológiu sme použili).

Rýchly posun vpred niekoľko mesiacov a som na Northwest airlines letu do Pekingu. Bol som tak zaneprázdnený prípravou tejto cesty, že som takmer žiadnu predstavu, čo to je ísť tam. Čítal som knihu kedysi, ako Američan bol v Číne za niekoľko rokov a naučil jazyk. Raz sa prechádzal mestom a požiadal niekoľko ľudí na cestu. Rozhovor šiel niečo to:

  • Americký: "Mohol by mi povedať, ako sa dostať do [XX] Ulica?"
  • čínština: "Prepáč, budeme nehovorí anglicky".
  • Americký: "Oh, No hovorím Mandarin." a spýtal sa ho znova v čínštine, ale jasnejšie (ako najlepšie mohol).
  • čínština: Veľmi slušne, "Prepáč, budeme nehovorí anglicky".

Rozhovor pokračoval takého kúsok a americkej vzdal vo frustrácii. Keď odchádzal, ako jeden človek hovorí k druhej, "Mohol som prisahal bol dotazem na cestu na [XX] Ulica."

Som zobral niekoľko bitov a kúsky iných kvázi informácie súvisiace s Čínou a "užitočné rady":

  • Kórejský spoločne pracovali mi povedal, že som potreboval byť opatrní čínskych, pretože "oni by pokúsiť sa dostať mi opitý a využiť vás" v zmysle tlačí ma do zlé obchodné rozhodnutia.
  • Sme nesmeli pohon auta (tam bol nejaký zmätok, či to bol zvyk, zákonnou požiadavkou alebo len klienta pravidlo).
  • Tam boli osobitné pravidlá pre prechod cez colnicu.
  • Sme nesmeli používať americkej peniaze za nič.
  • Ste nemal opustiť tipy. Je to urážlivé, ak si.

A napokon, Mal som pomerne čerstvé spomienky Tiananmen masaker. Keď som bol na vysokej škole, Spomínam, ako real-time Usenet príspevky ako svet prizerali hrôzou.

V skratke, Bol som veľmi nervózny. Nebol som len normálny-nervózny v tom zmysle, že bola dodávať riešenia, ktoré bolo rádov zložitejšie ako čokoľvek, čo kedy urobil pred. Bol som tiež obavy omylom rozbiť pravidlo, ktoré by ma do ťažkostí.

Ja som na to 14 hodiny letu a keď to bolo obchodné triedy, 14 hodiny je zatraceně dlho. Tam sú len toľko spôsobov, ako sa baviť sami čítaním, sledovanie filmov alebo hranie s magnetizované príbory. Aj naozaj dobrá kniha je ťažké prečítať na niekoľko hodín rovno.

Nakoniec, Začal som čítať obalového materiálu na kus softvér som ruka-niesol so sebou klientovi, Netscape webového servera. Som čítanie software a hardware požiadavky, uvedenie blurbs, pri pohľade na pekný obrázok a zrazu, Mám sústrediť sa na obrie "nie na vývoz" Upozornenie, niečo o 128 bit šifrovanie. Som späť do mojej tašky nosiť plnené poľa, Upozornenie lícom dolu (ako keby že by pomohli) a snažil sa držať vízie Polnočný Expres z mojej hlavy.

Ohliadnutie na to teraz, By boli strach, Ak vôbec, keď som opustil USA, not when I was entering China 🙂 Nothing untoward happened and I still consider that to be the best and most memorable business trip I’ve had the pleasure of making.

</koniec>

Vyberajte môj blog!

Technorati Tags: ,

Roztok: SPQuery neprehľadáva priečinky

Minulý týždeň som sa vykonáva "vyvíja" riešenie pre klienta, ktorý využíva BDC a SPQuery a narazil na niektoré problémy s používaním SPQuery proti knižnice dokumentov, ktorá obsahuje priečinky. Sečteno podtrženo: priradiť "rekurzívne" atribút zobrazenia dotazu.

Môj scenár:

  • V pondelok, Nahrať dokument a poskytnúť nejaké meta údaje.
  • Nasledujúci týždeň, Nahrať nový dokument. Moc tento nový dokument meta údajov vychádza z dokumentov, ktoré som nahral v pondelok (ktorú nazývame "nadradený dokument").
  • Sme vytvorili webovú službu fasádou, ktorá poskytuje BDC-priateľské rozhranie do zoznamu tak, aby užívatelia mohli ľahko vyhľadať pondelok dokumentu prostredníctvom vyhľadávania na názov.
  • Stĺpec údajov BDC poskytuje priateľské užívateľské rozhranie. (Toto je časť môjho pokusu pomocou BDC šetrnejší vyhľadávacieho stĺpca).

Konečné fasádu služba BDC používa dotaz ako to urobiť vyhľadávanie:

 // Použité U2U nástroj na pomoc pri vytváraní dotazu CAML.
      oQuery.Query =
        "<Kde>";

      Ak (titleFilter.Length > 0)
        oQuery.Query  =
          "  <A>";

      oQuery.Query  =
        "    <A>" +
        "      <GEQ>" +
        "        <FieldRef meno =  "DocumentId" />" +
        "        <Typ hodnoty =  "Text">" + minId + "</Hodnota>" +
        "      </GEQ>" +
        "      <LEQ>" +
        "        <FieldRef meno =  "DocumentId" />" +
        "        <Typ hodnoty =  "Text">" + maxId + "</Hodnota>" +
        "      </LEQ>" +
        "    </A>";

      Ak (titleFilter.Length > 0)
        oQuery.Query  =
          "    <Obsahuje>" +
          "      <FieldRef meno =  "Title" />" +
          "      <Typ hodnoty =  "Text">" + titleFilter + "</Hodnota>" +
          "    </Obsahuje>" +
          "  </A>";
      oQuery.Query  =
        "</Kde>";

V počiatočnej fáze vývoja, Táto skvelá pracoval. Avšak, sme zaviedli priečinky do adresára vyriešiť niektoré problémy a zrazu, môj výber BDC nechcel vrátiť žiadne výsledky. Sledoval som to tým, že SPQuery by sa nikdy nevráti žiadne výsledky. Použili sme priečinky predovšetkým umožniť viac súborov s rovnakým názvom byť nahraný, ale s rôznymi meta dáta. Keď sa súbor odovzdáva, vytvoríme priečinok na základe identifikácia položky zoznamu a potom premiestnite súbor tam (Napísal som o tom tu; mali sme zmiešané výsledky s týmto prístupom, ale na celom, to funguje dobre). Užívateľ nestarajú o priečinkoch a v skutočnosti, nechápe, že neexistujú žiadne priečinky. Sme nakonfigurovaný všetkých zobrazení knižnice na zobrazenie položiek bez ohľadu na priečinky.

Trafil som tento problém dvakrát ako technickú realizáciu vyvinul a vyriešil to inak zakaždým. Po prvýkrát, Nebol pomocou operátora obsahuje v dotaze. Bez toho, aby prevádzkovateľ obsahuje, Bol som schopný vyriešiť zadaním pohľad na SPQuery contructor. Namiesto použitia predvolený konštruktor:

SPList oList = web.Zoznamy["Dokumenty"];

SPQuery oQuery = nové SPQuery();

Namiesto toho použiť konštruktor uvedenej zobrazenie:

SPList oList = web.Zoznamy["Dokumenty"];

SPQuery oQuery = nové SPQuery(oList.Views["Všetky dokumenty"]);

Problém vyriešil a začal som sa dostať moje výsledky.

Následne sa pridá operátor obsahuje do mixu a to zlomil znova. Ukazuje sa, že obsahuje operátora, tak ďaleko, ako môžete povedať, nefunguje s názorom rovnakým spôsobom ako jednoduchšie GEQ / Prevádzkovatelia LEQ. Urobil nejaké vyhľadávanie a dozvedel, že atribúty zobrazenia dotazu by byť nastavená na "Rekurzívne", rovnako ako v:

oQuery.ViewAttributes = "Rozsah = "Recursive"";

Že problém vyriešil za obsahuje. v skutočnosti, to tiež môj pôvodný Hľadať problém vyriešený a ak mal špecifikovať rekurzívny atribút prvýkrát, Mám by nie bežať na otázku znova.

Skutočnosť, že view-založené SPQuery pracuje niekoľko prevádzkovateľov (GEQ/LEQ) a iné nie (OBSAHUJE), spolu s tým, že indikátory KPI nezdá sa pracovať vôbec priečinok obsahujúci dokument knižnice vedie mi veriť, že SPQuery má niektorí orthogonality problémy.

Osobitné poďakovanie:

  • Dobrý ľudí na U2U a nástroj ich dotazu.
  • Michael Hoffer veľký "učenie praxou" blogu, Komentáre a reakcie.

</koniec>

Vyberajte môj blog!

MOSS KPI chybu? Indikátorom zoznamu, ktoré sú viazané na knižnicu dokumentov s priečinkami

AKTUALIZÁCIA 02/29/08: Tento problém sa vyriešil vytvoriť priečinok a potom priradením určitého typu obsahu do priečinka, ktorý má meta dáta, ktoré potrebujem pre indikátory KPI. I ktoré popísaných v trochu podrobnejšie tu..

Zaviedli sme technické riešenie, kde užívatelia nahrať dokumenty do knižnice dokumentov. Príjemca udalostí vytvára adresár a presunie súbor do tohto adresára (použitím techniky podobné čo som napísal o tu). Sme úspešne prešli okolo potenciálne problémy spôsobené udalosť prijímače, ktoré premenovať nahrané súbory (hlavne preto, že používatelia nikdy spustiť ich dokumentu kliknutím na "nové" ale namiesto toho vytvoriť lokálne docs a potom nahrajte).

Meta data pre tieto dokumenty patria typu Yes/No stĺpec lokality s názvom "súrne" a ďalší stĺpec lokality s názvom "Stav". Musíme splniť obchodné požiadavky, aby sa zobrazuje percento "súrne" dokumenty, ktorých stav je "Až do".

To je zvyčajne jednoduché urobiť a já popísané niečo veľmi rád tento SharePoint Beagle s množstvom screenshotov if you're interested.

V skratke, Som urobil nasledujúce:

  • Vytvoriť zobrazenie v knižnici doc nazýva "Až do".
  • Konfigurovať pohľad ignorovať štruktúru priečinkov.
  • Vytvoriť zoznam indikátorov KPI.
  • Vytvorenie indikátora v zozname, ktorý poukazuje na doc lib a že "Čakajúce" zobrazenie.

To jednoducho nefunguje. Indikátor KPI ukazuje môj cieľ (napr.. päť urgentných písomností) ale vždy ukazuje skutočný počet naliehavých dokumentov ako nula. Paradoxne, Ak môžete zúžite podrobnosti, to ukazuje päť súrnych dokumentov v zozname. Som vytvoril veľmi jednoduchú scenár s dvoma dokumentmi, v priečinku a jeden nie. Tu je screen shot:

obrázok

Vyššie uvedený náhľad obrazovky jasne ukazuje, existujú dva dokumenty pohľadu však hodnotu"" je jedným. "CamlSchema" s prázdnym dokumentom Id je v koreňovom priečinku a druhá je v priečinku s názvom "84".

Zdá sa mi, že dokonca aj vtedy, keď určíte zobrazenie, indikátor KPI nemá cti "zobraziť všetky položky bez priečinkov" Nastavenie a namiesto, obmedzuje do koreňového priečinka.

Ak som zle, prosím kvapku mi čiary alebo zanechať komentár.

</koniec>

Vyberajte môj blog!

Technorati Tags:

JPD Workflow “Zozbieranie údajov od používateľa”: Upraviť formulára vytvorené úlohy

Som pracoval na projekte, ktorý používa päť rôznych pracovných tokov SharePoint Designer zvládnuť niektoré schválení dokument. SPD poskytuje "zhromažďovanie údajov od používateľa" akcie tak, aby sme môže používateľa vyzvať pre rôzne kúsky informácií,, ako napríklad, či schvália, niektoré komentáre a možno pýtať, čo mali na večeru v noci.

Formuláre sú dokonale funkčné. Sú viazané na zozname úloh ako typ obsahu. Sú 100% vygenerované systémom. To je ich sila a slabosť. Ak môžeme žiť s predvolený formulár, potom sme dobré ísť. Avšak, Nemáme príliš veľa kontrolu nad ako JPD vytvorí formulár. Ak sa nám nepáči, že predvolené správanie, Musíme sa uchýliť k rôzne triky sa dostať okolo neho (napríklad, Nastavenie priority na úlohu).

Potreboval som sa uviesť odkaz na tieto úlohy formuláre, ktoré otvoril Zobraziť vlastnosti (dispform.asxp) "súvisiace položky" v novom okne. To ponúka jeden-cvaknúť prístup k meta dáta súvisiace položky. Je to, čo mám na mysli:

obrázok

Našťastie, môžeme to urobiť, a nie je to veľmi ťažké. Všeobecne povedané, oheň SPD, Prejdite do adresára, ktorý domy toku súbory a otvorte ASPX súbor, ktorý chcete upraviť. Toto sú len klasické pokyny transformácie XSL a ak ste už výmeny, zložené s itemstyle.xsl, vyhľadávanie alebo iných scenárov XSL, to bude pre vás ľahké. v skutočnosti, Našiel som to je všeobecne ľahšie, pretože vygenerovaný formulár sa trochu ľahšie nasledovať v porovnaní s webovej časti základných výsledkov vyhľadávania (alebo strašidelný CWQP).

samozrejme, tam je jeden hlavný pascu. JPD je tok činností editora očakáva, že plnú kontrolu nad súboru. Ak si to zmeniť, SPD šťastne prepísať vaše zmeny dávajú právo stanoviť okolnosti. Urobil som dva rýchle testy, aby zistili, ako zlé to mohlo dostať. Obaja predpokladajú, že už vytvorený platné SPD pracovný postup, ktorý používa "zhromažďovanie údajov od používateľa" krok.

Test 1:

  • Ručne upraviť súbor ASPX.
  • Vyskúšať (Skontrolujte, či vaše zmeny boli riadne uložené a nenarušili nič).
  • Otvoriť pracovný postup a pridať nesúvisiace akciu (ako "denník História").
  • Uložiť pracovný postup.

Výsledok: V tomto prípade, SPD nie re-vytvoriť formulár.

Test 2:

  • To isté ako #1 s výnimkou priamo upraviť "zhromažďovanie údajov od používateľa" Akcia.

Výsledok: Re-vytvorí formulár od nuly, nadmernej-písanie zmeny.

Záverečné poznámky:

  • Aspoň dve opatrenia JPD vytvárať formuláre takhle: "Zhromaždiť údaje od používateľa" a "Priradiť položku". Obe tieto akcie’ formuláre je možné manuálne upraviť.
  • Som bol schopný vytvoriť môj odkaz na dispform.aspx, pretože, v tomto prípade, položka relate má vždy svoje ID vložené do príbuznej položky URL. Bol som schopný extrahovať, a potom budovať <a href> základe poskytnúť jeden-cvaknúť meta dát funkcie prístupu. Je nepravdepodobné, že vaša adresa URL takto toto pravidlo. Môžu existovať iné spôsoby, ako získať identifikátor súvisiacej položky, ale nemuseli cez most, tak neviem, či sa dostane na druhej strane priepasť.
  • I didn't vyšetrovať, ale já bych nemal byť prekvapený, keď tam je nejaký druh súboru 12 podregister, ktorý mohol zmeniť ovplyvniť ako JPD vytvára tieto predvolené formuláre (rovnako ako môžeme upraviť upozornenie šablóny).

</koniec>

Vyberajte môj blog!

Sú “Neznáma chyba” Správy naozaj lepšia ako zásobníka?

Bol čítanie Madhur na blogu o tom, ako aby zásobník stopových displeja a teraz som zvedavý: Prečo sme sa vždy show zásobníka?

Kto prišiel s tohto pravidla a prečo sme po nej?

Koncoví užívatelia vedieť, je niečo zle v oboch prípadoch. Aspoň s zásobníka, stlačením môžu kontrolou-printscreen, kopírovať/vložiť do e-mailu a odoslať ju na to. Ktoré by jasne znížiť čas a úsilie potrebné na vyriešenie problému.

</koniec>

Technorati Tags:

Nedeľa (Trápne) smiešny: “Moje meno je Paul Galvin”

Banda rokmi, môj šéf ma požiadal, aby vlak niektorí užívatelia na produkt s názvom výsledky. Výsledky je koncový používateľ podávanie správ nástrojom. Je to zhruba analogické SQL Server Reporting Service alebo kryštál. V čase, to bolo určené pre prevádzku na zelené rúrky (napr.. Wyse 50 terminál) pripojený k bloku Unix cez telnet.

Môj predvolenú odpoveď na akúkoľvek otázku, ktorá začína "môžete … " "áno" a to je miesto, kde všetky problémy začali.

Klient bol chemická spoločnosť, v južnej Kalifornii a mal len o zhrnula hlavných implementácii ERP na základe QAD je MFG/PRO. Realizačného plánu teraz vyzval školenia energie koncovým používateľom produktu výsledky.

Nebol veľký používateľ tento nástroj a vycvičil určite nikdy nikomu pred. Avšak, Uskutočnila celý rad iných školenia a bol rýchly na nohy, Takže som nebol príliš starosti. Dennis, skutočné denné výsledky inštruktor, mi dal jeho školiaci materiál. Ohliadnutie na to teraz, je to naozaj dosť absurdné. Nevedel som, že produkt aj, nikdy nebol formálne vycvičil na to a určite nikdy učil. Aký Biznis sa urobil majú vzdelávania niekto na to?

To komplikuje veci logisticky, Bol požiadaný ísť a stretnúť niekoho v Chicagu ako súčasť predpredajné angažmán na ceste. Plán bol lietať z New Jersey, Prejsť na Chicago, stretnúť na hodinu s vyhliadkou a potom pokračovať do Kalifornie.

Dobre, Som sa dostal do Chicaga a predaja chlap na môj tím urobil nejaký omyl a nikdy potvrdiť stretnutie. Takže, Ukázal som sa a vyhliadky tam nebol. Úžasné. Zbaliť a odísť a pokračujte CA. Niekde počas tohto procesu, Som zistil, že klient je učenie menej ako 24 hodín pred mojím príchodom že Paul Galvin"" uèí v triede, nie Dennis. Klient miluje Dennis. Chcú vedieť, "kto je táto osoba Paul Galvin?" "Prečo by sme mali veriť mu?" "Prečo by sme platiť za ním?" Dennis samozrejme nechcel prihlásiť sa k mojej "čoskoro dať zlé správy" filozofia. Úžasné.

Prídem na letisku a z nejakého dôvodu neuveriteľne hlúpe, Mal skontrolovať batožinu. Urobil som to na LAX, ale moja batožina nebola. Pre mňa, stráca Úschovňa je veľa rád prechádzal sedem etáp smútku. Nakoniec som sa v hoteli, s žiadnu batožinou, unavený, hlad a nosiť moje (Teraz, veľmi pokrčený) oblek. Trvá dlho cestovať z Newark — na O'Hare — klientovi — Späť na O'Hare — a nakoniec na LAX.

Konečne ocitám sedí v hotelovej izbe, žuvanie na snickers bar, vyčerpaný a snaží sa zohnať energie listovanie školiaci materiál znova tak, že nebude vyzerať ako úplný zadok pred triedou. To bolo trochu nízky bod pre mňa v čase.

Prebudil som sa druhý deň, mojich silách, aby vyhladiť môj oblek aby som nevyzeral ako Willy Loman na zlý deň, a zamierili cez klientovi. Ako je často prípad, osobne si prialo, zdvorilý a príjemný. To stál v ostrom kontraste k jej veľmi hnevá emaily/voicemails z predchádzajúceho dňa. Ona ma vedie 3 míľ cez budovu po stavebných s rozdelenou mimo oblasti obrie chemické skladu, kde budeme vykonávať triedy pre ďalšie tri dni. Na 15 alebo 20 študenti pomaly zhromažďovať, väčšine z nich ešte čaká Dennis.

Vždy som začať môj tréning triedy psi, dať nejaké pozadie a písanie mojej kontaktné informácie na bielu tabuľu. Ako som povedal:, "Dobré ráno, Moje meno je Paul Galvin", Píšem moje meno, e-mail a telefónne číslo nahor na bielu tabuľu veľkými písmenami, tak že všetci môžete vidieť jasne. Som vysporiadať so skutočnosťou, že som nahradil Dennis a uisťujem ich, že som vhodný náhradný, atď. Mám každý stručne povedať svoje meno, a to, čo chcú dosiahnuť mimo triedu tak, že môžete prispôsobiť veci na ich špecifické požiadavky, ako som ísť ďalej. Bežné veci.

Môžeme to zabaliť a oheň projektor. Idem vymazať svoje kontaktné údaje a … Som napísal v stálych marker. Bol som tak v rozpakoch. V mojej mysli oko, to vyzeralo takhle: Je to "Paul Galvin" osoba, Last minute nahradenie pre náš milovaný Dennis. Má na sebe pokrčený oblek a neoholený. Len napísal jeho meno veľkými písmenami na našej bielej palube v trvalé marker. Aký pohľad!

To všetko šťastne skončilo, Avšak. To bola chemická spoločnosť, napokon. A prešedivelý veterán zamestnancov vytiahol niečo z regálu a, pravdepodobne v rozpore s nariadeniami EPA, schválila Rada. Podarilo sa mi zostať 1/2 deň pred triedu v celom priebehu a dali mi dobrú recenziu na konci. Toto stmelil môjho štipka hitter"" povesť vo svojej firme. Moja batožina prišiel prvý deň, Takže som bol oveľa viac reprezentatívne dní dva a tri.

Ako bol pri červených očí späť domov, Bol uvažuje o "poučenie". Tam bolo veľa premýšľať. Komunikácia je kľúč. Povedať klientov o zmenách v pláne. Nikdy Nehľadať vašej batožiny na letisku, ak možno vyhnúť. Prineste voľné "veci" v prípade, že ste skontrolovať vaša batožina a to neznamená, že. Myslím, že najdôležitejšie lekcie som sa naučil, Avšak, bol to: vždy test marker v ľavom dolnom rohu bielu tabuľu pred písaním, veľkými písmenami, "Paul Galvin".

</koniec>

Technorati Tags: ,

Perspektívy: SharePoint vs. Veľký hadrónový urýchľovač

Kvôli nejaký podivín lety United Airlines som v polovici 90 rokov, Nejako som skončil s ponuky na premeniť "nevyužité km" do asi tucet zadarmo predplatné časopisu. To je, ako som skončil s prihlasovaním na časopis Scientific American.

Ako softvér / poradenstvo ľudí, stretávame veľa ťažké obchodné požiadavky našej kariéry. Väčšinu času, Milujeme spĺňajúce tieto požiadavky, a v skutočnosti, je to asi, prečo si myslíme, že túto kariéru je najlepší na svete. Občas vedel len to, čo na svete by som urobil sám ak som sa nenarodil kedykoľvek v histórii. Ako hrozné by bolo nechať ujsť na druhy práce mám teraz robiť, v tomto čase a mieste vo svetových dejinách? myslím: dosť hrozné.

V priebehu rokov, niektoré požiadavky, ktoré som čelila boli nesmierne náročné na splnenie. Komplexné služby SharePoint veci, Stavebné webové spracovanie rámcov na základe non-web-priateľské technológie, Komplex BizTalk orchestrations a podobne. Všetci môžeme (Dúfajme, že) hrdo obzrieť na našu kariéru a povedať, "áno, to bolo ťažké vyriešiť, ale nakoniec som pwned že sumbitch!" Ešte lepšie, ešte viac zaujímavé a zábavné úlohy čakajú.

Osobne si myslím, že môj životopis, v tejto súvislosti, je docela hlboký a som veľmi hrdý na to (aj keď viem, že moja žena nikdy nepochopím 1/20th to). Ale tento týždeň, Čítal som článok o Veľký hadrónový urýchľovač v mojom časopis Scientific American a mal jeden z tých vzácnych okamihov pokorujúceho, kde som si uvedomil že cez môj obor"" stav v určitých kruhoch alebo ako hlboká myslím moje dobre skúsenosti, tam sú skutočné gigantov v úplne odlišné svety.

Ľudia na LHC tímu majú niektoré naozaj pálčivé otázky riadiť. Za mesiac. Nemajú naozaj myslia veľa o mesiac (keď som bol veľmi podozrivý o to, pretože som sa naučil, je to spomalenie rotácie Zeme, ktoré nemôže byť dobrá vec pre nás ľudí v dlhodobom horizonte). ale, LHC tím mať strach. LHC je meracie prístroje sú tak citlivé, že sú ovplyvnené Moon (Earth-Rotation-slowing-and-eventually-Killing-all-Life) gravitácie. To je sakra požiadavka na splnenie — produkovať správne meranie cez mesiac rušenie.

Bol som premýšľal že problém keď som čítal túto vetu: "Prvý stupeň bude prijímať a analyzovanie údajov z iba podmnožinu všetkých detektor komponenty, z ktorých môžete vybrať von sľubné akcie na základe izolovaných faktory či mión energický bol videli lietania pod veľkým uhlom od osi lúča." naozaj … ? Nechcem hrať v tomto druhu sandbox a nikdy nebude.

Nabudúce som von s priateľmi, Budem zvýšiť prípitok na dobrých ľudí pracujúcich na LHC, Dúfam, že úspešne nebudú vážiť častice Higgsov bozón a prekliatie mesiac. Odporúčam vám urobiť to isté. It will be quite the toast 🙂

</koniec>

Technorati Tags: