.
Anmeldung | Registrieren | Hilfe

.NET-Blogs Archiv April 2015

Usefull NuGet Package: Units.Net

27.04.2015 13:49:01 | Jürgen Gutsch

Neulich bin ich bei meinen Spielereien mit dem Raspberry PI auf ein nützliches kleines NuGet Package gestoßen, mit dem sich diverse Einheiten relativ einfach berechnen lassen.

Units.Net

https://github.com/InitialForce/UnitsNet
https://www.nuget.org/packages/UnitsNet/

Units.Net liefert weitere Typen für diverse Maßeinheiten und entsprechende Umrechnungen an. Zum Beispiel der Typ Length für Entfernungen aller Art:

var distance = Length.FromCentimeters(120);

Erzeugt mit Zentimetern, liefert das Objekt Eigenschaften um die Distanz in Inches, Feet, Miles, Kilometern und auch Micrometern zu erhalten.

Analog unter anderem der Typ Temperature, mit dem man die Temperatur unter anderem in Einheiten wie Fahrenheit oder Kelvin erhalten kann:

var temperature = Temperature.FromDegreesCelsius(45);

Oder die Geschwindigkeit:

var speed = Speed.FromKilometersPerHour(25);
var knots = speed.Knots;

Insgesamt sind es sicher über 20 Typen auch zu elektrischen Einheiten, Vektoren oder z. b. Kräften. Wer also hierfür spezialisierte Typen haben möchte ist mit dieser Library gut bedient.

Für mich speziell interessant um auf dem RaspberryPI Bewegungs- und Entfernungs-Sensoren auszulesen und deren Werte zu verarbeiten.

Working with Git – Part 3: Custom Merge Tool

27.04.2015 00:44:00 | Jürgen Gutsch

Inhalt der Serie

Warum?

Standardmäßig kommt Git ohne ein wirklich geeignetes Merge-Tool. Man könnte zusätzlich TortoiseGit installieren und erhält etwas mehr Unterstützung. Auch das Visual Studio bietet einen nutzbaren Editor um Merge-Konflikte zu beheben.

Da ich mich mit Git aber eher in der Konsole bewege, genauer im Cmder, benötige ich ein Merge-Tool das bequem über die Kommandozeile aufrufbar ist. Zusätzlich habe ich mich an die dreigeteilte Merge-Ansicht gewöhnt, das mir zusätzlich zu meinem und dem Stand des zu mergenden Codes auch noch den ursprünglichen Zustand anzeigt.

Hier hat sich KDiff3 als sehr gutes Werkzeug erwiesen.

Installation

Um KDiff nach der Installation mit Git nutzen können muss es in der globalen Git Konfig registriert werden. Das kann man direkt in der globalen Konfig-Datei machen oder über die Git Config API

Die globale Git Konfig-Datei befindet sich im aktuellen User-Verzeichnis und hat den Namen .gitconfig (mit dem führenden Punkt) Diese Datei ist nun um zwei Einträge zu ergänzen:

[merge]
    tool = kdiff3
   
[mergetool "kdiff3"]
    cmd = \"C:\\\\Program Files\\\\KDiff3\\\\kdiff3\" $BASE $LOCAL $REMOTE -o $MERGED

Der erste Eintrag legt das zu nutzende Tool fest und der zweite den Pfad zur kdiff3.exe, sowie die zu übergebenden Parameter.

Über die Kommandozeilen API ist das etwas einfacher zu machen.

> git config --global --add merge.tool kdiff3
> git config --global --add mergetool.kdiff3.cmd "C:\\Program Files\\KDiff3\\kdiff3" $BASE $LOCAL $REMOTE -o $MERGED

Zur Kontrolle sollte noch git config --global --list aufgerufen werden, um zu sehen ob alle Einträge korrekt gesetzt worden sind.

Ein letzter Test ist der Aufruf von git mergetool:

01_GitMergetool

Benutzung

Die Benutzung ist dann relativ einfach: Sollte es trotz Feature Branches doch mal zu einem Konflikt kommen wird das in der Konsole angezeigt.

