Zum Inhalt springen
View in the app

A better way to browse. Learn more.

Fachinformatiker.de

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Whiz-zarD

User
  • Registriert

  • Letzter Besuch

Alle Beiträge von Whiz-zarD

  1. Eine Binäre Uhr von The One
  2. mmh, irgendwie macht die ganze Berechnung keinen Sinn. Das müsste doch: verbrauch = liter / km * 100 heißen.
  3. Whiz-zarD hat auf einen Beitrag in einem Thema geantwortet in .NET
    In Fachkreisen munkelt man, dass ASP.Net MVC in den kommenden Jahren tot sein wird. Der Grund ist, dass inzwischen immer mehr sog. Single-Page Application (SPA) entwickelt werden. Das generieren des HTML-Dokumentes übernimmt dann nicht mehr der Server, sondern der Client, weil die Clients immer Leistungsstärker werden und somit den Server entlasten. Angenommen wir haben eine Webseite, die pro Stunde von 10.000 Nutzern aufgerufen wird. Da ist es für den Server schon eine Belastung, wenn er für alle 10.000 Nutzern noch das HTML-Dokument generieren muss. Bei SPA wird nur ein HTML-Dokument an den Client geschickt und der Client aktualisiert den Inhalt mittels AJAX und WebAPI-Aufrufe selber. Das bedeutet, dass der Server nur noch JSON-Dateien zum Client schicken muss und man somit den Server entlastet. Frameworks für SPA-Anwendungen sind z.B. AngularJS oder Aurelia. Xamarin ist aber nicht dafür da, um ASP.Net MVC-Anwendungen zu bauen, sondern Mobile-Apps. Mit Hilfe von Xamarin kann für die unterschiedlichen Plattformen (iOS, Android und Windows) einen gemeinsamen Code schreiben und für die jeweilige Plattform kompilieren (für iOS benötigt man weiterhin ein Mac). Xamarin übernimmt auch das Look-and-Feel der einzelnen Systeme. So generiert Xamarin z.B. schon automatisch den Zurück-Button in iOS, während dieser Button in Android schon im System vorhanden ist. Auch werden weiterhin die einzelnen Bedienelemente für die jeweilige Zielplattform angepasst.
  4. Hinweis 1: arbeite bei wahrungsbeträgen nie mit double! C# bietet dafür den decimal-datentyp. Hinweis 2: schreibe nie die Logik in der UI! Das macht die Logik untestbar und falls du mal die UI tauschen möchtehst, musst du die Logik noch mal implementieren.
  5. Wenn ich schon so was lese, könnte ich kotzen. Aber gut. Offenbar richtet sich diese App an 14- bis 18-Jährige. Da mögen solche Begriffe noch Hip und Cool sein aber für einen über 30-jährigen sind solche Begriffe einfach nur noch peinlich.
  6. Mmh, okay. Ich bin eher davon ausgegangen, dass er den string noch weiter analysieren wollte.
  7. Das kann man vielleicht mit einem FISI machen, aber bei einem FIAE würde ich das nicht unbedingt tun. Auf unsere Software würde ich ihn nicht gleich loslassen. Schon gar nicht, wenn er nur wenig bis gar keine Programmierkenntnisse hat. Das wird ihn nur versauen, weil die Software echt gruselig entwickelt wurde und so gegen alle best practices verstößt, die man sich so vorstellen kann. Ich bin zwar kein Ausbilder aber bei einem FIAEler würde ich tatsächlich erst mal mit etwas spielerischem Anfangen, wie z.B. ein Sudoku-Löser oder ein Taschenrechner (ein guter Taschenrechner ist gar nicht mal so simpel) oder ein paar Coding-Katas und ihm dabei auch ein paar grundlegende Dinge beibringen, wie z.B. Variablentypen und die Probleme bei Fließkomma-Operationen und wie man ein Geldbetrag abbilden sollte, dann Design Patterns, Unittests etc. und erst dann, wenn er es so einigermaßen drauf hat, kann man ihn ja mal ein paar leichte Aufgaben aus dem Tagesgeschäft geben und ihn dann weiter betreuen.
  8. Dein Code ist schon recht komplex. Ein Problem hierbei ist schon, dass NewLine-Steuerkommando Systemabhängig ist. Unter Windows \r\n ist standardmäßig und unter Linux ist der Standard \n. Das lässt sich aber konfigurieren. Das .Net-Framework bietet hierzu die Enviroment.NewLine Konstante, die das aktuelle Newline-Kommando zurückliefert. Ich würde im ersten Schritt alle Text-Steuerkommandos entfernen: s = Regex.Replace(s, @"\t|\n|\r", " "); Dann würde ich den String in ein Array aufteilen: var array1 = s.Split(new[] { ' ' }, StringSplitOptions.RemoveEmptyEntries); Dann würde ich die beiden relevanten Ergebnisse extrahieren: var s2 = s1.Skip(Array.FindIndex(s1, x => x.ToLower() == "blato:") + 1).Take(2); und zum Schluss würde ich dann die Ergebnisse in ein String joinen: var result = string.Join(" ", s2); Und schon hat man mit vier Zeilen Code das Ergebnis und das ohne großartig reguläre Ausdrücke zu benutzen. Ich versuche sowieso reguläre Ausdrücke zu meiden, weil diese eh keine Sau versteht. Der gesamte Code: s = Regex.Replace(s, @"\t|\n|\r", " "); var s1 = s.Split(new[] { ' ' }, StringSplitOptions.RemoveEmptyEntries); var s2 = s1.Skip(Array.FindIndex(s1, x => x.ToLower() == "blato:") + 1).Take(2); var result = string.Join(" ", s2); Ist jetzt von der Variablenbenennung beschissen, aber ich hoffe, du kannst damit was anfangen.
  9. Klingt nach einem anderen Fehler. Die Funktion date_create_from_format() gibt dir ein Objekt zurück und kein String. Offenbar behandelst du irgendwo das Objekt als String und dann kommt es zur dieser Fehlermeldung. Bei der Ausgabe muss du die Format()-Funktion aus dem DateTime-Objekt benutzen. z.B. echo $datum->format('Y-m-d H:i:s')
  10. PDF-Dateien kann man auch so ohne weiteres nicht auslesen. Das ist ein recht komplexes Dateiformat mit einer eigenen Syntax zur Textgestaltung. Hier ist eine recht gute Übersicht, was die das Format funktioniert. Daher würde ich dir schon raten, eine Bibliothek dafür zu nehmen. Wir selbst erstellen nur Listen als PDF-Datei aber dafür verwenden wir List&Label von Combit. Das Tool ist aber nicht kostenlos. Ansonsten hast du ja schon einige Biblitoheken genannt, die du verwenden könntest. Etwas eigenes zu schreiben halte ich für zu fehleranfällig.
  11. Es wird ein Zeitplan auf Stundenebene erwartet und das spricht gegen die agile Entwicklung. Diese Zeitangaben ist auch eine einzige Mogelpackung, denn wer kontrolliert es und wer kann sich daran halten?
  12. TDD heißt nicht gleich, dass Agil gearbeitet wird. Agile Softwareentwicklung ist noch was anderes. Schaut man sich das "Agile Manifesto" an, so findet man folgende Leitsätze (kopiert aus Wikipedia): Menschen und Interaktionen stehen über Prozessen und Werkzeugen Funktionierende Software steht über einer umfassenden Dokumentation Zusammenarbeit mit dem Kunden steht über der Vertragsverhandlung Reagieren auf Veränderung steht über dem Befolgen eines Plans Und das widerspricht so allem, was die IHK von der Abschlussprüfung erwartet. Aber gut, da rege ich mich schon seit über 10 Jahren auf. Als ich damals meine Mechatroniker-Ausbildung absolviert hatte, musste ich sogar noch auf die Uhrzeit genau angeben, was ich mache ... Da ist es schon ein großer Fortschritt, dass man nur noch die Stunden angeben muss. Kanban muss aber auch nicht unbedingt agil sein. wenn z.B. bei Kanban nicht mit dem Kunden geredet wird, sondern stur die Aufgaben von "Bereit" bis "Fertig" abgearbeitet werden, haben wir hier ebenfalls ein Wasserfallmodell.
  13. Eine kleine Anekdote aus meinem Berufsleben: In der Software, an der ich arbeite, wurde damals in der Designphase (das war weit vor meiner Zeit) einen gravierenden Fehler gemacht und zwar hat man die Geschäftsobjekte direkt mit der Persistenzschicht verdrahtet. D.h. um ein Geschäftsobjekt erzeugen zu können, brauchst du zwingend eine Datenbankverbindung. Bei so einer Architektur im nachhinein Unittests zu schreiben ist unmöglich, da man anfangen müsste, die Datenbank zu mocken. Desweiteren wurde der Fehler gemacht, Geschäftslogik in die UI zu verlegen, weil das so schön einfach ist. Unter Visual Studio einfach ein Doppelklick auf dem Button im Designer und los gehts ... Schreibe aber mal dafür einen Unittest. Viel Spaß. Mit TDD umgeht man diese ganzen Probleme, weil man schon vornherein gezwungen wird, den Code so zu schreiben, sodass er auch Testbar ist. Ein weiteres Problem ist, wenn man die Unittests danach schreibt, dass man eigentlich nur noch die Schnittstellen nach außen testet und das reicht oft für ein Test nicht aus. Man sieht dann zwar, dass sich ein Ergebnis ändert hat, aber wo der neue Wert herkommt, sieht man nicht. Bei TDD geht es also darum, testbaren Code zu schreiben. Unittests Teste deine Klassen und die Methoden. Informiere dich mal über den Begriff "Testpyramide". Manuelle Tests gilt es zu vermeiden, weil die sehr zeitaufwendig sind und Zeit ist Geld. Hier in der Firma besteht der Regressionstest hauptsächlich aus manuellen Tests (die gründe stehen weiter oben) und der Test wird pro Major-Release mit 200 - 300 PT veranschlagt. Das ist enorm. Bei uns steht die Testpyramide auch auf dem Kopf und das ist das Worst-Case-Szenario. Manuelle Tests sind eigentlich nur noch UI-Tests und die testen nur noch den Workflow. Also dass z.B. wenn man auf Button X klickt auch Dialog Y auftaucht und dass Eingabefehler abgefangen wird aber auch diese Tests lassen sich automatisieren. Da gibt es genug Tools. Tests sollten immer durchgeführt werden, bevor es zum Kunden geht. Ansonsten hast du eine Bananen-Software: Reift beim Kunden. Aber ich persönlich sehe viele Probleme bei der Abschlussprüfung, wie die IHK es sich vorstellt. Das sind veraltete Methoden, die man heute nicht mehr anwenden sollte. Heutzutage versucht man den Kunden mit in die Entwicklung zu integrieren, sodass er für Fragen und Antworten bereitsteht und so kann man auch viel schneller auf Anpassungen reagieren (sprich agil arbeiten).
  14. Hast du auf dem Server alle Fehlermeldungen aktiviert? Vielleicht tritt dort ein Fehler auf und du siehst es nur nicht. Aber noch ein Hinweis: Vermeide SELECT *, denn das gibt zu viele Informationen zurück und kann auch zu Problemen führen, wenn man weitere Tabellen gejoint hat, die wiederum Spalten besitzen, die den selben Namen haben. Gib immer explizit an, welche Spalten du haben willst. In diesem Fall hast du sogar zwei Tabellen gejoint, also gibt dir die Abfrage die Spalten von drei Tabellen zurück. Je nach Anzahl der Recordsets kann es durchaus zu Performanceproblemen kommen.
  15. Unittests im Nachhinein zu entwickeln klappt meist auch nicht, da der Code dann der Code nicht testbar ist. TDD ist zwar anstrengend aber es ist durchaus hilfreich, denn TDD führt dich nicht in die Versuchung, den Code irgendwie hinzuhacken. Der Code bleibt dann immer testbar. Wenn man die Unittests erst hinterher schreiben will, hat man dann oft ein Code, der nur sehr schwer testbar ist. Dann testet man nur die Schnittstellen nach außen. Wenn aber dann ein Fehler auftauchen sollte, ist man da erst mal mit dem Suchen beschäftigt, wo der Fehler überhaupt herkommt und je nach Komplexität kann es sehr Zeitaufwendig sein. Ich kenne es auch eigener Erfahrung, dass man die Entwicklungskosten gerne niedrig halten möchte und daher gerne auf Unittests verzichtet werden, weil Unittests Geld kosten und von Unittests hat der Kunde nichts aber das Geld, was man hier investiert, spart man später bei der Pflege des Codes. Ich selber arbeite an einem unwartbaren Monstrum, wo die Entwickler an vielen Stellen im Code sich nicht rantrauen, weil sie nicht wissen, welche Seiteneffekte entstehen könnten, wenn sie was am Code ändern sollten. Der Analyseaufwand steigt somit ins unermessliche. Wenn aber schon vornherein dafür gesorgt wurde, dass vernünftige Unittests geschrieben worden sind, kann man bei Änderungen sehr schnell herausfinden, ob noch alles so läuft, wie vorher. Zeitdruck herrscht immer, denn Zeit ist Geld. Geld, was der Kunde nicht ausgeben will und ich weiß, dass es schwer sein kann, den Chef davon zu überzeugen, aber das ist einfach eine Milchmädchenrechnung, wenn man meint, dass man beim Sparen an Unittests grundsätzlich Geld spart, nur weil das Produkt schneller zum Kunden kommt. Die ganzen Bugs, die der Kunde meldet und der enorme Zeitanstieg bei der Beseitigung der Bugs oder bei der Implementierung von Weiterentwicklungen, sieht oft der Chef nicht. Also muss man ihn dies vor Augen führen, welche Folgekosten so etwas hat.
  16. Das hast du so gut wie in jedem Beruf und dennoch spricht man nicht gerade von einem "kaufmännischen Teil". Ein Kaufmann ist schon ein bisschen mehr, als Kosten- und Nutzen abzuwiegen.
  17. Such dir was aus und du hast deine Antwort... Also ist man sich eigentlich gar nicht im Klaren, was ein Anwendungsentwickler ist? Ich selber habe eine schulische Ausbildung zum "Assitent für Medieninformatik" und vor 16 Jahren eine Mechatroniker-Ausbildung absolviert und in beiden Berufen habe ich nichts über einen Kaufmann gelernt,
  18. Was muss man denn als FIAEler für einen kaufmännischen Teil lernen? Was hat ein Entwickler mit einem Kaufmann zu tun? Außerdem das e-book vom Rheinwerk Verlag würde ich nicht unbedingt empfehlen. Es ist komplett veraltet und die Programmierbeispiele sind oft abschreckende Beispiele, wie man es nicht machen sollte.
  19. So, wie ich das verstanden habe, will er das auch machen. Seine Frage ist wohl nur, ob und wie er es verkauft bekommen kann, irgendwas in Richtung "Medizin" zu machen, obwohl sein Arbeitgeber im Bereich "Musik" tätig ist.
  20. Whiz-zarD hat auf zwugel's Thema geantwortet in Java
    Selbst dann nicht mal wirklich. Sie sollten über Interfaces kommunizieren.
  21. Whiz-zarD hat auf Nopp's Thema geantwortet in Plauderecke
    In Japan gilt eigentlich per Gesetz die 40-Stunden-Woche. Einigen Unternehmen ist es auch gestattet, dies auf 44 Stunden auszuweiten. Darunter zählen z.B. Einzelhandelsgeschäfte oder Kinos. Das Bild des Arbeitswütigen Japaners stammt aus den 80ern und noch in die 90er hinein. Damals gabs Todesfälle wegen Überarbeitung aber dies wurde von denen gar nicht verlangt. 1997 hat man dann die 40-Stunden-Woche per Gesetz verabschiedet um der Arbeitswut Einhalt zu gebieten und so viel ist von der Arbeitswut auch gar nicht mehr übrig. Sie ist zwar immer noch recht hoch, aber inzwischen wollen die Japaner auch mehr Zeit für sich und ihrer Familie haben. Viele Firmen bieten sogar inzwischen eine 4-Tages-Woche an. Auch sind die Japaner sehr sozial eingestellt. So übernehmen viele Firmen auch inzwischen die Kita-Kosten, geben einen Mietzuschuss oder bezahlen Kindergeld. Davon können wir hier nur Träumen. Auch wenn man eine sehr lange Zeit Krank ist, bekommt man oft sein Gehalt sechs Monate ausgezahlt. Hier sind es nur 6 Wochen. Danach gibt es hier nur das Geld der Krankenkasse. Es bleiben also nichts weiter als Klischees übrig.
  22. Ich wäre da auch sehr vorsichtig, denn es klingt nicht so ganz, dass ihr wisst, was ihr da tut. Wozu ein Verschlüsselungsalgorithmus? Baut ihr den Algorithmus selber? Was soll überhaupt verschlüsselt werden? Wird die Verbindung zum Server verschlüsselt? Wie wollt ihr es denn überhaupt hinbekommen, dass keine Rückschlüsse auf die Wahl und dem Login gezogen werden können? Schließlich muss gewährleistet werden, dass ein Mitarbeiter nur ein mal Wählen darf und gleichzeitig muss die Wahl anonym gespeichert werden. Es darf z.B. mit Hilfe von Zeitstempeln oder IP-Adressen keine Rückschlüsse gezogen werden, wer wen gewählt hat. Das muss unterbunden werden und das ist nicht gerade trivial. Dazu braucht man zwei physisch getrennte Systeme. Ich denke mal, dass ihr euch da ganz schön übernommen habt und auch gar nicht im Klaren seid, welche Risiken in so einen System sich verbergen. Da zerbrechen schon sehr viele ihren Kopf und es gibt ganze Firmen, die sich auf solche Systeme spezialisiert haben und ich denke nicht, dass ein Student aus dem zweiten Semester und ein Azubi dies mal so eben aus den Ärmeln schütteln können. Man liest ja immer wieder, dass E-Wahlen-Projekte wieder eingestellt werden.
  23. Whiz-zarD hat auf einen Beitrag in einem Thema geantwortet in Coffeehouse's Themen
  24. Whiz-zarD hat auf einen Beitrag in einem Thema geantwortet in IT-Arbeitswelt
    Nicht jeder ist Single und hat nur einen Ein-Person-Haushalt. Es gibt Menschen, die essen lieber am Abend mit seinem/ihrem Lebensgefährten und von einem Essen in der Firma hat der Partner nichts von. Folglich muss hier so oder so Geld ausgegeben werden. Außerdem: Woher soll das Essen denn kommen? Nicht jede Firma hat Platz für eine Kantine und von Fraß aus Alu-Schalen oder Fast-Food halte ich sowieso nicht viel.
  25. Whiz-zarD hat auf einen Beitrag in einem Thema geantwortet in IT-Arbeitswelt
    Bei uns ist Kaffee (ein Automat mit diversen Sorten), Wasser und Tee umsonst und zwei Mal in der Woche bekommen wir eine Obstlieferung. Bei uns gibt es zwar auch Mängel (in welcher Firma nicht?) aber die Chef-Etage schätzt unsere Arbeit, weil sie selber mal Softwareentwickler waren und aufgrund der hohen Komplexität unserer Software können wir uns auch keine hohe Fluktuation leisten, also wird versucht, es den Arbeitnehmern die Arbeit so angenehm und so sozial wie möglich zu gestalten. Home Office ist zu jeder Zeit möglich aber bei uns ist es so, dass physische Anwesenheit doch besser ist. Auch wird Sonderurlaub für Umzüge genehmigt. Wir arbeiten im Bankensektor und es schon sehr schwer Softwareentwickler zu finden, die auch was von Finanzmathematik verstehen. Also durchlaufen Neuangestellte erst mal durch eine mehrmonatige Schulung und wenn sie angelernt und auch produktiv sind, möchte man sie dann auch nicht unbedingt gleich an den nächsten Arbeitgeber verlieren. Jedes Jahr werden auch Gespräche über unser Wohlerfinden in der Firma geführt und ob es vielleicht Ideen gibt, was man verbessern könnte und diese werden auch auf ihre Machbarkeit überprüft. Derzeit wird geprüft, ob es möglich ist, mit mehreren Firmen eine Kindertagesstätte einzurichten, damit man die Kinder im Falle von Ferien, Schulausfällen, etc. mal für ein oder zwei Tage unterbringen kann. Es wird aber nicht versucht eine sog. Gated Community aufzubauen, wie man es hier schon häufig bei Startups sieht, wo dann quasi ein gewisser Gruppenzwang herrscht, doch bis 20 Uhr und länger in der Firma zu bleiben, um noch mit den Kollegen ein Bier zu trinken.

Konto

Navigation

Suchen

Suchen

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.