PowerShell3

Hi…

Aus aktuellem Anlass mal ein paar Tipps zur Entwicklung von Modulen für PowerShell3:

(1) PowerShell3 ist Teil der  Windows Management Framework Beta und gibt es hier http://www.microsoft.com/en-us/download/details.aspx?id=28998

(2) Ein PowerShell3 Modul ist dann auch mal ein .net 4 Projekt (genauer eine DLL)

(3) Dem Projekt einen Verweis auf dieses Assembly einfügen: C:WindowsMicrosoft.NETassemblyGAC_MSILSystem.Management.Automationv4.0_3.0.0.0__31bf3856ad364e35System.Management.Automation.dll

(4) Zwecks Debugging habe ich die PowerShell.exe aus C:WindowsSystem32WindowsPowerShellv1.0 in mein bin Verzeichnis kopiert und folgende PowerShell.exe.config in das gleiche Verzeichnis gespeichert:

<?xml version =”1.0″?>

<configuration>

<runtime>

<loadFromRemoteSources enabled=”True” /> 

</runtime>

</configuration>

.net 4 hat ein verändertes Security-Model. Ohne dies bekommt man Fehler, wenn man import-module aufruft.

Dieser Artikel hätte mir mehrere Stunden rumsuchen erspart 😉

CU
0xff

NEXT impressions…

Hi…

ich war gerade auf der NEXT 2012 in Berlin. Eine extreme Erfahrung, eine ganz andere Sorte Developer wie die, die ich in Las Vegas kennenlernen durfte. Achtung, das ist keine Wertung!! Aber es sind total unterschiedliche Eigenschaften. WIE GEIL DIESE INDUSTRIE IST 😉

Witzig fand den Messestand der Telekom.

 

 

Oder den Zettel Kasten….

 

 

Welcome to the startup world 😉

CU

0xff

B2B2X – What the heck…??

Hi…

Genau so eine Email habe ich bekommen. Kaum hatte ich meinen neuen Titel eingetragen, bekam ich Glückwünsche und die Frage, was jetzt eigentlich B2B2X heißen solle. Gute Fragen verdienen gute Antworten.

Zugegeben der Begriff ist etwas sperrig. Aber ihr seid in besten Händen: Ich habe Physik studiert. Zunächst einmal zur Aussprache. Der Begriff muss englisch ausgesprochen werden, sonst gibt er keinen Sinn (OK, bisher habe ich noch kein „Aha“ von Euch erwartet). Dann lautet er „Be to Be to eX“. Nächste Überraschung: Be steht für Business. Jetzt wird es aber ernst.

Wir befinden uns in Software Ecosystems [1]. D.h. wir haben Endkunden im Consumer Bereich und im Business Bereich. Das X soll für Consumer oder Business stehen.

Eigentlich müsste der Begriff daher so aussehen:

Jede Zeile in diesem Vektor (das mehrzeilige Ding in geschweifter Klammer) steht für ein Ecosystem [2] [3]. Innerhalb dieser Ecosysteme gibt es die „App-Economy“ [4]. Also Entwickler von groß bis ganz allein, die Apps schreiben für Consumer oder Business. Die Telekom ist Teil dieser Ecosysteme, logischerweise als Telko; aber auch als App-Developer. Soweit ist das erst mal nix Neues.

Was könnte man aber jetzt diesen App-Developern noch Gutes tun (und das meint das erste B)?? Wir denken Dreierlei:

(1)    APIs. Die Telekom hat schon sehr lange eigene APIs veröffentlicht. Zu finden sind diese im Developer Garden. Schaut man sich das Angebot an, denkt man unweigerlich „Guter Anfang“. Ja, da gibt es viel mehr. Wahrscheinlich braucht es nur jemanden, der ein wenig kitzelt und eine entsprechende Plattform anbietet. Voila, unsere erste Aufgabe. Weiterhin sollte die Telekom aktiv an der Standardisierung von solchen APIs mitarbeiten. Ja, tun wir.

(2)    Code-Samples, Whitepapers, SDKs, fertige Klassen, kleine Beispiel-Apps – rund um das Thema, wie man diese APIs und anderes nutzt. Damit können wir es den Entwicklern so einfach wie möglich machen unsere APIs zu nutzen oder einfach generell Software zu entwickeln.

(3)    Business-Modelle. Derzeit werden viele verschiedene Modelle gehandelt: Werbe-Finanziert, Freemium, Lizenz, Marketing-App, Affiliate-Marketing… So richtig toll ist das Alles nicht. Man muss meist verschiedene kombinieren, um ein einigermaßen Auskommen zu haben. Einfach ist meist auch anders. Nun ja, da hätten wir auch ein paar Ideen.

So, macht jetzt B2B2X Sinn?? Wie die einzelnen Elemente in Realität aussehen, das erzähle ich ein andermal.

