The amount of languages, frameworks, 3rd party libraries and tools is staggering. And every place of work uses a unique permutation of those.
As developers, we have to stay on top of things, no two ways about it.
Once we’ve decided we want to learn a new technology, we have a lot of ways to approach that. Especially with the burst of information nowadays. There’s no clear answer as to how we learn something. It depends on the technology itself, how deep you need to learn it, how much time and money you have to spend on this and personal taste.
In my previous company, we experienced a reoccurring nightmare. It went something like this:
New critical bug arrived from QA:
Program suddenly crashed. Reproduces 1 / 10 times. Reproduce steps – unclear.
The development team, after realizing they are unable to reproduce the bug on their development machine would claim the bug doesn’t reproduce, moving the ticket back to QA.
In return, the QA team reproduced the bug, moving the ticket back to dev.
Then, the development team would claim another layer of the code caused the bug, moving the ticket to a second development team maintaining that code.
The second development team, with spite, would find an obscure line of code in the log file proving the bug is actually not in their layer of code, moving the ticket to the original dev team.
This would go on until either the development team succeeded in moving the bug to backlog or, in rare cases and by sheer luck, the development team was able to solve the bug.
In our defense, All the coders who originally built the system were long gone, the application was huge and complicated.
I guess not much of an excuse but eventually we learned some tricks to help us solve those pesky crash bugs.
Well, some developers learned. Others kept claiming the bug doesn’t reproduce 🙂
Introducing our bag of tricks:
In WPF we define a UI resource system (mostly in XAML resource dictionaries) which includes colors, templates, icons, styles and so on. Sometimes, we need the ability to change our application’s look and feel dynamically, allowing different Themes or Skins.
We might have Shared resources for all Themes and Dynamic resources based on the current Theme or Skin.
The following article talks about the different ways to build a theming/skinning infrastructure in a WPF application.
How the annual review scores are formed in the eyes of managers always fascinated me. I have five years of experience with annual reviews myself, and I was always able to do well on them.
As a tech lead I got to give recommendations and participate in some discussions with managers. I formed a pretty firm and possibly naive point of view on them now.
WPF is very dynamic and allows us to use resources in many different ways. We can use Static or Dynamic. We can place all our resources in App.xaml or use merged dictionaries each time.
You can see all the approaches and what I think is best practice in my WPF Merged Dictionary problems and solutions post.
If you’re new to WPF resources, I suggest reading my Explicit, Implicit and Default styles in WPF post before diving into this one.
This benchmark is supposed to show, in numbers, how any approach affects performance.
Here’s what I want answered with this benchmark:
- Is splitting resources in App.xaml to many Merged Dictionaries file vs. one long App.xaml file means longer application startup time?
- Is loading all resources in App.xaml once better than loading the resources every time with merged dictionary?
- Is DynamicResource instead of StaticResource an issue? How big of an issue?’
Did you ever feel like Visual Studio is rebuilding projects every single time, even when there were no changes to the code?
We can build, change nothing, build again and there we go… VS is starting a build instead of saying all my projects are up to date.
Also, there’s that nagging feeling that even when we do change something, VS is building way more projects that it needs.
Like most things I do in life, frustration led me to look further into this matter.
After working for the last three years with TFS’s classic source control TFVC, I recently moved to a new company and with that, to Git.
Before working with Git, I loved working with TFVC. I thought it was great and pretty much the most I can expect from a source control.
Git however changed the way I work with source control and even the way I think about source control.
This post is a small taste of what Git does and how my workflow changed accordingly. It is not a Git tutorial, but rather my impressions from it. I do link at the end to some additional resources.
After a relatively short time looking for a job, I joined my a new company: CodeValue.
Specifically, I’m working on the OzCode project (which is awesome).
But a bit later on that… First let me tell you a bit about my job hunt experience.
After three years and three months in Cellebrite, I decided to leave the company and pursue other challenges.
Cellebrite was a great place to work at with great people and I enjoyed my time there.
This post is a recap of my time in Cellebrite and why I eventually decided to leave.
I started a software developer in a team of 6, working on a large WPF application. After working in a startup company, I was impressed on how professional and orderly everything was. We had TFS work items, we had a build machine, we had an installer to create our Setup files, we had update distribute system. I was truly impressed.
In-office Nerf wars
When starting with WPF, I had a hard time realizing when to use converters and just how powerful they can be. I would often create styles with complicated Data Triggers, or abuse my ViewModel instead of doing some simple converter magic.
I’ll share with you some converter tips and tricks that make my development easier every day.