01_GitMergeConflict

Der Merge wird nicht committet und die Dateien mit Konflikten werden aufgelistet. Nun muss nur der Befehl “git mergetool” eingegeben werden und die KDiff3 GUI öffnet sich nachdem man die zu mergende Datei in der Konsole ausgewählt hat:

02_GitMergetool

03_s_Mergetool

Für diejenigen die ausschließlich mit SVN oder TFS arbeiten, ist das dreigeteilte Merge-Fenster möglicherweise ungewohnt. Mir allerdings hilft das beim vergleichen der verschiedenen Stände enorm.

Nun kann hier der Konflikt gelöst werden. Nach dem Klick auf Speichern kann das Fenster geschlossen werden. Sollten noch weitere Konflikte aufgetreten sein, kann nun die nächste Konflikt gelöst werden. Sind alle Konflikte gelöst, müssen die Änderungen nun committet werden. In Git wird dieser Commit – auch wenn er manuell vorgenommen wurde – als Merge-Commit gelistet. Dadurch wird er z. B. auf BitBucket leicht ausgegraut dargestellt.

Pedestrian pathfinding part 2: Collision detection

26.04.2015 17:40:00 | Daniel Springwald

I spent much time during the last weeks in programming the pedestrian pathfinding. After investing much work into the buggy implementation of evasion pathfinding algorithm and many hours of debugging now it seems to work.

Instead of the vehicle implementation (using Dijkstra pathfinding) for the pedestrian I use a jumpoint-pathfinding and a grid map. 

To prevent pedestrians from colliding with aother pedestrian, they mark their map pos as blocked (drawn red in the screenshot).



To synchronize between the vehicles and the pedestrians the vehicles project their actual position onto the pedestrian map (drawn black in the the screenshot). So no pedestrian can enter a field, a vehicle is driving across. 

Only for exceptional cases (when the blocking of the map has not prevented a collision) there is a front collider attached to each pedestrian.



Pathfinding seems to work fine now. So I can now go on with a little more exciting part of game development including graphic stuff and game mechanics.

Microsoft Speaker auf der ADC C++ 2015

22.04.2015 15:47:05 | Christian Binder

Die ADC C++ findet am 5 und 6.Mai statt. Von dem Microsoft C++  Team werden mit dabei sein:

Steve Carroll Visual C++ Team | Principal Group Software Engineering Manager
James McNellis Visual C++ Team | Senior Software Development Engineer

mit folgenden Sessions:

- Keynote: Microsoft Visual C++ Strategy
- What is new in Visual Studio 2015 
- Modernizing Legacy C++ Code
- Cross-platform development with C++ and Visual Studio 2015
- Graphics debugging in Visual Studio 2015

PS: Ich werde mit Gunter Logemann auch vor Ort sein. Gunter ist unser IoT und Windows (10) Spezialist und mein Thema ist ja ALM (TFS, VS, Git, TVCS usw.)  Ihr könnt uns am Microsoft Stand treffen und Eure Fragen mitbringen Smile

Chris

C++ and Windows Kernel Internals, Filter Driver and Debugging

22.04.2015 09:08:45 | Christian Binder

