lilith2k3

Region: Niedersachsen Anmerkungi: Ich bin "noch" AzuBi (wie gesagt Beginn der Ausbildung war Februar letzten Jahres). Aber von Anfang an miteingespannt und selbständig Projekte abgewickelt; derzeit betreue ich nebenbei noch unseren Nachwuchs Fit (1 Bachelorant und 1 AzuBi). Betriebsgröße 200+ Achja: Keine Entwicklungsmöglichkeiten vorgesehen: weder Gehalt noch Position.

Kurz und schmerzlos: Ausbildung im Betrieb absolviert. Mitarbeiterbeurteilung (vor 3 Wochen): Zeugnisnote 1- Aufgabengebiet (im Groben): Alleiniger Support MSCRM (Angefangen von der Kundenberatung über Helpdesk bis hin zu Anpassung und Programmierung vollständiger Lösungen, Schnittstellen, Integrationslösungen) Installation, Wartung MSSQL. Installation, Anpassung, Wartung CTI-Lösung Gehalt: 24600€ p.a. Arbeitszeit: 40h + 4 inklusive Überstunden Urlaub: 25 Tage Alter: 35 Jahre Anmerkung: Ausbildung FIAE seit 02/2010 Projekte (Programmierung) abgewickelt seit etwa 05/2010. Da unser FISI aus der Abteilung weg ist, habe ich dessen Job übernommen und mache oben angegebene Tätigkeiten. Meine Antwort: nein. Wie schätzt Ihr das Angebot ein? Ist doch ein Witz? Vorallem bei der Mitarbeiterbeurteilung.

Defacto haben heute Switches Hubs abgelöst. Im Grunde hast Du heute im Heimbereich das Szenario, dass Du ein Kombigerät nutzt, wo dann Router- und Switchfunktion zusammen fallen. Interessant wäre es, wenn Du uns ein wenig mehr zur Infrastruktur verraten würdest.

Index(finger) ist der Zeigefinger. Ein Index zeigt etwas, bspw. eine Position, an.

Wenn Dein Chef fair ist, wird er auch keine ausprogrammierte Lösung verlangen - evtl. wird er aus allen Wolken fallen, wenn Du eine Lösung selbständig erarbeitest. Ich denke wichtig von Deiner Seite ist ein gewisses "Improvisationstalent": Du machst Dir Gedanken darüber, wie ein Programm formal aussehen müsste, wie der Ablauf aussehen müsste, etc. Wenn Du dann hingehst, Dein bisheriges Wissen zu Code verarbeitest und das Ganze Deinem Chef präsentierst, wird er mehr als zufrieden sein. Du zeigst ihm einerseits, was Du bisher schon in der Praxis kannst und andererseits, dass Du das Problem verstanden und eine Lösung erarbeitet hast. Wenn Du ihm dann erklärst: »Und dann müsste mein Programm diesdasundjenes, aber ich weiß nicht wie ich es umsetzen soll« wird er Dir schon anerkennend auf die Schulter klopfen. Vorallem ist in der Anfangszeit wichtig, nicht aufzugeben und Sitzfleisch zu zeigen. Ein Teil der Praktikanten scheidet allein schon von selbst deswegen aus, weil Sie zu früh aufgeben und nicht mehr wiederkommen. Desweiteren wird Dein Chef sich dafür interessieren, wie Du insgesamt mit der Aufgabe umgehst, also auch wissen, dass er Dich stresst und wissen wollen, wie Du unter Stress reagierst. Ich als Dein Praktikumsleiter würde Dir auch Aufgaben zuschustern, die Dich wahrscheinlich gnadenlos überfordern. Mich würde interessieren: 1) Kannst Du die Aufgabe lösen? Erwarten würde ich es natürlich nicht. 2) Wie gehst Du bei der Lösung vor: Fragst Du evtl. Mitarbeiter aus der Abteilung, ob Sie Dir helfen (=>Teamspirit) 3) Wie schnell kannst Du Tipps von Kollegen in Deine Arbeit einfließen lassen? 4) Erarbeitest Du eine theoretische Lösung, die Du praktisch nur nicht umsetzen kannst, weil Dir die Erfahrung fehlt? 5) Suchst Du eventuell nach schon vorhandenen Lösungen? etc. Wichtig wäre nicht die eigentliche Lösung, sondern Dein Weg dahin.

Ohne jetzt auf eine Diskussion über packet switching/circuit switching hinaus zu wollen, einigen wir uns auf PDU?