CU

0xff

Bezüge:

[1] D. Dhungana, I. Groher, and E. Schludermann, “Software ecosystems vs. natural ecosystems: learning from the ingenious mind of nature,” ECAS Conference, pp. 96-102, 2010.

[2] P. R.J. Campbell and F. Ahmed, “An Assessment of Mobile OS-Centric Ecosystems,” Journal of theoretical and applied electronic commerce research, vol. 6, no. 2, pp. 11-12, 2011.

[3] R. C. Basole and J. Karla, “Entwicklung von Mobile-Platform-Ecosystem-Strukturen und -Strategien,” Wirtschaftsinformatik, vol. 53, no. 5, pp. 301-311, Aug. 2011.

[4] D. MacMillan, P. Burrows, and S. E. Ante, “Inside the app economy,” Business Week, New York, pp. 2-7, 2010.

 

IMPACT 2012 in Las Vegas

Hi…

Ich komme gerade von der IMPACT 2012 aus Las Vegas. Es ist eine sehr große IBM Veranstaltung rund um Websphere (und da gibt es viel „Rund um“) – rund 8.500 Teilnehmer. Für mich war es seit Jahren mal wieder ein direktes Zusammentreffen mit „IT Heavy Industries“. Wow, ich habe Menschen von Walmart getroffen, die das zentrale Management der Registrierkassen machen. Oder die Kollegen, die das Backend-System von Delta-Airlines betreiben. Ein sehr interessanter Schlag von Menschen. Viele betreiben ihre Host-Systeme seit Jahrzehnten und können mit beeindruckenden Zahlen aufwarten. Und generell sieht man den PC auf der gleichen Stufe wie ein iPad. Klar, der Rock’n’Roll geht natürlich auf den Backend-Systemen ab.

IMPACT 2012 - Pass and ProgramAuch sehr cool war zu sehen, wie sie teilweise echte Designer-Maschinen dabei hatten. Mac Book Air, Ultra-Books, what so ever… sie haben das ganze Design dann genutzt eine Shell auf zu machen und ein wenig in der 1970er ASCII Metapher zu schwelgen. Die STRG Taste war immer ganz abgewetzt. Schon witzig, da hätte mein Uralt-Dell Studio eigentlich einen besseren Job gemacht.

Für mich sehr interessant war das Thema SOA versus RESTful. Schließlich arbeite ich jetzt als RESTful Service Provider (siehe die Developer Garden APIs der Telekom). Und ja, SOA war (noch) ein Thema und wurde viel diskutiert. Was nicht deutlich rauskam (wenigstens kam es mir so vor) war die Tatsache, dass so lustig RESTful ist, man sich damit einige Problemchen einhandelt.

Ein großer Teil des Overheads bei SOAP kam aus der Semantik, die man den Webservices mitgegeben hat. Bei REST ruft man eine API und bekommt irgendwas zurück. Was man da hat und wie man es weiter verarbeitet, liegt dann in der Aufgabe des Frontends. Da gab es dann best-practices zu sehen (Abruf eines Aktienwerts), der dann „13.54“ zurück geliefert hat. Schön. Ich gehe mal davon aus, es handelt sich um den Aktienkurs in Euro oder Dollar oder süd-bengalische Muschelscherben. Scheinbar eine Zahl (hoffentlich immer eine Zahl, weil meine Routine wahrscheinlich sich an Buchstaben verschlucken könnte). Wie aktuell ist der Kurs denn (aka Timestamp wäre cool). Und das sind nur meine Bedenken nach 20 Sekunde nachdenken… Die Semantik kommt dann per Code-Snippet und per Doku, die hoffentlich gut gelesen wird.

Äh, Einspruch, Euer Ehren. Ich hätte eine alternative Idee. Wir brauchen Komponenten, die einem dieses Plumbing abnehmen. Kleine Blackboxes, die ich einbinde und gut is‘. Was rauskommt ist im guten OO Sinne formatiert und fertig.

Nächster Gag: Batch-Processing. Wenn ich jetzt nicht nur einen Aktienkurs haben mag, sondern viele. Hoffen wir mal, dass der Programmierer sich dann der Batch-Routinen bedient und nicht einzelne Werte per Schleife. Man hat ja schon viel gesehen. Wieder könnten Komponenten helfen.

Oder: Asynchrone Aufrufe. Geht ja alles, wenn man es kann und hoffentlich richtig macht. Sicherheit nächstes Thema.

Es gibt also viel worauf jeweils eine Seite bei der API Entwicklung bzw Verwendung achten müssen. Fertige high-level Komponenten helfen…nur wo her bekommen???

Schlussendlich: Sehr interessant zu sehen, dass IBM mit einigen Produkten das Thema OpenAPI ernst nimmt und angehen will.

CU

0xff