My friend T.Roy from CodeMachine, USA (http://codemachine.com), will be visiting Munich to present at the ADC++ conference in May 2015. He will be available during 6 - 8, May, to meet up and discuss the Windows training courses offered by CodeMachine as well as present an hour long brownbag seminar on cool debugging tips and tricks. You can reach him at contact@codemachine.com to schedule a meeting and presentation. Please note that the presentation will be in English.

If you are interested in such deep Dives I highly recommend to contact T.Roy Smile

Chris

Mein Technologieradar für 2015

22.04.2015 05:30:23 | Johnny Graber

Seit der Veröffentlichung meines ersten Technologieradars ist schon mehr als ein Jahr vergangen. Somit ist es höchste Zeit für einen Rückblick, ein Fazit und die Erstellung der nächsten Version.   Was brachte mir der Technologieradar? Der grösste Pluspunkt für mich war die erzwungene Fokussierung. Ein bewusstes Einteilen von verschiedenen Technologien in die einzelnen Ringe hat … Mein Technologieradar für 2015 weiterlesen

IT-Visions Infotag: Was bringen .NET 2015, Visual Studio 2015 und Windows 10 am 11. Mai 2015 in München

20.04.2015 20:22:45 | Andre Kraemer

Was sollte ich als Softwareentwickler in 2015 wissen? Diese Frage beantworte ich am 11. Mai 2015 gemeinsam mit meinen IT-Visions Kollegen Dr. Holger Schwichtenberg und FH-Prof. Manfred Steyer. Wir werden einen Überblick über .NET 4.6, .NET Core 5.0, Visual Studio 2015, Windows 10, AngularJS, Xamarin, Appache Cordova, ASP.NET MVC 6 und das Entity Framework 7 geben.

IT-Visions Infotag: Was bringen .NET 2015, Visual Studio 2015 und Windows 10 am 11. Mai 2015 in München

20.04.2015 20:22:45 | Andre Kraemer

Was sollte ich als Softwareentwickler in 2015 wissen? Diese Frage beantworte ich am 11. Mai 2015 gemeinsam mit meinen IT-Visions Kollegen Dr. Holger Schwichtenberg und FH-Prof. Manfred Steyer. Wir werden einen Überblick über .NET 4.6, .NET Core 5.0, Visual Studio 2015, Windows 10, AngularJS, Xamarin, Appache Cordova, ASP.NET MVC 6 und das Entity Framework 7 geben.

Am 23. März haben wir die gleiche Veranstaltung bereits in Essen durchgeführt und durften dort über 130 Teilnehmer begrüßen. Anbei ein paar Impressionen:

Manfred Steyer über AngularJS
André Krämer zeigt Windows 10
hs

Wer übrigens gerne selbst mehr über Windows 10, AnuglarJS, Xamarin, ASP.NET MVC 6, .NET Core 5.0 und das Entity Framework 7 erfahren möchte, der kann sich unter http://www.it-visions.de/produkte/vortragsdetails.aspx?v=8035 einen der noch Verfügbaren Plätze für den Infotag in München sichern

Working with Git – Part 2: Feature Branches

20.04.2015 00:40:00 | Jürgen Gutsch

Inhalt der Serie

Im letzten Teil habe ich meine Motivation beschrieben mit Git zu arbeiten. In diesem Teil Beschreibe ich wie man Effektiv und Sicher mit Git Arbeiten kann. “Sicher” heißt in diesem Fall sauber, agil und mit sehr wenigen Konflikten. Sicher heißt in diesem Fall auch annähernd fehlerfrei. In diesem Teil geht es darum isoliert in Feature-Branches zu arbeiten.

Wer täglich mit Git arbeitet und dabei bereits Freature-Branches anwendet, wird in diesem Blog-Artikel nichts neues erfahren. Ich schreibe das hier hauptsächlich für Leute die keine oder wenig Erfahrung mit Git haben und für Leute die Git wie SVN oder TFS verwenden, also historisch bedingt mit Commits und Branches eher sparsam umgehen.

Branchen geht schnell

Herkömmliche zentralisierte SCM haben alle den Nachteil, dass Branching relativ schwer oder aufwendig ist. In SVN und TFS wird für jeden Branch zumindest ein eigener Ordner angelegt, was ich für recht umständlich halte, zumindest beim häufigen Wechseln der Branches.

Diese Umstände führen dazu, das in zentralisierten SCM unvollständiger Code, unvollständige Features committet wird oder eben nur ein einziges Mal, wenn das Feature fertiggestellt ist. Allerdings sollte man so häufig wie möglich committen, um eine detaillierte Historie zu erhalten und um seine Arbeitsschritte besser nachvollziehen zu können. Ein weiterer Grund für häufiges committen ist die Größe des Change Sets. Je kleiner dieser ist, desto einfacher fällt das Mergen.

In Git und Mercurial ist das nicht der Fall. Der Wechsel der Branches findet immer im gleichen Ordern – dem sogenannten Workspace – statt. Aus .NET Sicht heißt das, ich kann die Branches innerhalb der gleichen Visual Studio Instanz wechseln. Der Wechsel der Branches passiert also sehr schnell und ich muss meine IDE, meinen Workspace nicht verlassen. Der Wille einen Branch zu erstellen ist größer.

Dieser Vorteil kann genutzt werden um mit Feature Branches zu arbeiten. Das heißt es wird für jedes Feature, das zu entwickeln ist ein eigener Branch angelegt und man kann nun isoliert in diesem Branch arbeiten und beliebig oft committen. Ich kann jederzeit in einen früheren Stand wechseln und von dort aus wieder einen eigenen Branch erstellen, wenn es sein muss. Ich kann einen Branch erstellen nur um etwas schnell zu testen und dann wieder zu verwerfen. Der Vorgang des Branchens selbst bei sehr großen Projekten dauert nur einen Bruchteil einer Sekunde.

Für jede Anforderung einen eigenen Branch zu erstellen, erscheint auf dem ersten Blick sicherlich etwas Übertrieben. Allerdings hilft das enorm den Code lauffähig zu halten. Feature Branches sind auch eine Voraussetzung für Pull Requests die ich in einem dritten Teil kurz vorstellen möchte.

Praxis

Hier möchte ich die Arbeit mit einem Pull Request kurz in einem gespielten Szenario anreißen:

Wir wechseln also als erstes in unseren Workspace.

01_OpenTheRepo

In diesem Workspace gibt es zwei Branches. Der eine ist der “master” der den fertigen, getesteten und abgenommenen Code enthält, der andere ist “dev” welcher der Entwicklungszweig ist. Hier kann unter umständen Code landen der fehlerhaft ist. Auf diesem Branch lauscht ein Build Server mit einem schnellen Continuous Integration Prozess, es wird also gebaut und die Unit Tests werden ausgeführt.

02_ListBranches

Aktuell befinden wir uns im master-Branch, wechseln wir also in den dev Branch, in dem sich aktuell eine HalloWelt.txt befindet. Das ist nun unser Source Code ;)