Plain simple: Hub - OSI 1 : Sowas wie ein Mehfachstecker an der Steckdose. Alle eingehenden Pakete über alle Ports raus Switch - OSI 2: Switched Pakete. Pakete je nach MAC über die entsprechenden Ports raus - nicht über alle. Router - OSI 3: Routet Pakete anhand der IP von A nach B.

Quatsch. Java läuft auf allen Plattformen für die es eine VM gibt; und für C# gilt das gleiche - cf. Mono unter Linux, bzw. unter Android. Im Übrigen ist Java wesentlich ungelenker in der Codierung. Wenn man seinen Code ordentlich schreibt benötigt man auch keinen Debugger. Debugger ist nur was für Leute, die Spaghetti-Code schreiben, oder sich im Spaghetti-Code fremder Programmierer bewegen müssen. Wer seinen Code sauber hält, ordentliche Unit-Tests schreibt benötigt keinen Debugger - wozu auch: der Test zeigt schon was, warum nicht funktioniert. Debugger sind was für Cowboys die gerne drauf los programmieren und sich nachher wundern, warum mal wieder nix läuft.

http://packages.ubuntu.com/

Ich verstehe gerade nicht, was Du meinst: Wenn ich eine Klasse habe, die einen 3-fach überladenen Konstruktor hat, und ich diese ableite: woher soll ein harmloses Snippet wissen, welchen der Konstruktoren Du nehmen möchtest?

Types Nein.

Da kann es an mehrerem hängen. 2GB sind wirklich Kinderquatsch. Wie Carsten schon sagte: Ohne intensive Analyse ist da schwer was raten.

Reflektion Aber vielleicht erklärst Du einmal genauer, was Du vorhast ...

Ctrl+.

TeamViewer: Fernwartung, Online Meeting und Fernzugriff - kostenlos für Privatnutzer Kann man für alles mögliche und Unmögliche benutzen ... Und sogar zum Dateitransfer

Ansonsten Jobqueue bauen wo die Jobs gequeued werden, wenn auf Objekt xyz ein lock liegt.

Cool. Von welchem Rollenspiel ist denn der Fertigkeitsbogen? Ich würde den empfehlen: http://www.google.de/url?sa=t&rct=j&q=shadowrun%20charakterbogen&source=web&cd=1&sqi=2&ved=0CCcQFjAA&url=http%3A%2F%2Fwww.unknown-online.de%2Fdaten%2FCharbogen-ausfuellbar.pdf&ei=Ltq4TtjhO4nYsgaW0oXiBg&usg=AFQjCNHhpu_i8etB-DICYi2pPcpaSBCNdQ&sig2=SHUg48Sqm2Epd533Skwugg&cad=rja

