I’ve not written anything here for more than a month and I’d like to make a short off-topic post to explain why. In the end of May our third kid arrived to the family. He’s a healthy little boy, but even though he’s still small, he’s wreaked havoc to my ability to plan my time. Just as it is supposed to be. But that means blogging hasn’t been on the priority list.
I’m living in Sweden, where the possibilities to spend time with the kids (even as a dad) is totally awesome. It’s easy to take things for granted and it’s not until I discuss how to balance family life and work with people from other countries that I fully remember just how awesome it is here.
The biggest thing is the parental leave. For every child the parents gets 480 paid days to stay at home and care for the child. Counting only work days, that is nearly two full years of paid leave.
The thing that usually surprises non-Swedes the most is that those paid days are not tied to the mother, but to both parents. Actually 60 days are non-transferable, meaning that if the dad doesn’t use them, they are void. Personally I’ve been staying at home with my two older kids for about half a year each and I plan to do the same with the baby, once my wife get back to work. Oh, that’s standard in Sweden too – Mothers are usually working.
When she returns to work, it’s my turn to stay at home on state pay. But, there is actually a limit on how much the state pays for during parental leave. The maximum pay is about €100/day (before tax) and salaries in the IT sector are often much higher than that. But as I’m working at a generous company they actually fill in on top of the public payment, so I get 90% of my salary for spending 6 months with my son. That’s awesome (did I mention we’re hiring?).
Once I get back to work, my son will go to daycare. Children in Sweden usually start daycare from somewhere between age 1.5-2 years. Daycare is heavily subsidized. We pay about €120/month per child for daycare. That’s roughly 10% of the real cost. On the other hand I can confirm that the rumors are true: We do have high tax levels in Sweden, but in my opinion we’re also getting a lot back.
For now this means that I’m taking a long summer off and spend the time with my family. There will probably be blogging done, but not as frequently as when I’m working.
Distribution of credentials to new users of a system is often done in an insecure way, with passwords being sent over unsecure e-mail. With ASP.NET Identity, the password recovery functionality can be used to create a secure account activation mechanism.
The scenario for ASP.NET Identity, in the default MVC template is to let users self register. Then there are mechanisms to confirm the e-mail address, to make sure that the user actually is in control of the given e-mail address. There are also support for letting the user associate the account with external sign on solutions such as Google, Facebook and Twitter. That’s perfectly fine, but not for most applications I build.
I’m building line of business applications. They are actually often exposed on the Internet as they need to be available for partners. But, they are not meant to be available through self registration for anyone on the Internet. Those applications are invite only. That means that a user account is created for a new user. Then that user somehow has to be notified that the account has been created. The usual way to do that is to create the account, set a good password like “ChangeMe123″ and send the user a mail with the new credentials. There are two problems with this
- A lot of users don’t get the hint and keep the “ChangeMe123″ password.
- The e-mail can be sitting unread for a long time in the inbox, until someone gets hold of it – and the account.
Fortunately, there is a much more secure way to do account activation with ASP.NET Identity without much coding at all – by reusing the password recovery mechanism.
This is a guest post by Albin Sunnanbo, introducing a burst filter preventing log4net from filling up a support mailbox.
One Friday afternoon, just before leaving for the weekend, I glanced at our support mail inbox.
The unread counter was literally spinning. Three mails a second.
To make a long story short we had two problems.
A lost db connection due to a DNS failure.
A mail logger that tried to nuke Outlook into oblivion. A mail logger that took a while to stop because we could not reach our server due to the aforementioned DNS failure.
This incident taught us two lessons. Write down the IP addresses of all your servers and throttle your logging.
That project mentioned above used Enterprise Library Logging block.
When starting a new project I decided to try log4net for logging. I also decided to not repeat previous mistakes.
So you created an awesome pull request with a couple of features, but the evil(?) maintainer (could be me) just denied it and said you shouldn’t make pull requests from master? Then you’ve come to the right place to learn what went wrong and how to fix it.
Current (Incorrect) State
Looking at the history of your repository, it probably looks something like the image to the right. There’s a base commit and then you’ve added one commit for each of the features to it. And everything is done on the branch
The image was created with Git Extensions. Although I prefer using the command line when working with git, having a tool that can display the branches and commits graphically is indispensible to understand what’s happening.
Doing everytying on
master as shown in the image is wrong for a couple of reasons that might not be obvious when first starting working with git.
- Every single feature should be created in its own branch. Branches are so lightweight in git that it’s okay to branch all the time.
- Submitting a pull request from your own
master branch is a recipe for disaster, as it effectively prevents you from getting the latest code from the upstream repository (more on that later).
Unfortunately it’s easy to end up in this situation with git. Fortunately, it’s also quite easy to fix.
It’s call for papers season and I’m preparing abstracts and sending them off hoping that I’ll be accepted with my talks. What surprises me is how huge quality difference there is between different conferences in their call for papers (CFP). It’s basically anything ranging from very detailed information to a
I still have quite limited experience in submitting to conferences (and even less experience of being accepted). But when looking at what’s in a good CFP I think that is actually an advantage. A seasoned speaker will know how to write an abstract and what to expect – and what to demand(!) from the conference organizers. Someone less experienced need more information. To get relevant content and a wider selection of speakers it should be in the interest of conference organizers to have a good CFP.