03_ChangeToDev

Wir haben nun die Anforderung einen neuen Abschnitt mit Infos über Feature Branches anzufügen. Die Anforderungen kommt in Form eines Tickets aus einem Tool wie TFS, Jira, Redmine, etc. Wenn ich einen Feature Branch erstelle habe ich mir angewöhnt meinen Username und einen Ticket Identifier als Branch-Name zu nutzen. In meinem Fall sieht das z. B. so aus: 
juergengutsch/HalloGit-1
<Username>/<Ticket Id>

Die Initialen vorne dran, helfen beim erkennen des Branch Erstellers in einer großen Liste von Feature Braches. Der Slash erzeugt z. B. im SourceTree eine Ordnerstruktur mit den Entwicklerkürzeln als Ordner und darin dann die Liste mit Branch-Namen, bestehend aus dem was nach dem Slash folgt. Diese Schreibweise sorgt also für mehr Übersicht.

Wir erstellen also unseren Branch und wechseln in diesen:

04_FirstFeatureBranch

Nun können wir die Datei öffnen und die Anforderung implementieren und abspeichern. Der Cmder zeigt nicht nur den aktuellen Branch an, in den wir uns befinden, sondern zeigt auch noch dessen Zustand. Rot bedeutet der Branch ist unsauber. Wir haben also Änderungen:

05_ChangedFile

Wir fügen die Änderung nun in unser Change Set ein und committen. Der Workspace ist nun wieder sauber:

06_ComitChanges

Wir möchten unsere Änderungen nun in den dev-Branch mergen. Was wir nun aber machen müssen um Merge-Fehler im dev zu vermeiden, ist diesen zuerst in unserem Feature Branch zu mergen.

Wir wechseln also in den dev-Branch und holen uns die aktuellen Änderungen vom entfernten Repository, schließlich könnte ein anderer Entwickler ebenfalls am Code gearbeitet haben:

