Being a good programmer is, of course, even harder. Unlike countless other jobs where the daily work is a routine, and being good at your job is to be efficient at that routine, being programmer is all about constantly learning and doing new things. Being a good programmer is about being fast at learning, and doing new things well. The process might stay for a while, but the content of the job is constantly changing. (If you keep doing same content over and over again, you are doing it wrong)
Why LOH? It’s a special heap contains the memory objects which are more than 85000 bytes in size – which, previously, never compacted (that was changed with .NET 4.5 when you have an option to compact LOH, but beware of the consequences).
If you know about the generation garbage collection in CLR, you already know that when an object is no longer used, its memory will be claimed back for later use. GC do more than that, by trying to compact the “free” memory – so it’ll move (via copy and delete) the survived objects next to each other, therefore you’ll be a big, continuous free memory. This helps improving performance in upcoming allocations, but only until a point. If the objects are too big, then the costs of moving the objects around might outweigh the benefits. Microsoft did a bunch of performance test and they decided that 85000 bytes is the break point, where the costs are bigger than the performance gain. Then we have LOH, where the memory is almost never compacted.
If you ask me what had I been doing the last two weeks – then the answer is I was pulling my hairs. A customer had a problem with their site as the memory hiked up after catalog imports and stayed there “forever” – and in the end it slowed the site down. I jumped in and almost regretted that decision – had to spent days messing around with WinDBG and memory dumps. In the end – I found the problem and it was fixed. A lot of hairs were loss in progress, but I learned something about WinDBG – and that’s what I’m sharing today.
WinDBG is probably the most famous tool for debugging stuffs on Windows. Out of the box, it only works with native applications, aka assembly and such – but lucky for us, there are plenty of extensions to allow it to work with .NET application. The “standard” SOS and more advanced extension SOSEX. SOS is included in WinDBG, while you can download SOSEX from here (for 64 bit) or here (for 32 bit) . Download the zip file and extract the dll somewhere.
WinDBG comes with the Windows SDK, not the standard .NET framework, so you’ll probably need to install it separately from here
Then what is a branch in Git, actually? A branch in Git is simply pointer to the hash of a commit (which will be the HEAD commit of that branch), and a name of your branch, of course. That means creating a branch in Git is extremely cheap and is almost instantous.
Now if you look back at the branch tree in Git Extensions, you will see a linear tree. (It’s not something you usually see in your working environment, but we’re new anyway.). You can see that the name of the branches and the commit message are in bold.
For the commit, it means the commit is the HEAD commit of a active branch. A commit will always point to it parent (or its parents, in case of a merge). When you know the HEAD commit, you can know how does your branch look like, down to the initial commit (which has no parent).
Sometimes, you make a mistake committing something. A file can be missing, or the indentation is not perfect, or you had a typo in your commit message. If you are using some other source control softwares such as Team Foundation Server you’re done with that. The only option you have is to check in another change set to fix your previous one (in case you have a typo in your commit message, be done with that). Git is so much more powerful in terms it allows you to rewrite history.
To fix a commit, make a change, then commit as usual, but this time, Select the “Amend commit” checkbox:
The war of version control systems was over. Git has won. And that is not an over-statement. CSV, SVN, TFS were the past. Mercurial was close, but GitHub put the end of it. The popular of open source platform makes Git an unambiguous choice for almost every developer in the field . Even BitBucket, the service which once known for Mercurial, supports Git for now. If you start a new project today, Git should be your first and foremost option – well, unless your boss says otherwise.
Recently I stumbled on a tutorial named Learn git in 30 minutes. While there is nothing wrong with that tutorial, it’s actually pretty accurate, and clear and easy to follow – thumbs up to the author about the writing – I have great concerns about how should we learn Git.
Git is not that easy.
Don’t get me wrong, Git is a great tool, perhaps the greatest developers’ tool since C language. Where I work at, we switched from Team Foundation Server to Git two years and a half ago, and I’ve never looked back – Git does things right where TFS did wrong. It really helped my life, as a developer, easier.
But everything comes at a cost.
As powerful and flexible as it is, Git is also complex and easy to mess up. It can be your best tool, but it can also be your worst nightmare, when something goes wrong.
Back when I was young and mostly stupid, I discovered StackOverflow. The site struck me hard. There were a lot of “Wow” moments for a third year student. I still remember the first time I asked the first question, then even think about the questions to ask (so I can gain some precious reputation – yeah, I was young and stupid, remember?), and the first time I tried to answer a question myself.
It has been a long time since those days.
I still use StackOverflow, even at this very moment. But it’s on demand, instead of browsing it everyday as a habit. I search for a question, read the answer, possibly vote it up, then leave. Sometimes, when I have absolutely nothing to do, I try to review the suggested edits from other users. And that’s it.
Today I updated our TeamCity server from 8.15 to 9.17. We need to support C# 6.0 so it’s an essential move. TeamCity 10 is still EAP and we would wait a couple of months after it comes out to make sure all the plugins are supported.
The installation was a breeze – the installer detected there was a previous version and offered to uninstall it. All good. Until there was a browser window opened so I can continue the configuration, but http://localhost/ only returned time out.
When I opened the Service Management (services.msc), it looked like the service was not running. I tried to start it, but then it stopped immediately. Events viewer was not exactly helpful, it gave a very obscure information:
The description for Event ID 404 from source TeamCity (see below) cannot be found. Either the component that raises this event is not installed on your local computer or the installation is corrupted. You can install or repair the component on the local computer.
If the event originated on another computer, the display information had to be saved with the event.
The following information was included with the event:
=============================================================== TeamCity JetBrains JetService v1.1.755.777 c:\TeamCity\bin\TeamCityService.exe Service process exited without service stop request =============================================================== Continue reading “Upgrading to TeamCity 9.x: the JRE headaches”
There’s a enormous number of books out there – (even I am writing a book!), so choosing the right books to read can be a difficult task. Yet it’s important because our spare time, is very limited: we still need to eat, sleep, socialize, take care of family and kids, while we have to spend significant time to write code and solve problems. How to get the right book and not regret spending time reading it?
There are many good books – but it’s best to categorize them into smaller groups:
Is the book beginner-level, or does it require some experience to digest?
Will the content be still largely relevant after ten years, or will it be obsolete in just next few years?
Is it a book to read from cover-to-cover in one sitting (just kidding, I mean you should finish it when you start it), or to read chunk by chunk (read a chapter, stop for a while, read another chapter), or keep it around as a reference?
I have this criteria to categorize books myself:
Good books: A book which is on-topic and with accurate information, and in an easy to read and easy to follow style, the author(s) deliver their promises.
Great books: Good books give information. Great books raise questions. A good book becomes great when it makes readers think – not only about topics mentioned in the book, but also the bigger picture.
Legendary/Classic books: Great books which stand the time and still be useful after 10 years, or even longer. These are truly gems of their own and should be read, regardless of the topics. The topics might be obsoleted, but the thoughts/ insights are still relevant. They are battle-tested and no matter which field you are working on, you’ll still learn something from it.
Books you really should read
C programming language, 2nd edition
Not everyone works with C (myself included), but this book is still recommended over and over for developers. The book is pretty small, and indeed very easy to read and follow – it is widely accepted as one of the best programming books ever written, in terms of writing quality – and it provides a view of what is a function, how a program works, how are things connected to hardware-level …
If you ever write a programming documentation – and you will – make this a reference for writing style.
Code Complete, 2nd edition
This book is considered must read for everyone, especially those who are new to software development, and re-read after a while. It’s a big book contains almost everything you should follow when you’re in the software industry – coding convention, naming, how to structure your classes … Get a copy and read it from cover to cover, if you haven’t, and re-read after 3-4 years to see how much you learned from it.
The Pragmatic Programmer: From Journeyman to Master