Few weeks ago I was listening to a lecturer explaining how Salesforce works from programmer perspective. Among other things I have noted that SalesForce cares very much about their performance. They care so much that they have forbidden sequential access to the database. This is also why database access API are all designed to work with batches.
Power point, source code and resources from presentation are here.
I will be speaking at this year’s Sinergija.
Presentation is titled State of the art logging.
I just wrote another code project article -Attaching detached POCO to EF DbContext - simple and fast.
Simple generic extension method that will attach detached POCO to DbContext without reloading it form DB.
In my Code Project article “Demystifying concurrent lazy load pattern” I have explained what common mistakes in lazy load implementations and how to implement fast concurrent lazy load cache. In this post I will discuss why caching itself is important and what are some implementation strategies for caching.
Simply put... performance! Usual business application relies on lots of data, and that data usually resides in a database. Because data is out of the application thread, accessing it can be much slower. If external data is on a hard drive (and it usually is), accessing it can be thousands of times slower than accessing data in application memory. The great thing about cached data is that not only it will be few thousand times faster, but it will also scale much better under heavy load than your poor database.
Nowadays, cached data is becoming more and more important with the emergence of high load web sites with many concurrent users. In addition, we see the rise of distributed key-value databases acting as a shared cache.
In our application, we have increased the speed of a critical business feature, Order lines import, for about 50 times after data caching. Speed went from 1 row per second to 50 rows per second.
Sounds great, and best of all it is easy and it just takes a little caring about your data. Unfortunately, I have seen many problematic implementations of caching that will either occasionally break in production or have very low performance and those implementations are the main reason for writing this article.
I've took my article Demystifying Lazy Load Pattern published in Software Developer’s Journal 1/2012, polished it a bit, added review of System.Lazy<T>, implemented simulation app and published it on CodeProject.
Feel free to check out the article, rate it and play with simulation app.
I have written an article for Software Developer’s Journal 1/2012 titled “Demystifying Lazy Load Pattern”.
Here is the presentation material [download] [view online].
Also I have a some interesting resources for you.
I will be giving a talk on 19th October at this year Sinergija titled “Soprex framework on .NET in action”.
The target of this session is to cover leading ideas and basic principles behindSoprex Core Application (SCA) framework for building enterprise applications. I will cover some of the most important design decisions we made while building it. Some of them are:
- How we implemented Domain objects (entities) and why.
- What are we using for Data Access and why it is awesome!
- How Model-View-Presenter saved the day.
Thanks to Sorpex I had a great pleasure to visit this year TechEd
held in Atlanta. I got a chance to attend many interesting talks and
also meet the people from Microsoft that build the tools I have been
using for years. In the focus of the conference were the Cloud, Windows
Phone and Application Lifecycle Management.
Here are the most interesting sessions available online that I recommend
READ MORE >>
As I promised last night, here are the materials from my two presentations at Sinergija10:
- Unit Testing solid fundamentals [download] [view online]
- Advanced Unit Testing - real life examples and mistakes [download] [view online]
- Code samples [download]
I hope that in few days I will also have video recordings of these two sessions.
READ MORE >>
As some of you might already know I will be speaking at Sinergija10, Microsoft conference held 16-19 November 2010 in Belgrade, Serbia.
Last year I held two presentations
regarding Code Refactoring, Coding Standard and Code Review. This year
my presentations will be about Unit Testing (both on Thursday
Unit Testing solid fundamentals
Advanced Unit Testing – real life examples and mistakes
started happening while I was still at college. We students have
informally divided into two groups, us that were
constantly digging for more knowledge and them that
were telling us that we will just be stupid programmers. We wanted to
be great at software development, but they said that we will be zombies
staring at out monitors for the rest of our lives. They had different
future in mind for them, where they would be very smart without any
effort, work little and be very good paid for that. My favorite quote
from them was "I won't be a programmer, I will be a consultant
to other programmers" ... straight from collage. Imagine that!
Or "I will stay at the collage and teach others on
the advanced software development techniques"... techniques they have
some person you admire for what they have achieved in their
profession. Do you think they earned your respect by being talented or
with their passion and hard work? Do you think they were stupid to push
Albert Einstein was committed to his work but I never heard
anybody says that he was staring at formulas for the whole day. Nobody
complained that he was always lost in his taught or that his clothes
were always wrinkled. And what about Jimmy Hendrix, when
you think of him, do you think he was a freak locked up in a room all
day long with his guitar? What about Michael Jordan,
can you even imagine his commitment to basketball? Do you know he was
rated as untalented player when he was in high school?
In my previous blog post I have mentioned that most of our job candidates state in their CV-s that they work great under pressure. The thing is ... nobody works grate under pressure. The only difference between people is whether they break under pressure or not.
The pressure is something well known to probably every programmer, but
hopefully it isn't present every day. When I say pressure, I don’t
think of managers forcing programmers to code for long hours. I rather
think about situations when you must finish something that you care
about very much, but the situation makes it almost impossible.
This is often the truth for developers because we:
- have deadlines,
- do complicated things that are error prone,
- lack engineering practices and tend to throw the ones we got the first time we hit the wall
Because pressure is probably guaranteed thing, first thing we can do is
become aware of it. I have met two kinds of pressure: negative and
Last few months Soprex was hiring new people which also meant I had to:
- read a lot of CV-s
- hold technical interviews
- judge people
- neglect my regular duties
you can guess I wasn't too happy about it because I had other important
staff to do and I don't like judging people, especially not based on
some resume. But still, this is a small effort compared to potential
impact on our firm. Last thing you want to do is to misjudge people and spend few months getting them in the business to find out that it is not going to work out.
David Parnas said:
Q: What is the most often-overlooked risk in software engineering?
Incompetent programmers. There are estimates that the number of
programmers needed in the U.S. exceeds 200,000. This is entirely
misleading. It is not a quantity problem; we have a quality problem. One bad programmer can easily create two new jobs a year.
Hiring more bad programmers will just increase our perceived need for
them. If we had more good programmers, and could easily identify them,
we would need fewer, not more.