07_PullDev

Wie wir nun sehen, gab es tatsächlich Änderungen. In der Historie können wir sehen was gemacht wurde. Nun wechseln wir wieder zurück in unseren Feature Branch und mergen die letzten Änderungen in den aktuellen Workspace. Sollte die Implementation des Features länger gehen, sollten wir immer wieder mal den letzten Stand aus dem dev-Branch in den Feature Branch holen.

08_MergeDev

An dieser Stelle müsste jetzt noch ein Review erfolgen. Das passiert bei uns in Form eines Pull Requests auf den ich im nächsten Teil eingehen möchte. Für den Pull Request müsste der aktuelle Feature Branch in das Remote Repository gepusht werden.

Wer der Merge erfolgreich, baut der Code lokal und laufen alle Tests lokal durch, können wir diesen Feature Branch nun nach dev mergen. Vorausgesetzt unser Feature ist fertig:

10_MergeToDev

Anschließend pushen wir diesen Stand in das Remote Repository:

11_PushToRemote

Wir können uns nun dem nächsten Feature widmen :)

Fazit

Was ich hier mit relativ viel Text und Bilder beschrieben habe ist im Alltag viel weniger Aufwand und ist in einigen Sekunden getan. Lediglich Merge-Konflikte – die Dank der Feature-Branches nur noch selten vorkommen – benötigen etwas mehr Aufmerksamkeit.

Für diesen Zweck ist die Konsole auch absolut ausreichend, da die paar Befehle die man hierbei anwendet schnell gelernt sind. Für alles weitere, was eher selten benötigt wird, kann man schnell das Netz konsultieren. Der Cmder ist für Git eine sehr gute Unterstützung.

Windows Phone 8.1: Mails und Anrufe

16.04.2015 20:49:28 | Hendrik Loesch

Für eine App brauchte ich eine Möglichkeit, dass der Nutzer direkt aus der App heraus Behörden anrufen oder ihnen eine Email schicken kann. Dabei war ich positiv begeistert wie einfach sich diese Funktionalität umsetzen lässt. Grundlage dafür ist immer der Namensraum Windows.ApplicationModel. Von diesem aus kann dann auf die Anruffunktion (Call), die Funktionalität für E-Mails […]

Pretzel – finished the Blog Migration

13.04.2015 01:11:05 | Jürgen Gutsch

Die Migration meines Blogs vom Community Server nach Pretzel ist nun technisch fast abgeschlossen.