Der Unterschied ist zunächst sehr gering. Im Grunde geht es darum, verschiedene Objekte in gleichen Einsatzszenarien zu benutzen. Das Stichwort hierzu ist Polymorphismus. Polymorphismus besagt nichts anderes als, dass Du einen definierten rahmen vorgibst, den verschiedene Objekte ausfüllen können; oder anders: Polymorphismus erlaubt es Dir statt mit konkreten Objekten mit ganzen Gruppen von Objekten zu arbeiten. Nehmen wir das Beispiel der Logger. Dein Programm hat je nach Implementation zwei Ansprüche: 1) Wählst Du die klassenweise Vererbung (extends), erwartet Dein Programm ein Objekt vom Typ Logger oder alternativ ein Objekt aus der Familie (nenne ich es jetzt einmal) der Logger. 2) Wählst Du die interface Implementation erwartet Dein Programm ein beliebiges Objekt, welches die Fähigkeit Logging mit sich bringt. Soweit sehen sich die Arten der Vererbung recht ähnlich. Kommen wir zu den Unterschieden: * Mit der klassenweisen Vererbung schaffst Du die Möglichkeit eine Gruppe gleichartiger Objekte zu erschaffen - quasi: Objektfamilien. Die abgeleiteten Objekte erben von ihren Vorgängern alle Methoden die Public sind, sowie diejenigen, welche Protected sind. Du erhälst also ein Objekt, welches quasi schon Fähigkeiten mit sich bringt, ohne eine Zeile Code geschrieben zu haben. Ebenfalls werden die Attribute der Klasse, welche Public, bzw. Protected sind nach unten hin weitervererbt. Je nach Größe der Hierarchie kann das recht unübersichtlich werden. Bzw. manchmal ist es auch nicht gewünscht alle Variablen und Methoden in abgeleiteten Objekten zur Verfügung zu haben. Dann erweist sich die klassenweise Vererbung als ungünstig * Die Interfacevererbung bietet den Vorteil, dass Du Objekte verknüpfen kannst, die nichts gemein haben, außer dass sie ein gemeinsames Interface haben; also: eine gemeinsame Eigenschaft haben. Oftmals ist es genau das, was gewünscht ist: Man möchte nicht eine Reihe von verwandten Objekten behandeln, die einen gemeinsamen Stamm an Funktionen besitzen und darüber hinaus noch viele andere Funktionen besitzen, sondern oftmals hat man eine fest umrissene Anforderung, was das Objekt können soll. Diese wird fest im Interface definiert. Und alle Objekte, die genau die Fähigkeit besitzen können benutzt werden. Beispielsweise kann man eine Klasse Fortbewegungsmittel definieren, welche einen Antrieb benötigt. Der Antrieb soll die Kommandos Start und Stop beherrschen - das war's. Ob nun in das Fortbewegungsmittel ein Dieselmotor kommt, ein Raketenantrieb oder irgendeine Form des Antriebes, die wir nicht kennen, ist eigentlich egal. Hauptsache die Anforderungen werden erfüllt. * Modellierst Du Familien von Objekten kannst Du bequem neue Objekte mit neuen Funktionen hinzufügen, die die Elternobjekte noch nicht besaßen. Der Code muss nicht neu kompiliert werden. Du kannst die Objekte bequem austauschen * Bei Interfaces definierst Du eine feste Struktur - ändert sich diese Struktur, so müssen alle Klassen, die diese Struktur implementieren, neu geschrieben werden und der Code muss neu kompiliert werden. Daher eignen sich Interfacedefinitionen sehr gut für fest umrissene Schnittstellen - wie bspw. bei dem Logger-Interface. Wir haben von vornherein festgelegte Logging-Stufen, die sich voraussichtlich nicht mehr ändern werden. Also bietet es sich an, diese Struktur in einem Interface zu fixieren. Was nun die darunter fallenden Objekte bei dem Aufruf der jeweiligen Methode tun (oder lassen) bleibt ihnen überlassen. * Interfaces beinhalten keine Implementation: Die Methodenkörper müssen für die Objekte, welche die Methoden implementieren (neu) geschrieben werden. * Interfaces bieten sich an, bei fest umrissenen (abstrakten) Strukturen. Bspw. wenn ich es ermöglichen will, dass innerhalb meines Codes in irgendeiner Form Plugins ausgeführt werden sollen, bietet sich ein simples Interface Plugin an mit genau einer Methode: Execute(). Was sich dann dahinter verbirgt, soll mir als Entwickler gleich sein. So schafft man Strukturen, die einerseits fest gefügt (geschlossen) sind, da die Schnittstelle vorgefertigt ist; zum anderen, da die Details der Implementation offen gehalten werden ist unser Programm offen für Erweiterung; das nennt man auch das Open-Closed-Principle. Eines der wichtigsten Grundprinzipien der objektorientierten Programmierung.

Mich mit Studenten rumschlagen Ich betreue derzeit u.a. unseren Bacheloranten. Wie gesagt: Das Verhältnis von Praxisrelevanz und Studienrelevanz ist leider nicht 1:1. Das solltest Du tunlichst unterlassen. Sinnvoller ist es, sich erst in die Materie einzuarbeiten, die Dir angeboten wird und Dich später nach Lust und Fähigkeit zu spezialisieren. Wir haben derzeit eine Halbwertszeit für IT-Wissen von ca. 1.5 Jahren. Das heißt, das Du mit dem "Wissen" aus Deiner Ausbildung nur bedingt etwas anfangen kannst. Wichtiger ist die Kompetenz, auf dem Wissen aufzubauen, bzw. es selbständig erweitern zu können. Statt also zu fragen: »Ist das, was ich an der Hochschule lerne für mein Seelenheil notwendig?« solltest Du es einfach mitnehmen. Das, was später für die Praxis relevant ist, lernst Du auch da. Wie oben angesprochen betreue ich unseren Bacheloranten. Der kennt sich nicht oder nur mäßig mit C# aus. An der HS hat man eben Java gelehrt. Ist kein Beinbruch: Dafür hat er ja mich Hm. Da wirst Du nicht drum herum kommen. Ein soldies betriebswirtschaftliches Grundwissen gehört heute in allen Bereichen zum Handwerkszeug. Schließlich wollen wir ja Geld verdienen und unsere Betriebe mit uns Geld verdienen. Wer auf dem Auge blind ist, wird aussortiert.

