How to configure my (tomcat) webapp running on AWS elastic beanstalk with an SSL certificate available at my custom subdomain https://mysubdomain.chatbotsagency.com/healthcheck
Why AWS?
– you can host your (tomcat) webapp on AWS beanstalk for free*
– you get a free SSL cert from AWS
– Problem: no HTTPS on elastic beanstalk URLs by default
Why not Heroku?
– Heroku has HTTPS out of the box, but…
– Heroku is super nice when building directly from github, but if you need some custom modifications or have a custom build process, beanstalk is more flexible
Needed steps for configuration:
Steps
1. create new SSL cert for HTTPS (via AWS, it’s free!)
– for e.g. “mysubdomain.chatbotsagency.com”
+ validation via email
-> create new free SSL certificate for your custom subdomain
2. setup app (e.g. tomcat webapp) at beanstalk
– during setup: set custom domain “Environment settings” – Name & Domain
-> setup new beanstalk environment at http://mysubdomain.us-west-2.elasticbeanstalk.com
– opt. check webapp with URL http://mysubdomain.us-west-2.elasticbeanstalk.com/healthcheck (tomcat apps runs on /healthcheck)
3. setup subdomain forwarding at your own domain provider
– CNAME mysubdomain.chatbotsagency.com -> mysubdomain.us-west-2.elasticbeanstalk.com
-> app runs at: http://mysubdomain.chatbotsagency.com
– opt. check webapp with URL http://mysubdomain.chatbotsagency.com/healthcheck
A week ago I launched Mica on Product Hunt. Mica, the Hipster Cat is one of the first bots that got approved by Facebook to run on the brand new Facebook Messenger platform that helps you discover hip venues. You can talk to Mica here đŒ.
What is a Chat Bot?
A Chat Bot is a (ro)bot that is programmed to talk to you and answer requests. The topic depends on the businessâ focus and could be a weather forecast bot, (online-)shop assistant bot, or a hotel reservation bot, but in our case itâs a venue recommendation bot.
Poncho, a weather bot, on Facebook Messenger (left) and The Economist bot on Line app (right)
Bots could also replace regular services of bigger companies such as service hotlines or FAQs, which would lead to massive cost savings.
You donât need to install a specific app to use a bot because it is integrated in the chat provider infrastructure such as Messenger, WhatsApp or Telegram.
Meet Mica
I love fancy coffee shops and restaurants! I spend lots of time hanging out in them, meeting friends or working, and I have my own favorite hipster locations where I know the coffee and vibe is just perfect. So I thought it would be great fun to have a chat bot that shares my love for good coffee and food that can be asked for recommendations worldwide.
Here are a few screenshots that illustrate how interacting with Mica feels like:
Mica on Android
You can send her your location as city name or Facebook Messenger attachment and you can also use some basic chat phrases such asâHelloâ, âHow are you?â or âThank youâ
Mica on iOS
Since the Messenger platform is platform-independent Mica can also be used in the browser itself:
Mica in a browser
Mica on Product Hunt
So how did the Product Hunt launch go? Quite well actually! Since Mica is a fairly simple bot I did not expect that it would get a lot of attention. But I clearly underestimated the Product Hunt communityâs enthusiasm for cats and coffee.
User comment on Product Hunt
What happened since the launch?
#1 in the Product Hunt category Facebook and Travel
Over 2.500 hipster location recommendations given
400 funny cat pics sent
#1 on Product Hunt
Key learnings about the Facebook Messenger Platform
Building a bot for the Facebook Messenger platform was way easier than I expected. It just took me two afternoons to get to a simple proof of concept. Now that Mica is white-listed 900 million users of Facebook Messenger can get coffee shop and restaurant recommendations without having to go to any app store. They can just directly interact with Mica.
This might not sound like a huge deal but just a few months ago I also built location based recommendation apps for iOS and Android. One big adoption barrier for apps is that you have to get people to the app store to download your app. If your app is not mission critical this is even more difficult. The whole process of downloading apps is quite complicated for many people. It often means they might have to enter a password or figure out how to free up storage by deleting other apps. Because of that some people donât use any apps apart from what comes pre-installed or what other people helped them to get onto their phone.
By building on top of the Messenger platform a lot of adoption barriers suddenly disappear.
Another key learning for me was that most people are still quite unfamiliar with the idea of a bot within chat platforms (yet). Most people expect that they have to download an app and are very surprised about the fact that they can just directly send messages to Mica. Iâm curious how fast bots will become mainstream.
Whatâs next?
Iâm currently working on a Telegram bot to cover its users tooâââthey recently announced to serve 100M monthly active users.
These are quite exciting times, building one of the first bots feels a bit like building the first mobile applications back in the day when the app stores where still empty. If you havenât yet Iâd encourage you to try some bots and think about what kind of bot you would build.
Originally posted as “10+ things I hate about iOS development” on Medium March 11.
As you might know, I finally released the first iOS versions of LIKE A HIPSTER and Hungry?. So I finally stumbled upon iOS development, although I tried to avoid for so long. And Iâm not very happy with it.
I like to try out new technologies. I love to play around with stuff, especially mobile. So I submitted some more or less serious Android apps in the Google Play Store and developed also professional Android apps for Keyosk Tablets and Freewave. Since I already program with Java for 15 years now, itâs fun to develop Android apps because there are no obstacles concerning the language and itâs a very well thought-through framework.
But iOS is different. Why? Here are at least 10 reasons:
1. Swift is not intuitive
You can program iOS apps natively in Objective C or Swift. First I tried to learn Swift on my own because itâs the successor of Objective C (why learn an ancient language when starting iOS development from scratch?) but I soon realized that Swift and I were not made for each other. I never tried Objective C but Swift is super unintuitive and as some of you also might know Iâm very impatient. But also pragmatic – so I checked some (Cordova) alternatives such as React Native and finally found Ionic. And this time it was love at first sight!
Iâm a Java back-end (and Android) developer but usually I try to see the full picture of a software project so I would rather be called a âfull-stack developerâ nowadays. Usually I try to avoid front-end development because there are for sure better skilled people out there adjusting CSS and that other hardcore FE stuff, but with my current project George I slipped into AngularJS, which is very nice to work with, when you are used to the âlaw and orderâ of Java (I already had a talk or two about AngularJS at someconferences – here are my slides from Berlin).
Ionic is based on AngularJS so for me it was the perfect choice since I was already familiar with AngularJS. But developing for iOS means to use OS X.
2. Must use OS X
There is no way around it! You have to use OS X to build the iOS binaries and I never was a Mac user. Coming from the Java world which was from the very beginning conceptualized as platform independent it is strange to be bound to an OS.
So what I did was to virtualize OS X. Yeah, you might think now âWTF?â, but I really did! Some people warned me about it because it would be too slow or to complicated or so but I though Iâll give it a try anyway because âhow hard can that be?â (famous last words!) and I really didnât want to buy an overpriced MacBook.
So what I did was to get my hands on an OS X image and virtualize it with Oracle VirtualBox, which worked pretty well. The VM is fast, not slow at all! Also with the virtualization I didnât have to switch computers all the time.
The only disadvantage of OS X as VM is that VirtualBox has a limitation of screen resolution on the virtual machineâs window in your original OS. So the VMâs window does not scale. But at least it is Unix⊠-ish.
3. Must use XCode
Another very limiting fact about developing iOS is that you can only upload the binaries in XCode! As far as I know there are alternative possibilities to the IDE such as JetBrainsâ AppCode or alternatives to the build tools e.g. Fastlane or Ionic (also uses its own build tools) but you have to use XCode (at least from command-line) to submit the artifact to the iTunes app store.
I donât like proprietary software. Iâm an open source girl. And being limited and bound to something is kind of strange to me. So for actual development I use WebStorm that is per se a JavaScript IDE and then I commit the iOS stuff with Git to OS X and build and submit it there with XCode.
The one good thing about XCode is that the emulators start very fast. When starting an Android emulator you have to wait a minute or so for the Android OS to fully start up. At least one small advantage of iOS development.
4. Paid Apple developer account
If you want to contribute to the iTunes app store you have to buy a developer license. Thatâs very strange: So the community builds killer-features for the iPhone and they also have to pay for that?
Itâs around âŹ/$ 100 a year! At this point I donât even see that the app will amortize this 100 euro/dollars in the foreseeable future.
In contrast to that gorgeous Android land itâs free to publish withing the developer program, you just have to pay a registration fee of $25.
5. Certificates, certificates, certificates
Generally speaking certificates and encryption are awesome! Itâs the only way to secure communication or authenticate and authorize in a proper way.
ios developer certificates, provisioning profiles and a small little bug in xcode… #AngerManagement#notWorking
For iOS development you need a bunch of certificates. Many certificates. Far too many! You need two for yourself (iOS Development and iOS Distribution). Then you need to register each of your development devices (e.g. your iPhone and iPad). Next you need to register your apps themselves (âApp Identifierâ) and last but not least you need a bunch of âiOS Provisioning Profilesâ, again two per app – one for distribution and one for development – and also three (!) iOS Team Provisioning Profiles (at least they are managed by XCode itself).
In Android you just have two Java key-stores, one for development and one for releases. Thatâs it. Super secure and easy.
6. Keychain Access my ass
Unfortunately at one point the âApple Worldwide Developer Relations Certification Authorityâ certificate expired (after only 2 yearsâŠ) and it took me several hours to find out what was wrong because the error message just told me that my app developer certificates were not valid. Googling and trying to change my certificates also broke the currently published apps⊠Finally I got the right google-hit that this one certificate was expired. It was hidden in the Keychain Access tool by default, well because it was expired. But I already destroyed all my dear certificates, so I had to create all of them again.
Having all those certificates and your bought license you can finally start developing. In XCode of course.
7. XCode is too complicated
XCode is strange. Very strange. Especially when you are used to (Java) IDEs like IntelliJ, Eclipse or Android Studio.
For example if you want to release a build you have to add all these different versions of the app icons and launch images. Why arenât they just generated automatically?
many many different icons
If you use Ionic it already generates a bunch of these icons and launch images in different resolutions but still you have to create a hand-full of them manually. And you have to associate these icons to the proper versions. Itâs like playing Memory for developers!
And youâll find the build artifacts under âOrganizerâ. Totally plausible, isnât it? Why donât you just call this menu item âArtifactsâ or âArchiveâ?
Also you cannot archive an artifact if currently an emulator is selected as run-time device. Why not just automatically archive it for the default generic device?
Just to compare iOS and Android Iâll show you the number of clicks you need to release a version. In XCode you need to:
Click âBuildâ
Click âArchiveâ â the âOrganizerâ opens
select your version
click âUpload to App Store..â â a pop up opens
every single time you have to select our âTeamâ. Why not use defaults? This point will not change that often
send to Apple by clicking âUploadâ
In Android Studio itâs:
Click âGenerate signed APKâ â a dialog opens
(enter keystore password if you like and) click âNextâ
(choose build type and path if you like and) click âFinishâ
This is only half the number of steps! And I also think the last step in Android Studio is not really necessary.
Apple always proudly presents its software and other products as super usable, but I really have to admit that, at least for the developer tools and developer experience, this does not seem to be the case.
XCode is the perfect IDE for developers without personal will and self-respect
I call it âApple-XMLâ because iOS uses XML in an unusual way, especially for the plist-file (Property List file), which is a config file for your iOS app. If you are lucky you donât have to adapt it at all because the Cordova build tool already alters it for you but I ran into a Cordova plugin bug so I had to adjust this file myself.
Apple does not use the âproperâ XML standard way such as:
<key name=ânameâ>value</key>
but in a way where key and value alternate in a list:
OK, this is very technical (and correct XML) and I also think itâs not a super bad thing but it just âitchesâ in by brain and I cannot scratch it.
9. iOS development limitations
There are unnecessary limitations developing iOS such as: You cannot use a transparent PNG as icons. Why not? A transparent icon would be so much nicer on the iPhone home screen!
It would also be very, very nice to use a GIF as launch image in iOS, but this is also not possible in Android.
10. Bad Usability of the iTunes Connect website
I just sum up some usability points:
The iTunes connect website does not work properly on Androidâs internal chrome browser! The lower part of the website simply does not show up. That was pretty annoying since last weekend I was AFK and only had my Nexus with me and wanted to add Beta users to my iOS apps.
The website has a timeout of 30 minutes or so and it has disabled the possibility to save your password in your browser. Well Apple takes security serious, but in the wrong way! Every time I go to the iTunes website I have to enter my password which is very bad because of possible sniffing attacks, key-logger, or person simply standing behind you (âshoulder surfingâ) if you have to enter your password all the time.
The website is also broken in that way that when you ran into a timeout youâre redirected to the the login form three times in a row because of improper session management. I hope, theyâll fix that soon!
Every time you submit a new release you have to pass several steps until you can finally submit a new version. You also have to answer the same questions all the time (does your app use encryption? does your app use ads?). But in a way that is consistent with XCode ;)
When you want to update your apps’ screenshots it also gets a little bit difficult: When you generate the screenshots on your emulators or devices you usually identify the device e.g. “iPhone 5”, “iPhone 6S” etc, but when you have to upload the iPhone 5 screenshot, iTunes Connect just shows you the screen-size e.g. “3,5 inch”, “4 inch”, “4,7 inch”, “5,5 inch”! Ok, maybe you might say now, that every iOS developer knows the resolutions of all iOS devices by heart, but I tell you, that’s again just one other point of your Tech-Stockholm Syndrome.
11. Crash TestFlight
I almost forgot to mention TestFlight, Appleâs beta testing tool! It is – you might guess it – complicated. A developer can add very good friends or other abusable people as Alpha or Beta testers and Iâm very glad for every single one of them.
So you start adding their Apple ID email addresses and TestFlight sends them an email invite. To make things a little bit more juicy this email has to be opened on the test device itself, and since some people use a different email address as Apple ID than they regularly do, this is the first difficult obstacle for some. After opening the invite email on the device the poor testers have to install the TestFlight app on their device! So you need an app to test an app. At least the testers can submit feedback though this app – but actually no one did so far, they just texted me directly.
Another advantage of a distinct test management app would be to show you pending invitations for other app, but for some reason TestFlight doesnât!
With Android you can decide whether you want to create an open or a closed Beta or Alpha (cannot choose that in iTunes), just add these people and they get the updates pushed via the Play Store. OK, they also receive an email and have to click on a confirmation link, but no special strings attached.
If you want to release a new Beta you have to wait for an Apple review, that might take some days (usually 5 days) and when the artifact is accepted by the Apple consortium is also is not directly published as Beta, but you again have to click yourself through the dialogs.
At least you donât need a review with Alpha releases, but you cannot simply add Alpha users, you have to define a certain role for them in your company in iTunes Connect. So, who wants to be my new Alpha tester slash Chief Legal Officer?
12. No Hot-Fixes!
Last but not least: There is no extra workflow for hot-fixes!
This would be a killer argument against iOS development: If you find a bug or even if you find out you uploaded the wrong screenshot you have to wait for a new release to be approved.
iOS development is not for the impatient (me): you have to wait almost a week for a release, also for screenshot changes, no hotfixes WTF
If you are lucky you can request (with a simple contact form) a quicker release but this is not the standard way and Apple does not guarantee anything. So you release the bug-fix and hope for the best. And wait, 2â3 day or up to a week, to get your bug-fix deployed or app store entry changed.
In Android all releases are deployed in 2â3 hours. Just FYIÂ ;)
Describing all of these problems I had with the setup and development of my iOS apps Iâm even more proud that I was finally able to release the iOS versions of my apps LIKE A HIPSTER and Hungry?.
Nachdem ich immer und immer wieder mit Argumenten fĂŒr Outsourcing – oder auch “Near-/Off-Shore Development” oder wie man es auch immer nennen schönreden möchte – ĂŒberschwemmt werde, möchte ich nun ein fĂŒr alle mal klarstellen: Outsourcing ist eine schlechte Idee.
In meiner Heimat, der Software-Entwicklung, bedeutet Outsourcing, dass die Entwicklung (oder ein Teil davon) an einen meist geografisch deutlich entfernten und preislich (zumindest auf den ersten Blick) Ă€uĂerst begĂŒnstigten Ort ausgelagert wird. Nicht zu selten kann es sich dabei um eine (Tochter-)Firma in einer indischen (in Bangalore haben IBM, HP, Accenture etc. Niederlassungen), kanadischen, irischen oder einer auch (nah-)östlichen Stadt handeln. So kann man sich Software in vermeintlich lukrativen, weil anfangs deutlich kostengĂŒnstigeren, (Sub-)Unternehmen erstellen lassen.
Warum ĂŒberhaupt?
Nicht selten wird outgesourced, da das Know-How im eigenen Unternehmen fehlt und ebenso die Zeit, dieses aufzubauen. So werden als Quick’n’Dirty-Alternativen Dienstleister engagiert, die das GewĂŒnschte anbieten und mit einem Stundensatz bestechten, der bei vielleicht nur einem Drittel von dem in Ăsterreich/Deutschland liegt. Auf dem Prinzip der Auslagerung basiert ja eigentlich die gesamte IT-Branche, da AuftrĂ€ge an andere vergeben werden und gern fĂŒr ein fertiges Produkt inkl. GewĂ€hrleistung gezahlt wird – ein sowieso vollkommen veralteter Gedanke, Software als in sich abgeschlossenes Werk zu betrachten. Denn Software lebt! Wird Software nicht mehr weiterentwickelt, stirbt sie fast augenblicklich.
HĂ€ufig wird Outsourcing so eingesetzt, dass billige “FachkrĂ€fte” eingekauft werden, um einen Engpass im Unternehmen auszugleichen. So wird ein Teil der Entwicklung dann vielleicht nach Bangalore ausgelagert, aber das Management bleibt in Wien. Dabei werden aber oft einige Kosten nicht mitgerechnet, wie der Mehraufwand in der QualitĂ€tssicherung, der Kommunikation oder der (Wieder-)Eingliederung des Know-Hows in das Unternehmen. Kurzfristig lassen sich sehr wohl Kosten reduzieren, aber langfristig halst man sich ein teures Problem auf, das man vermeiden hĂ€tte könnten.
Die LĂŒge
Was hĂ€ufig bei Outsourcing zugunsten der hĂŒbsch niedrigen Zahlen fĂŒr den Entwicklerstundensatz vergessen wird, ist:
Persönliche Kommunikation kann NICHT ersetzt werden.
Im Sinne von Scrum sitzt das Entwickler-Team möglichst im selben Zimmer.
Kulturelle Unterschiede zwischen Entwicklern unterschiedlicher LĂ€nder.
Das bedeutet vor allem Arbeitsmoral und LoyalitÀt.
VerstÀndigungsprobleme aufgrund unterschiedlicher Sprachen.
Der immer unterschÀtzte Koordinationsaufwand.
Wenn wir Entwickler schon schwer verstehen, was das Marketing will, obwohl wir beim selben Meetingraum sitzen…
Know-How-Verlust.
Höherer Planungsaufwand.
Auch nach Fertigstellung des Projektes zur Reintegration ins auftraggebende Unternehmen.
Enorme QualitÀtssicherungskosten.
Zumindest das Userinterface muss erneut wieder von einem deutschen Native Speaker ĂŒberprĂŒft werden. Rechtschreib- und Grammatikfehler werden nicht erkannt.
Verlust des informellen Informationsaustausches.
Plauderei beim Mittagessen etc.
Schlechtes Image.
Die Zeiten, als Outsourcing noch als gute Möglichkeit gewertet wurde, sind definitiv vorbei.
Verlagerung der Wirtschaftsleistung weg ins Ausland.
Besonders gefÀllt mir die Beschreibung bei der Vergabe des Negativpreises des Unwort des Jahres (und das war schon 1996!):
“Imponierwort, das der Auslagerung/Vernichtung von ArbeitsplĂ€tzen einen seriösen Anstrich zu geben versucht”
Outsourcing macht meines Erachtens nur Sinn, wenn:
– es sich nicht um das KerngeschĂ€ft des Unternehmens handelt,
– es ein in sich abgeschlossenes englischsprachiges Projekt handelt (und alle “Externen” auch gut Englisch können),
– nicht agil entwickelt wird (allerdings sowieso eine TodsĂŒnde – Ich schlafe ja bekanntlich mit dem Agilen Manifest unter dem Kopfkissen. Und das ruhig und sehr zufrieden).
Machen wir es richtig!
Die Alternative zu Outsourcing liegt somit auf der Hand: Aufbau eines qualifizierten (agilen) Teams als eigene Abteilung oder Subunternehmen in unmittelbarer NĂ€hre zum Produktmanagement statt Ausgliederung. Sollen einzelne Mitarbeiter (kurzfristig) ersetzt werden, dann können das gern externe sein, die sich aber möglichst stark ins Team integrieren (Anwesenheit). Outsourcing sollte nur im Ă€uĂersten Notfall in ErwĂ€gung gezogen werden, und am besten nicht mal dann. Lieber qualifizierte Software-Entwickler einladen und Know-How im eigenen Unternehmen aufbauen. Versteht mich nicht falsch, ich bin nicht eine, die glaubt, dass ihre Mitarbeier nur dann arbeiten, wenn ich sie sehe. In einem gut eingespielten Team kann Homeoffice durchaus ĂŒblich sein… aber das zu erörtern sprengt nun hier wohl den Rahmen.
Ich liebe und lebe agile Software-Entwicklung und arbeite gern eng mit meinen Mitarbeitern, Kollegen und Kunden zusammen. Als Scrum-Master kenne ich die Vorteile von Transparenz, Kommunikation und Innovation und bringe diese tÀglich zum Einsatz.
Naja. Und falls jemand diesbezĂŒglich eine Beratungsleitung von mir in Anspruch nehmen möchte… Nun ja, ihr wisst ja, wo ihr mich findet. ;)
FĂŒr mein Foodblog chefbabe.at habe ich eine Android App geschrieben:
Sie reprÀsentiert die Android App Version des Foodblogs chefbabe.at
Die köstliche Chefbabe App ist da! :)
chefbabe.at jetzt auch auf deinem Android-Telefon.
Nie mehr ein Rezept versÀumen mit der Sofort-Benachrichtigung.
Kreative Idee gefĂ€llig? Einfach schĂŒtteln!
Features:
– Liste der Rezepte inkl. “Schmökern”-Ansicht (nur Bilder), Nachladen bei Scrollen, Ansicht des Blogbeitrags, “Neu laden”…
– SchĂŒttelfunktion! (Zufallsrezept)
– Benachrichtigungen bei neuen Rezepten
– Teilen eines Rezepts
– Suchen
– Ăber-Seite (wer kocht hier?)
Chefbabe.at ist das erste Foodblog* mit eigener App. Viel Spaà beim Mitnaschen! :)
select
fko.name   "Foreign key name",
par.name   "Referenced table name",
fk1.name || ' -> ' || pk1.name "Reference 1",
fk2.name || ' -> ' || pk2.name "Reference 2",
fk3.name || ' -> ' || pk3.name "Reference 3",
fk4.name || ' -> ' || pk4.name "Reference 4"
from
sysobjects     tab                                      join
sysconstraints con on tab.id       = con.tableid       join
sysobjects     fko on con.constrid = fko.id            join
sysreferences  ref on con.constrid = ref.constrid      join
sysobjects     par on par.id       = ref.reftabid left join
---- 1. Column
syscolumns     fk1 on ref.fokey1   = fk1.colid and
ref.tableid  = fk1.id       left join
syscolumns     pk1 on ref.refkey1  = pk1.colid and
ref.reftabid = pk1.id       left join
---- 2. Column
syscolumns     fk2 on ref.fokey2   = fk2.colid and
ref.tableid  = fk2.id       left join
syscolumns     pk2 on ref.refkey2  = pk2.colid and
ref.reftabid = pk2.id       left join
---- 3. Column
syscolumns     fk3 on ref.fokey3   = fk3.colid and
ref.tableid  = fk3.id       left join
syscolumns     pk3 on ref.refkey3  = pk3.colid and
ref.reftabid = pk3.id       left join
---- 4. Column
syscolumns     fk4 on ref.fokey4   = fk4.colid and
ref.tableid  = fk4.id       left join
syscolumns     pk4 on ref.refkey4  = pk4.colid and
ref.reftabid = pk4.id       -- Et cetera...
where
tab.type = 'U'Â Â Â Â Â and
fko.name = 'FOREIGN_KEY_NAME' and
fko.type = 'RI'
But when you do this, you get a javax.net.ssl.SSLHandshakeException: java.security.cert.CertificateException: No name matching xxx found when trying to connect e.g. with new java.net.URL(url).openStream();
The work around for this problem is, to include the following in your Java class (found here):
public class ClassBla {
static {
javax.net.ssl.HttpsURLConnection.setDefaultHostnameVerifier(new javax.net.ssl.HostnameVerifier() {
public boolean verify(String hostname, javax.net.ssl.SSLSession sslSession) {
return true;
}
});
}
..
}
There is a way to import a certificate issued to a different domain for another certain (sub-)domain with the java keytool as well.
Nach etwas mehr als einem Jahr verlasse ich den IT-Giganten Hewlett-Packard, fĂŒr den ich als Software-Architektin (nicht als Architecture Astronaut!) in Wien tĂ€tig war. Ich bedanke mich bei allen Mitarbeitern, Kollegen, Kunden und Lieferanten fĂŒr die aufregende, lehrreiche Zeit, die ich nicht missen möchte, denn ich habe eine Menge gelernt.
Nachdem ich bereits fĂŒr Siemens, IBM, das BMLV und die Telekom Austria gearbeitet habe, war die Arbeit fĂŒr ein GroĂunternehmen nichts Neues fĂŒr mich – mit allen einhergehenden Vor- und Nachteilen. Das ProjektgeschĂ€ft eines Software-Dienstleisters (meine ehemalige Abteilung setzte Individualentwicklungen im Rahmen von GroĂauftrĂ€gen um) ist ebenfalls interessant und herausfordernd, allerdings wende ich mich nun neuen spannenden Aufgaben zu, und zwar wieder der Produktentwicklung.
Ich beginne bei paysafecard als Senior Software-Entwicklerin! paysafecard ist ein relativ junges österreichisches Unternehmen, das verschiedene Prepaid-Bezahllösungen fĂŒrs Internet anbietet, unter anderem eine prepaid Mastercard YUNA oder die paysafecard selbst.
Nach etwas mehr als zwei Jahren im “Staatsdienst”, habe ich mich vom BMLV+S getrennt und bin auf die gute Seite der Macht gewechselt – wieder mal vom Kunden zum Lieferanten, wie ich es damals bereits beim Wechsel von der Telekom Austria zu Knallgrau gemacht habe. Bei diesem Wechsel hat sich allerdings auch eine groĂzĂŒgige berufliche Weiterentwicklung vollzogen, da ich nun nicht mehr als Senior-Software-Entwickler, sondern als Software Architekt bei Hewlett-Packard arbeite, zum Teil auch im Pre-Sales-Bereich.
Vom Fleck weg ĂŒberzeugt hat mich das super moderne BĂŒro mit ergonomischen Tischen und Dockingstations mit Monitoren etc. fĂŒr die Mitarbeiter-Notebooks …
… und das Konzept des sogenannten “e-clubs”, ein Bereich, in dem gratis FrĂŒhstĂŒck angeboten wird, gratis Kaffee (u.a. Lavazza!) und als Socializing-Bereich dient.
HP bietet eine Reihe von Benefits fĂŒr seine Mitarbeiter wie neue Firmen-Smartphones, Mitarbeiterpreise bei Hardware, gestĂŒtztes Essen in den Eurest-Kantinen im Euro-Plaza …
… Duschen fĂŒr Jogger und Radfahrer, Betriebsarzt, Mitarbeiterkonditionen bei diversen Firmen, Firmenveranstaltungen (am ersten Tag hab ich einen roten HP-Sweater wegen einer Kampagne geschenkt bekommen!) und vieles mehr. Hier sind noch mehr Fotos vom Office (hier auch von Dieter) zu finden.
Teleworking wird bei HP groĂ geschrieben, wobei viele Mitarbeiter sogenannte “mobile ArbeitsplĂ€tze” bekleiden. Somit ist Homeoffice möglich und wird auch gefördert – so auch bei mir. Ein Gleitzeit-Modell bietet flexible Arbeitszeiten. Auf den ersten Blick also ein fabelhafter Arbeitgeber!
Kompetente Mitarbeiter haben sich am Anfang um mich bemĂŒht und mir bei den bĂŒrokratischen HĂŒrden geholfen. Ein Mentoring-Programm hat mir einen “GroĂen Bruder” bei HP geschenkt, der sich um mich kĂŒmmert ;) . Neue Projekte warten schon auf mich und ich bin gespannt, wie es weiter gehen wird.