Die größter Herausforderung bestand darin, die alten Beiträge sauber aus dem alten System in das neue Markdown-basierte System zu bringen. Auf Codeplex fand ich ein kleines Projekt, dass dafür da war, Blogs über die MetaWeblog PI in das BlogML Format zu exportieren (https://metaweblogtoblogml.codeplex.com/). Ich habe das Projekt nun so angepasst, das statt BlogML, der Output Markdown-Dateien sind die im Pretzel, bzw. Jekyll Format vorliegen (https://github.com/JuergenGutsch/MetaWeblog-To-Mardown-Converter). Da dieses Projekt nur einmalig zum Export verwendet wird, habe ich nicht auf sauberen Code geachtet.  Der Code enthält viele kleine Korrekturen die über einfaches String-Replacement gelöst sind. Zum Beispiel müssen Umlaute korrigiert werden. Auszeichnungen für Codebeispiele müssen von BB-Code ähnlicher Syntax nach Markdown übersetzt werden. Bildpfade müssen ggf. angepasst werden.

Für Codebeispiele kommt nun der clientseitiger Javascript Formatter highlight.js zum Einsatz. Pretzel ist bereits für diesen Formatter ausgelegt, das heißt der generierte HTML Code wird von highlight.js verarbeitet.

Nun müssen noch Bilder aus dem alten System in das neue geholt werden, neu verlinkt werden und der Export ist aus technischer Sicht fertig. Diesen Schritt werde ich nicht automatisieren können.

Nun folgt der aufwendigste Schritt:

Mein Blog ist recht gut Verlinkt und ich werden dafür sorgen müssen, dass die alten Links noch gehen. hier werde ich mich nun zwischen mehreren Möglichkeiten entscheiden müssen.

  • Ich nehme alle Artikel in das neuen Blog und ignoriere die alten Verlinkungen.
    • Solange Stefan Falz das alte Blog online hält existieren die Contents doppelt, wäre aus meiner Sicht kein großes Problem
    • Wenn Stefan meinen Blog löscht führen die alten Links ins leere.
  • Ich nehme nur die neuesten und alle zukünftigen Artikel in den neuen Blog auf. Mache also einen harten Break und starte mein Blog unter neuer URL neu.
    • Sobald Stefan aber mein Blog löscht, sind die alten Beiträge allerdings nicht mehr erreichbar.
    • Die Migration wäre fast umsonst gewesen.
  • Ich nehme alle Artikel in das neue Blog und Bitte Stefan eine Umleitung für mein Blog einzurichten.
    • Die Umleitung funktioniert auch nur so lange wie Stefan das alte System, bzw. den Server online lässt.
    • Alle Anfragen auf http://www.aspnetzone.de/blogs/juergengutsch/ müssten nun auf http://blog.gutsch-online.de/ gehen.
    • Ich müsste dann schauen, wie ich die weiteren Umleitungen der Artikel übernehme, da sich die Pfade auch leicht geändert haben.
    • Letzteres scheint mir das schwierigste, da der Blog auf https://pages.github.com/ gehostet wird und die Möglichkeiten dort nicht so umfangreich sind.

Die RSS Syndication ist kein Problem, da die RSS und Atom Feeds des Blog seit Jahren über Googles Feedburner läuft. Ich ändere also dort nur das Quell-Feed in der Feedburner Verwaltung. Die URL für alle Feed-Abonnenten ändert sich somit nicht.

Schwierig also. Mal sehen. Bis ich eine gute Lösung gefunden habe geht’s mal noch in diesem System weiter :)

Working with Git – Part 1

13.04.2015 01:01:00 | Jürgen Gutsch

Inhalt der Serie

Seit gut zwei Jahren arbeite ich nun fast ausschließlich mit Git, nachdem ich vorher mehrere Jahre mit Mercurial gearbeitet habe war der umstieg nicht allzu schwierig. Heute sind es noch einige alte private Projekte die mit Mercurial laufen. Migrieren möchte ich diese nicht. Warum auch? Mercurial ist genauso gut, für Einsteiger in die verteilten SCM sogar besser, das es eine einfachere API besitzt. Ein seit drei Jahren laufendes privates Projekt, basiert im Backend sogar auf Mercurial zur Sicherung, Versionierung und Verteilung von Daten.

Erst seit ich in Basel bei der YooApps arbeite, bin ich sowohl beruflich als auch privat auf Git umgestiegen. Fazit? Vom Prinzip keinen Unterschied. Wieso auch? Ich halte beide Systeme für gleichwertig. Git bietet lediglich mehr Möglichkeiten, wohingegen Mercurial wesentlich einfacher zu bedienen ist.

Soviel zur Einleitung. Was gibt es zu Kritisieren? Nur eines. Es gibt keine wirklich gute GUI für Git, so wie man es von Mercurial gewöhnt ist. Die hg Workbench ist ein einfach zu bedienendes und übersichtliches zentrales Werkzeug, mit dem man sogar gleichzeitig mehrere Repositories bedienen kann. Git kennt kein solches Werkzeug. Das was mit TortoiseGit mitgeliefert wird, sind mehrere einzelne unabhängige Werkzeuge, die eher umständlich zu bedienen sind. SourceTree von Attlassian kommt der hg Workbench recht nahe, hat sich aber als sehr träge und wesentlich unübersichtlicher herausgestellt. SourceTree habe ich mehrere Monate verwendet, nachdem es aber irgendwann bei großen Workspaces mit vielen Branches und vielen Dateien sehr schnell langsam wird, benutze ich es nun nicht mehr.