Ich denke, Du solltest mein Beispiel nocheinmal durchlesen. In dem Beispiel ging es darum, dass ein Objekt Logging kann, also die Fähigkeit "Logging" implementiert; e.g. implementiert der Console Logger Logging: ConsoleLogger implements Logging Das ist der Inhalt des Beispiels.

public interface Logging { void Debug(String message); void Warning(String message); void Error(String message); void Info(String message); } class ConsoleLogger implements Logging { public void Debug(String message) { //Konsolenausgabe } ... } class EventLogger implements Logging { public void Debug(String message) { //Ausgabe in's Eventlog } ... } [/php] Später kannst Du dann folgendes tun: [php] class NeedsLogging { ... Logging logger; ... public NeedsLogging(Logging logger) { this.logger=logger; } } Ob Du nun einen ConsoleLogger oder einen EventLogger oder whatever injezierst ist der Klasse egal. Hauptsache, das übergebene Objekt erfüllt die Schnittstelle/Fähigkeit Logging.

Vererbung geschieht auf zweierlei Art und Weise (in Sprachen wie Java oder C#) durch Klassenvererbung oder durch Interfacevererbung. Es kommt immer darauf an, was Du modellieren willst. Willst Du eine Beziehung der Art A ist ein B modellieren wählst Du die Klassenvererbung. Ein Beispiel aus der Praxis wäre eine Klasse Logger. Man könnte verschiedene Arten von Loggern implementieren: File-Logger, Konsolen-Logger, Eventlogger, Datenbank-Logger. Insofern wäre es sinnvoll, zu bestimmen, was alle Logger können sollten. Daraus baust Du dann die (abstrakte) Basisklasse. Die davon abgeleiteten Methoden überschreiben dann die Methoden der Elternklasse. Willst Du etwas modellieren, was ausdrückt, dass A b kann, also die Fähigkeit besitzt etwas zu können, dann wählst Du die Interfacevererbung. Die Implementierung entscheidet dann das Verhalten. Auf unser Logger-Beispiel bezogen: Wenn wir uns die verschiedenen Logger-Arten vor Augen halten, so haben sie alle gemein, dass sie gewisse Loggingfähigkeiten voraussetzen. Diese kann man in einer Interfacedefinition festhalten und alle Objekte, die das entsprechende Interface implementieren, können untereinander ausgetauscht werden. Wenn ein Objekt beispielsweise den Anspruch hat, ein anderes Objekt zu empfangen, welches logging beherrscht, so ist es ihm piepschnurzegal, welches Objekt kommt und was das Objekt tut. Hauptsache das gewünschte Interface wird unterstützt. Je nach Anwendungsfall kannst Du das eine oder das andere Modell wählen.

Ich weiß nicht, was Du an Pascal auszusetzen hast. Pascal ist eine ausgezeichnete Lehrsprache. Welche Sprache wäre Dir denn lieber? Es geht darum, dass Du das Konzept "Programmieren" überhaupt erst einmal lernen sollst. Ob das eine "industrierelevante" Sprache ist, sollte Dich zunächst nicht stören. Ja. Am besten C#. C# ist in meinen Augen die modernste Programmiersprache, die mehrere Programmierparadigmen erlaubt (Du kannst funktional, objektorientiert und prozedural programmieren). Die Syntax ist recht aufgeräumt und übersichtlich. Du kannst zum einen mit microsofteigenen Tools entwickeln (Visual Studio 2010). Als Student kannst Du über den MSDNAA-Zugang eine Ultimate-Version des Visual Studios herunterladen und nutzen. Alternativ kannst Du auch mit einer freien IDE (Sharp Develop) entwickeln oder mit Mono sogar C#-Code unter Linux schreiben - so Du es denn einmal installierst. Aufgrund der Verbreitung von Windows ist es nicht unwahrscheinlich, dass Du nach Deinem Studium irgendwann evtl. etwas für Windows entwicklen solltest - insofern ist C# nicht verkehrt. Ergänzend empfehle ich eine dynamisch typisierte Sprache wie Ruby oder Python gesehen zu haben und wegen der Aktualität bzgl. Multithreading auch eine funktionale oder teilfunktionale Sprache wie Scala, F#, Haskell etc. Ja. Wissen tut nicht weh und schadet nicht. Insofern solltest Du auch mit anderen Betriebssystemen Kontakt haben. Am besten machst Du den Einstieg mit Ubuntu (CD rein, installieren, läuft). Oder wenn Dir tatsächlich nach Unix sein sollte und Du einen Websrever aufsetzen willst, schau Dir FreeBSD und das Konzept der "Jails" an - auch wenn das für den Anfang ein wenig viel sein sollte. Im Grunde ist es wumpe, was Du in Deinem Studium gelernt hast. Vieles von dem ist von akademischem Interesse und wäre interessant, wenn Du in der Forschung bliebest, bzw. in die Lehre einsteigen möchtest. Desweiteren hängt viel davon ab, was Du später für eine Position in einem Unternehmen einnehmen möchtest. Möchtest Du Dich eher in Richtung Consulting entwickeln, lohnt nicht die Mühe, dutzender Betriebssysteme und etlicher Programmiersprachen. Da reicht es, wenn Du Konzepte verstehen bzw. Dir nötiges Entscheidungswissen binnen kurzer Zeit aneignen kannst. Sinnvoller wäre es dann eher den Focus auf betriebswirtschaftliche Kompetenzen zu legen. Willst Du eher Richtung Softwarearchitektur gehen, lohnt es sich, sich in dieser Richtung weiterzubilden. Ein Studium bietet Dir die Möglichkeiten, Dich einzubringen, Dein Wissen nach Deinen Wünschen zu erweitern und zu vertiefen. Das geht allerdings nur dann, wenn Du reif bist und weißt, was Du willst und die Bereitschaft mitbringst, für Deine Ziele zu arbeiten. Von anderen vorgekaut zu bekommen, wie und was man im Studium machen sollte ist der falsche Ansatz. Als Informatiker solltest Du lernen, selbst zu denken, und nicht zum Nachbeter zu werden.

Vergiss den ganzen Kram und beschäftige Dich mit Download Details - Microsoft Download Center - Visual Studio Async CTP Unter der kommenden .NET-Version wird das alles ein wenig einfacher :] Ansonsten "Producer-Consumer" ist schon das richtige Pattern. class Producer { Container con; public void Execute() { Thread myThread = new Thread(()=>DoAction()); myThread.IsBackground = true; myThread.Start(); } public Producer(Container Con) { con = Con; } void DoAction() { Random rng = new Random(0); for (int i = 0; i < 10; i++) { Console.WriteLine("Producing {0}", i); lock (con.ContainerLock) { con.FertigeFirmen.Enqueue(System.Guid.NewGuid()); Monitor.Pulse(con.ContainerLock); } Thread.Sleep(rng.Next(2000)); } } } class Consumer { Container con; public void Execute() { Thread myThread = new Thread(() => DoAction()); myThread.IsBackground = true; myThread.Start(); } private void DoAction() { Random rng = new Random(1); for (int i = 0; i < 10; i++) { Console.WriteLine("Consuming {0}", i); lock (con.ContainerLock) { while (con.FertigeFirmen.Count==0) Monitor.Wait(con.ContainerLock); Console.WriteLine(con.FertigeFirmen.Dequeue()); } Thread.Sleep(rng.Next(3500)); } } public Consumer(Container Con) { con = Con; } } class Container { public Queue<Guid> FertigeFirmen = new Queue<Guid>(); public readonly object ContainerLock = new object(); } class Program { static void Main(string[] args) { Container container = new Container(); Producer producer = new Producer(container); Consumer consumer = new Consumer(container); Console.WriteLine("Start!"); producer.Execute(); consumer.Execute(); Console.ReadKey(); } } [/php] Mal so als Anregung. Wenn's ein wenig komplexer sein darf: NServiceBus - The most popular open-source service bus for .net zur asynchronen Kommunikation könnte interessant sein - kommt auf den Anwendungsfall an*g*

Das gleiche in anderer Schreibweise? Also auch vergleichbar mit char * Variable = NULL; Derjenige, der C++ gewohnt ist benutzt letztere und der C-Programmierer erstere Schreibweise. Genaugenommen handelt es sich nicht um eine Pointervariable vom Typ char sondern um eine Variable vom Typ Pointer auf char. Der Typ ist char*. Aber das nur für's Protokoll