Adding blog articles, associated images and authors for new blog entries (#77)
* add D Wehrle Blog Articles * changing pub dates * merging authors * changed up authors.yml * fixing copy paste problemo * Change publish date of Hackathon blog post to today. * Change publish date of Windows Hello blog post to Tuesday.
This commit is contained in:
Scott Speights
Martin Danielsson
parent
87da1a0a15
commit
b5e0bb39c6
7 changed files with 190 additions and 27 deletions
|
|
@ -1,77 +0,0 @@
|
|||
---
|
||||
layout: post
|
||||
title: Creating the Smartsteuer 'Snap' App
|
||||
subtitle: A behind the scenes view of the birth of our youngest creation.
|
||||
category: product
|
||||
tags: [smartsteuer, mobile, custdev]
|
||||
author: eike_hirsch
|
||||
author_email: eike.hirsch@smartsteuer.de
|
||||
header-img: "images/bg-post.jpg"
|
||||
---
|
||||
|
||||
As we at [smartsteuer](https://www.smartsteuer.de) really enjoyed how our [Smartsteuer Smartphone App](https://www.smartsteuer.de/online/steuererklaerung-online/#smartphone) was imagined and eventually created, I thought it might be fun to write about it. This blog post is not that much technical but describes our journey to a product which (hopefully) will create value for our customers.
|
||||
|
||||
### Background
|
||||
|
||||
At smartsteuer we create tools for people who want to do their tax filings online. For that, we continuously seek for smart solutions to make this task as easy as possible. One example is an app that we created to answer one question which always nags our customers:
|
||||
|
||||
> Why should I care? Can I even expect a refund?
|
||||
|
||||
To answer this seriously you have to do a whole lot of calculations for which you need quite some information from the user. Which in turn would create a process which is _not_ fast and easy. So, some years ago we created this app which would do two things:
|
||||
|
||||
1. Only asks for about five things every user knows of the top of their heads.
|
||||
2. Make some educated guesses to answer all the other questions with rough estimates.
|
||||
|
||||
The result couldn't be exact but it was good enough to answer said question. It worked quite well even though you still had to provide those five figures.
|
||||
|
||||
### Theory
|
||||
|
||||
Now, with the help and cooperation of our fellow colleagues from "Haufe Lohn & Gehalt" we wanted to take the app to the next level. It was our aim to reduce the number of questions the user needs to answer and at the same time increase the accuracy of the calculation. I will spare you the details but the result of our efforts was a QR-Code which every user of "Haufe Lohn & Gehalt" would get and which would contain all wage and tax information an employee needs to file her taxes.
|
||||
|
||||
So the plan was to enhance the app with a qr-code scanner to safe the user some typing.
|
||||
|
||||
We created a quick briefing for our mobile dev agency - they returned an offer - we signed it - the deal was sealed.
|
||||
|
||||
You might wonder why I am writing the blog post in the first place, as this sounds all to familiar and is in any regards special. Well you are right. Up until here this story is _only_ an example of solid work. But please bare with me and read on.
|
||||
|
||||
### Reality kicks in
|
||||
|
||||
About an hour before the agency would come by to kick the project off I was holding an internal meeting to get everybody on the same page. During this meeting it came to light that the project somehow managed to stay under the radar and that everyone in the room did not know about it. This is quite uncommon in our company as everybody is eager to know what is going on and to contribute her ideas and we encourage everyone to do so. But in this particular case this somehow did not happen until said meeting.
|
||||
|
||||
And so it was this meeting when all the experts where questioning the new feature and its purpose:
|
||||
|
||||
> Why are we doing this?
|
||||
> What is the benefit for the user?
|
||||
> Is the benefit big enough to justify the work?
|
||||
> What data is included in the qr-code?
|
||||
> Is this really the best we can do for our customers?
|
||||
> …
|
||||
|
||||
It turned out that, while we would get a lot more data to replace some of our guesses with real values, the user would still need to answer four out of the former five questions and instead would need to turn on the scanner and snap the code. That was not the benefit we hoped to deliver.
|
||||
|
||||
### Adaption
|
||||
|
||||
Luckily we did not stop there. When you happen to have a bunch of smart people in the room, new ideas come up and so a totally new app slowly came into shape.
|
||||
|
||||
**What can we do with that qr-code?** It contained lots of data which the user would need to manually enter into her tax filing - a tedious and error-prone process.
|
||||
|
||||
**But our main product - the tax filing software - runs in the browser on desktop-PCs.** You don't normally scan qr-codes with an desktop-PC.
|
||||
|
||||
**What if we could transform the qr-code-scanner into an input device for our software?** We would need to find a way to link the app with the software without needing the user to do some fancy stuff or even worse needing to understand the whole process. And at the same time keeping her data safe and protected.
|
||||
|
||||
**Can't we create a second qr-code which contains the data needed for the linking?**
|
||||
|
||||
**And why not use OCR to read any other document**
|
||||
|
||||
By the time the agency arrived we had totally rewritten the plan. And they had no idea…
|
||||
|
||||
### Outcome
|
||||
|
||||
Well, we had to start the meeting with a lot of apologies. The app we original signed up for was from the table but we still wanted *an* app. Luckily our agency was flexible enough to adapt to the new plan and within only one week we had a working prototype. From that day on everything worked according to the plan and now our Smartsteuer App is available at the [IOS App Store](https://itunes.apple.com/de/app/smartsteuer/id1068423226?mt=8) and will be very soon be in the Android Play store as well (We will post the link as soon as its up). Check it out if you like and let me now what you think.
|
||||
|
||||
Finally I'd like to give a big shout out to our colleagues at [Haufe-Lexware](http://haufe-lexware.com) and to our agency [Wissenswerft](http://wissenswerft.net) for the great teamwork and flexibility!
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
|
@ -1,27 +1,56 @@
|
|||
---
|
||||
layout: post
|
||||
title: Summer Internship @Haufe
|
||||
subtitle: An experience that greatly helped me to improve myself
|
||||
category: general
|
||||
tags: [culture, docker]
|
||||
author: Bogdan Bledea
|
||||
author_email: bogdan.b19c@gmail.com
|
||||
header-img: "images/summerInternships1.jpg"
|
||||
---
|
||||
|
||||
I'm Bledea Bogdan and together with Patricia Atieyeh, both second year students at Polytechnic University of Timisoara, we built a feedback box app for Haufe-Lexware.
|
||||
|
||||
Today is the last day spent @Haufe. And I must admit, this summer internship was simply awesome. My work colleagues were so friendly, they helped me when I was in trouble. And I didn't thought it's so fun to go to work.
|
||||
|
||||
Below, is a screenshot of the application we built during this intership, built with the Meteor framework. Meteor is a brand new framework, both front-end and back-end, which makes Meteor a great framework.
|
||||
|
||||
{:.center}
|
||||
{:style="margin:auto"}
|
||||
|
||||
This application is for internal company use and it takes a feedback from a user, post it on the site, and sort the feedbacks by the number of votes. Users can delete only their feedbacks, and the feedback can be modified only if there is no reply or vote.
|
||||
|
||||
The development process was a little bit tricky for us, and, furthermore, it was the first time we used Meteor to develop web apps. But, in the end, we proved that nothing is impossible, and if you truly want, you can learn new things anytime.
|
||||
|
||||
As you can see, this feedback box app has an user login®istration form, but, we restricted the account creation to the company email domain, haufe-lexware.com. After the user logs in, he can post and reply to the other feedbacks.
|
||||
|
||||
And when I say it was tricky, I mean, the support on the internet for docker and meteor was so poor. I've had a lot of bugs, the meteor pack for docker it wasn't at least official, and the problems we encountered, was already posted on the internet, with a lot of troubleshooting, but, nothing for our case.
|
||||
<<<<<<< HEAD
|
||||
---
|
||||
layout: post
|
||||
title: Summer Internship @Haufe
|
||||
subtitle: An experience that greatly helped me to improve myself
|
||||
category: general
|
||||
tags: [culture, docker]
|
||||
author: Bogdan Bledea
|
||||
author_email: bogdan.b19c@gmail.com
|
||||
header-img: "images/summerInternships1.jpg"
|
||||
---
|
||||
|
||||
I'm Bledea Bogdan and together with Patricia Atieyeh, both second year students at Polytechnic University of Timisoara, we built a feedback box app for Haufe-Lexware.
|
||||
|
||||
Today is the last day spent @Haufe. And I must admit, this summer internship was simply awesome. My work colleagues were so friendly, they helped me when I was in trouble. And I didn't thought it's so fun to go to work.
|
||||
|
||||
Below, is a screenshot of the application we built during this intership, built with the Meteor framework. Meteor is a brand new framework, both front-end and back-end, which makes Meteor a great framework.
|
||||
|
||||
{:style="margin:auto"}
|
||||
|
||||
This application is for internal company use and it takes a feedback from a user, post it on the site, and sort the feedbacks by the number of votes. Users can delete only their feedbacks, and the feedback can be modified only if there is no reply or vote.
|
||||
|
||||
The development process was a little bit tricky for us, and, furthermore, it was the first time we used Meteor to develop web apps. But, in the end, we proved that nothing is impossible, and if you truly want, you can learn new things anytime.
|
||||
|
||||
As you can see, this feedback box app has an user login®istration form, but, we restricted the account creation to the company email domain, haufe-lexware.com. After the user logs in, he can post and reply to the other feedbacks.
|
||||
|
||||
And when I say it was tricky, I mean, the support on the internet for docker and meteor was so poor. I've had a lot of bugs, the meteor pack for docker it wasn't at least official, and the problems we encountered, was already posted on the internet, with a lot of troubleshooting, but, nothing for our case.
|
||||
=======
|
||||
---
|
||||
layout: post
|
||||
title: Summer Internship @Haufe
|
||||
subtitle: An experience that greatly helped me to improve myself
|
||||
category: general
|
||||
tags: [culture, docker]
|
||||
author: Bogdan Bledea
|
||||
author_email: bogdan.b19c@gmail.com
|
||||
header-img: "images/summerInternships1.jpg"
|
||||
---
|
||||
|
||||
I'm Bledea Bogdan and together with Patricia Atieyeh, both second year students at Polytechnic University of Timisoara, we built a feedback box app for Haufe-Lexware.
|
||||
|
||||
Today is the last day spent @Haufe. And I must admit, this summer internship was simply awesome. My work colleagues were so friendly, they helped me when I was in trouble. And I didn't thought it's so fun to go to work.
|
||||
|
||||
Below, is a screenshot of the application we built during this intership, built with the Meteor framework. Meteor is a brand new framework, both front-end and back-end, which makes Meteor a great framework.
|
||||
|
||||
{:.center}
|
||||
{:style="margin:auto"}
|
||||
|
||||
This application is for internal company use and it takes a feedback from a user, post it on the site, and sort the feedbacks by the number of votes. Users can delete only their feedbacks, and the feedback can be modified only if there is no reply or vote.
|
||||
|
||||
The development process was a little bit tricky for us, and, furthermore, it was the first time we used Meteor to develop web apps. But, in the end, we proved that nothing is impossible, and if you truly want, you can learn new things anytime.
|
||||
|
||||
As you can see, this feedback box app has an user login®istration form, but, we restricted the account creation to the company email domain, haufe-lexware.com. After the user logs in, he can post and reply to the other feedbacks.
|
||||
|
||||
And when I say it was tricky, I mean, the support on the internet for docker and meteor was so poor. I've had a lot of bugs, the meteor pack for docker it wasn't at least official, and the problems we encountered, was already posted on the internet, with a lot of troubleshooting, but, nothing for our case.
|
||||
>>>>>>> haufe/master
|
||||
|
|
|
|||
79
_posts/2016-10-07-HackathonInsights.md
Normal file
79
_posts/2016-10-07-HackathonInsights.md
Normal file
|
|
@ -0,0 +1,79 @@
|
|||
---
|
||||
layout: post
|
||||
title: Project: B#1
|
||||
subtitle: Insights from the Freiburg Hackathon: New online Queue Management in Bürgeramt
|
||||
category: product
|
||||
tags: [Mobile, Open Source]
|
||||
author: daniel_wehrle, anja_kienzler
|
||||
author_email: daniel.wehrle@haufe-lexware.com, anja.kienzler@haufe-lexware.com
|
||||
header-img: "images/FR-hackathon-2016/2016_09_08_11_22_05_Hackathon_2016.png"
|
||||
---
|
||||
|
||||
A Hackathon is a kind of software prototype development marathon. This year the second Freiburg hackathon took place. The target was to develop an application for “Newcomers” to the city of Freiburg in 48 hours (Friday evening to Sunday morning). We accepted this challenge with the idea to create less-stressful way to manage the necessary administrative procedures at “Burgeramt Freiburg” (city government administrative services) for foreigners and employees alike with the possibility to extend the system to other official city departments at a later point.
|
||||
|
||||
### The technologies
|
||||
|
||||
Among newcomers, smartphones are more common than personal computers, and we decided to build an smartphone app instead of a website because the solution required personal user settings and an offline mode function which we shall address below. The project goals we defined were:
|
||||
|
||||
1. An online function for receiving a number (ticket) for a queue at one of the city offices. The application should also provide users with information about current waiting times so they are on time for their appointments. If you use this app, you should feel like you are the first in line upon your arrival.
|
||||
2. Retrieval of digital forms in various languages, including a checklist of the required documents and forms needed for “Bürgeramt” appointments. This ensures that you do not have to come a second time because you forgot something. This feature also includes a database of translated forms that are normally only available in German. Even if they have to fill out the German forms, newcomers may see the questions in a language they are familiar with.
|
||||
3. An App-UX that is easy to understand and comfortable to use even if the user is not always online.
|
||||
|
||||
Due to the short timeframe, our team had to make use of one technology that was known by the whole team, and so we also decided at very the beginning to develop in C#.
|
||||
|
||||
As platform options, we had Xamarin and Universal App and we decided to use Universal App because the team was also more familiar with this technology.
|
||||
|
||||
### Technical doing
|
||||
|
||||
The project was then split into the subprojects UX-concept, Data Layer, Office and Queue Management, QRCode Scanning, and Document Storage. One developer was responsible for one subproject. Several times during the Hackathon, developers switched subprojects.
|
||||
|
||||
### UX-concept
|
||||
|
||||
Working on the UX-concept and on the interface design started some days before the Hackathon. This allowed us to complete our UX-concept shortly after the event started so the developers could get the most out of the short timeframe of the hackathon.
|
||||
|
||||
The aim of the UX-concept was to make an interface that is easy to understand - the exact opposite of German bureaucracy. The user should always be guided to the best action, moving through the application in a few simple steps and reaching the desired goal quickly and easily.
|
||||
|
||||
To achieve the UX-concept, it was important to start from the user's point of view by reorganizing and resquencing the existing appointment categories of the “Bürgeramt” to meet newcomer needs.
|
||||
|
||||
The design is friendly and welcoming and supports easy navigation by using flat buttons and a clear menu prompt. Because of the app’s name, B#1, and the characteristic behavior (diligent and useful) the mascot is a friendly bee.
|
||||
|
||||
### Data layer
|
||||
|
||||
While the design was being finalized, the developers started on the data layer. This subproject is the major backend component, and the data layer holds all user data, offices, lines, advices (representations of Bürgeramt appointments) and requirements - like required documents - for these advices. Because advices are built in a tree structure we built in a self-reference from advice to advice.
|
||||
|
||||
{:style="margin:auto"}
|
||||
|
||||
A simple XML solution for the data, stored directly on the phone, was our first choice to get the version of this main component running quickly. This was important so other developers could start using data for our app very early.
|
||||
|
||||
The next step was to connect via WebService to a server and to update this data. The information should always stay on the phone to enable offline browsing of the data. Only the functions of receiving a line number, checking current waiting information and downloading documents should require an internet connection. This was clearly defined because newcomers often are dependent on Wi-Fi which is generally not available.
|
||||
|
||||
The offices’ addresses and required data were taken from the city of Freiburg homepage. For the demonstration, we implemented a test data generator to create the rest of the data (number of people currently waiting, next number in line and so on).
|
||||
|
||||
### Queue management
|
||||
|
||||
For each possible type of appointment, we set a fixed waiting time, in a later version, we will improve this by adding self-learning. For each office, we defined one FIFO (First in, First out) queue filled with waiting tickets.
|
||||
|
||||
By using the queue information, it was possible to calculate the current waiting time and the next ticket number.
|
||||
|
||||
#### QRCode scanning
|
||||
|
||||
To realize this function, we included the XZing.Net component Nuget package. The usage was very straightforward, the only thing that was a little bit tricky was to improve focusing of the phone camera. But in the end we figured it out.
|
||||
|
||||
In the QRCodes, we embedded the IDs that are associated with links to specific documents stored in our data layer. So for "advice requirements", we were able to use the same ID and link for QR Codes and associated documents and to avoid storing duplicate data.
|
||||
|
||||
The ID made it possible to change the storage locations for documents without needng to reprint the QR Codes.
|
||||
|
||||
### Document storage
|
||||
|
||||
Document storage was a nice to have feature which is why we started working on it last. We settled for a very quick solution. We only stored IDs (Used for QRCodes) along with http links to the documents so we could use cloud storage to address the documents.
|
||||
|
||||
Because we did not know at that point whether a centralized or an individual storage from the independent office should be used, the document storage solution functions with both local storage and remote storage.
|
||||
|
||||
### Conclusion
|
||||
|
||||
Getting a project done in two days is not an easy task. It requires great effort and teamwork. Building a team consisting of members from different Haufe Group departments is also not easy - especially considering that each member is busy with his/her own projects.
|
||||
|
||||
In the end, we completed the project and it was possible to produce a prototype within 48 hours. For this kind of a project, our takeaway is that you have to concentrate on the core functions and use as much external code as possible (Nuget, OpenSource Libraries etc.). Another takeaway was that it is good to have a finished design concept at the beginning of the project. The completed UX-concept helped guide our coding.
|
||||
|
||||
Freiburg Hackathon was a good challenge to learn new things and test our skills in a “new project environment”. We all liked the concept of the hackathon.
|
||||
Finally, we believe our idea is a good concept that will be a really nice, working product. Because of the short timeframe there is still a lot of work to do, turning many of the functions, that are right now “dummies”, into full-fledged features.
|
||||
48
_posts/2016-10-11_WindowsHello-2FactorAuth.md
Normal file
48
_posts/2016-10-11_WindowsHello-2FactorAuth.md
Normal file
|
|
@ -0,0 +1,48 @@
|
|||
---
|
||||
layout: post
|
||||
title: Two factor authentication with Windows Hello and Google Authenticator
|
||||
subtitle: Exploring new ways to make customer login more secure
|
||||
category: howto, product
|
||||
tags: [Security, Mobile, Open Source, API]
|
||||
author: daniel_wehrle
|
||||
author_email: daniel.wehrle@haufe-lexware.com
|
||||
header-img: "images\bg-post.old.jpg"
|
||||
---
|
||||
|
||||
Currently all of our Lexware “on-premise” products work, using the well-known user/password login authentication. But, in the last couple of years, new techniques for authentication have become available, and we tested some of these technologies - Windows Hello and Google Athtenticator - to make proposals for alternative authentication and authorization technologies for Lexware products - especially for our “on premise” products.
|
||||
|
||||
### Windows Hello
|
||||
|
||||
“Windows Hello” has been available since the release of Windows 10 and is integrated into Microsoft’s sign-on service “Microsoft Passport”. Windows uses this service to enable login by face recognition or by other biometric methods, like fingerprint recognition. The face recognition requires a special camera (“Intel RealSense”), consisting of two cameras for visible light (for 3D scanning), and one infrared camera, to ensure the face recognition is not run on a photograph. These cameras are not widely distributed across the laptop market.
|
||||
|
||||
I started to check and go through the information Microsoft provides for integrating “Passport” and “Hello” into applications.
|
||||
|
||||
I also started recoding the sample from the pages, creating a simple Universal Windows Platform (UWP) app that performed indentification by Face recognition - [See Sample on MSDN](https://msdn.microsoft.com/en-us/windows/uwp/security/microsoft-passport-login-auth-service). The sample was short and pretty straightforward. It contains a simple xml serialization framework that would need to be replaced by a more secure data layer for productive usage. But to get started it was a really good resource.
|
||||
|
||||
The next step I had planned was to transfer this sample from UWP into a normal desktop app. Here I was confronted with a show stopper: The Microsoft Passport and Windows Hello components were located in the WinRT Framework, but I planned to use the .Net Framework. I found a lot of information how to use WinRT Components in normal .Net applications - [e.g. on CodeProject](http://www.codeproject.com/Articles/457335/How-to-call-WinRT-APIs-from-NET-desktop-apps). There is also a [compatibility list](https://msdn.microsoft.com/en-us/library/windows/desktop/dn554295(v=vs.85).aspx), but Microsoft Passport and Windows Hello is not part of it, so there is no guarantee that it will work. After I finished the import I was faced with fact that it was impossible to initialize the Passport framework.
|
||||
|
||||
We verified this by asking our Microsoft contact, who gave us the same information: Hello was only supported for UWP, not for old style Windows applications.
|
||||
|
||||
After learning that not all WinRT features can be used in the .Net Framework we had to put the project on hold.
|
||||
|
||||
### Google Authenticator
|
||||
|
||||
Now we had go back and rethink about how this project was defined, the main goal was a more secure authentication. So we checked for other possibilities and remembered that there was a time limited token system from Google.
|
||||
|
||||
Time limited tokes are also known as TOTP (Time-Based One-Time Password Algorithm see RFC 6238). Those systems generate passwords that are only valid for a limited time, those passwords are also called tokens. Normally the generation of a token is limited to one hardware device. In the past, token generators were a small piece of hardware including an LCD display, showing the current token. Google Authenticator does not rely on dedicated hardware and makes it possible to turn every smartphone into a security token generator.
|
||||
|
||||
So I began to research how to use Google Authenticator with .Net. I found out that there are open source .Net Projects on [GitHub](https://github.com/brandonpotter/GoogleAuthenticator). I integrated those to my failed port of the Windows Hello app and was happily up and running with very low effort.
|
||||
|
||||
It was clear that biometric authentication can definitely make authentication more secure, and so I did a little more research on recommendations for secure authentication.
|
||||
|
||||
### Takeaways for moving forward with two factor authentication technologies
|
||||
|
||||
Two factor authentication can indeed bring a lot more security to applications. Data thieves not only have to get the password but also the token or biometrical information. And this information cannot be replicated as easily as a password.
|
||||
|
||||
But the technology that holds the second factor must also be secure itself. Windows Hello and Google Authenticator seem to be secure technologies. So it makes sense to use them as a second factor for higher-priority security issues. And, it also makes sense to use these technologies to build an up-to-date, secure authorization service. In any case two factor authorization should be adopted. Both technologies are easy to use, both for integrating into a software, and also from the customer-use standpoint. Like this, the security of an authorization process can be tightened with just some simple steps.
|
||||
|
||||
It’s too bad that Windows Hello does not work for classic desktop apps. Another drawback is that the availability of hardware (cameras) may limit the number of possible users. But, with Google Authenticator, there is an available technology that can be used on most smartphones and with all kinds of applications.
|
||||
|
||||
Two factor authentication may not be a requirement for each simple login. But at administrator login or for a task with a higher security risk, it makes much sense to perform a second authentication step, at least as an option for the user. This does not require more effort or extra steps from the users but does heighten the security for critical operations.
|
||||
|
||||
Since it only requires low effort to integrate and use, I would recommend this technology to every developer, to enhance security for their applications and make use of Windows Hello or Google Authenticator, and I am also proposing two factor authentication to our product management because it would definitely be a product-feature quick win for us and our customers.
|
||||
Loading…
Add table
Add a link
Reference in a new issue