Über die Git Integration im Visual Studio habe ich mich bereits geäußert. Obwohl dieses nun wesentlich besser geworden ist, nutze ich SCM Integrationen im Visual Studio generell sehr ungern, weil diese nur das sehen, was das Visual Studio sieht. Das heißt alles was im Solution Explorer sichtbar ist, kann mit diesen integrierten SCM Werkzeugen behandelt werden. Alles was über das Dateiensystem direkt gemacht wird, wird von den Integrationen nicht gesehen. Das Gilt auch für den TFS und VisualSVN und ähnlichen Tools.

Das heißt es bleibt für Git nur die Konsole übrig, bzw. den Cmder. Das ist aus meiner Sicht eine der besten Konsolen, der nicht nur nützliche Linux-Befehle mit bringt, sondern eine Git Integration enthält, welche die Übersicht in der Konsole enorm steigert. Den Cmder nutze ich nun seit sehr langer Zeit als Git Client. Das beste an dieser Konsole, ist allerdings die Nutzung von Ctrl+V um Text, Pfade, Befehle, etc. direkt in die Konsole zu bringen. Die paar Git Befehle die man im Alltag verwendet sind relativ schnell verinnerlicht. Alles andere lässt sich schnell Googlen.


im Cmder wird immer der aktuelle Branch am Ende des aktuellen Ordners angezeigt, wenn es sich um einen Git-Workspace handelt.

Im folgenden Artikel möchte ich beschreiben wie Ich selber und wie wir bei der YooApps mit Git sehr erfolgreich arbeiten.

Repair of my cobra robot

11.04.2015 21:45:00 | Daniel Springwald

Last month I wanted to use my good old Cobra Robot for a new hobby project. 

I hadn´t used the robot for some months. When starting the control unit I noticed a smell like burnt electronics.

However, all functions of the robot still seemed to be working. But for safety reasons, it seemed advisable not to use the device.

Because my knowledge in electronics is limited I needed some help to find out what the exact problem was and how to repair it.

Fortunately, I had practical help of my good friend Jens and remote email support from the german cobra-robot guru Bernd Barnewald.

The first step was to check all voltages and fuses. All voltages seemed to be normal and stable, all fuses intact.

So all circuit boards had to be checked.

After some search we found a exploded buffer capacitor.

Jens said, these capacitors are well known problems: In the 1980s, the chemical quality of this type of capacitors was not as perfect as it is today.

So it seemed advisable to replace all these capacitors.

After assembling the robot was fully operational again.


7 Jahre MVP in Folge!

03.04.2015 10:23:00 | Lars Keller

Yes! Ich bin wieder Microsoft Most Valuable Professional (MVP) geworden und das nun das siebte Jahr in Folge! :-)

Sehr geehrte(r) Lars Keller,
herzlichen Glückwunsch! Wir freuen uns, Ihnen den Microsoft® MVP Award 2015 verleihen zu können! Diese Auszeichnung wird an herausragende, führende Mitglieder der technischen Communities verliehen, die ihre wertvollen praktischen Erfahrungen mit anderen Menschen teilen. Wir schätzen Ihren außerordentlich bedeutenden Beitrag in den technischen Communities zum Thema Windows Platform Development im vergangenen Jahr hoch ein.

Vielen Dank Microsoft dafür! Ich freue mich riesig ein Teil der Community zu sein. :-)

Die Zukunft von Team Foundation Server Version Control

02.04.2015 11:42:04 | Christian Binder

TFS unterstützt bekanntlich zwei Versions Control Systeme. Team Foundation Server Version Control als CVCS und Git als DVCS. In diesem Zusammenhang kommt immer wieder die Frage auf, ob TFVC nicht mehr weiterentwickelt wird. Die Antwort ist ein klares Nein. Brain Harry (CVP) hat dazu einen entsprechenden Post veröffentlicht, der hier Transparenz schafft und entsprechende falsche Gerüchte entkräften sollte. Die Kunden haben die Wahl, ob Sie CVCS Workflows oder DVCS Worklflows für Ihre Entwicklung nutzen möchten.

Chris

Regeln | Impressum