|
I think C# is a good programming language.
I think that for a new language to stand the test of time, it needs to provide something that "we" can't live without.
|
|
|
|
|
I think C# is a very well designed and implemented language.
Even a bad language can stand the test of time if there is little competition from other languages. To this list I would add PHP. An absolute monstrosity of a language, but gained widespread traction and adoption as there were few web languages around at the time. If PHP was invented today, nobody would use it.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I was recently tasked with the problem of preventing users from clicking a button multiple times. This was on a login form whereby if the form was taking longer than normal, the user would click again....and again repeatedly. Whilst there was no impact on the product as such and no exception was thrown, it did register the fact the same user was logged in multiple times within the product.
There are times however when a user clicking repeatedly on a button can have far more adverse affects, such as posting a transaction or an update more than once, leading to inconsistent data.
There are several ways of solving this problem, but this one seems the most straight forward and simple to implement.
Firstly, you will need to add a fake button to your page. This fake button is what the user will see on the page. The original button will be hidden. The user clicks on the fake button. The text on the fake button is changed to indicate that the button has responded, and the button is immediately disabled.
To achieve this behaviour firstly add a fake button to your form as in the following example.
<%----%>
<asp:Button ID="login" runat="server" OnClick="Go" />
<%----%>
<input type="button" id="visibleLoginButton" value="Login" onclick="DisableButton(this)">
Now you need to add some Javascript to the page that will update the text on your fake button, disable it (so it won't get clicked repeatedly) and invoke the click event of your original button.
<script type="text/javascript">
function DisableButton(b) {
b.disabled = true;
b.value = 'Submitting';
b.onclick = document.getElementById('login').click();
}
</script>
Finally you need to hide your original button. Most people would naturally set visibility to false, but this won't work. The reason is that the form will only post back elements that are on the form. An element that has visibility set to false wil not get posted because it is not contained on the form. The trick is to set the display to none. This should be done in your form's Page_Init() event.
this.login.Attributes.Add("style", "display: none;");
And that's all there is to it. Happy coding.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I came across this article[^] and found it quite interesting. As usual with these sorts of articles, some of the items you will agree with, others not so much.
Missing from the list (in my opinion) is a greater emphasis on cross-development tooling for mobile. These are development tools that allow you to target multiple mobile platforms e.g. iOS and Android. I have previously used Xamarin[^] but there are others, and with new tools being developed. I predict that in 2016 there will be new and improved tools for those wishing to develop apps for multiple mobile platforms.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
We often hear software developers talking about "clean code", but what exactly does it mean? How can code be clean? Presumably you don't take your code to the shower for a wash, so how can code be said to be clean?
There are a great number of articles and blogs on this subject, and there is even a book on the subject, so clean code is obviously an important topic in the world of software development. During interviews it is something that I try to look for (by asking the candidate to write some code, by checking their on-line source code repositories e.g. Github etc).
There is no single definition of the term, as it encompasses many different elements, and there will also likely be disagreement and discussion as to its definition amongst software developers. This list is therefore my own definition. If you have any comments please feel free to leave a comment below.
Clean code should adhere to the following constraints:
- Variables, functions, events and properties should have meaningful names so that their intention is unambiguous and obvious e.g. calling a variable x or y is not allowed.
- Proper use of comments. I know that this single statement will have opened up a can of worms by itself (software developers do love their religious wars) but what that means is to leave comments where they clarify and add useful information to aid in the understanding of a piece of code. How you define that is up to you (but please do so consistently).
- Low coupling and high cohesion. I won't explain what these are, as I am assuming that the reader already has an understanding of software development principles. All functions within an application should be independent and not rely on any global state. All dependencies should be passed via parameters and they should perform one and only one task, and perform that task well.
- Clean code is simple and well engineered as opposed to complicated and over-engineered. Whilst it is great to understand design patterns, object mappers etc. you probably wouldn't use them in a simple console app for importing your payroll data. Understanding good design is important, but of greater importance is knowing "when" to use them. Cluttering a very simple application with design patterns, object mappers and the like just makes the whole thing difficult to comprehend.
- Good levels of re-factoring. If you see the same code repeated all over the place then it is clearly breaking the DRY principle (Don't Repeat Yourself). If you find yourself writing the same code more than twice (although some would keep this at one) then you need to refactor the code into a function and call that function instead.
- Another developer should be able to quickly (relatively speaking) understand what the code is doing and make modifications. If the code is so incomprensible that it takes your average developer an increasingly long time to make sense of the code, then clearly the code is not intuitive. In the same way that we strive to make our user-interfaces as intuitive and self evident as possible, so we ought to strive to reach the same ideals with our code.
Writing good code takes practice and skill. It takes effort and attention to detail. This final quote from Michael Feathers best sums up the definition of clean code.
Quote: Clean code is a code that is written by someone who cares.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
This article[^] describes how software engineers at Yahoo have moved away from using QA teams, and do all their own testing.
This rings alarm bells. Whilst I agree that increasing the level of quality from the development team is a smart move, I can't see how removing the QA team leads to an increase in software quality.
Unit testing was never meant to replace QA, it is a tool to give the developer the ability to exercise their code so they could automate it and run it under various scenarios and edge cases to ensure it handled them all correctly.
But that's not the whole story. As a web developer, my UI needs to be consistent with the rest of the application and I need to handle failures and omissions in a consistent manner for example. Having my code tested by a domain expert who has vastly greater knowledge of the domain area will ensure that my code enforces all the domain rules.
Having your code tested by an independent QA team isn't rocket science. It gives a level of verification above and beyond what a developer can achieve on their own.
Are Yahoo's software engineers coding without a safety net or without a clue? Only time will tell.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
IntroductionAs a design standard where I work we allow users to click on the label of a control which sets the focus to the control associated with the label. For example if there is a label with an associated textbox, then by clicking on the label, this will set the focus to the textbox in the same way as clicking directly on the textbox itself. We use this technique for all input controls such as dropdowns, checkboxes etc. This is a very simple behaviour but makes your web forms just that little bit easier to use.
Setting focus to an associated control
There are two ways you can achieve this behaviour. You can either use an HTML label control or an ASP.NET label control. Both can be used to achieve this behaviour.
Using an HTML label control
Using an HTML label you need to specify the for keyword when declaring your label control.
<label for="<%= this.textbox.ClientID %>">I am a label</label> Use the for keyword to specify the associated control i.e. the input control that is associated with the label. In the example code here I have associated the label with a textbox control. Therefore if the user clicks on the label the textbox gets the focus.
Using an ASP.NET label controlYou can achieve exactly the same behaviour using an ASP.NET label. You need to specify the AssociatedControlID keyword when declaring your label control.
<asp:Label ID="textboxLabel" runat="server" AssociatedControlID="textbox"></asp:Label> Use the AssociatedControlID keyword to specify the associated control i.e. the input control that is associated with the label. In the example code here I have associated the label with same textbox control as in the previous example. SummaryThis is a very simple tip but makes your forms that little bit more usable for an end-user.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
modified 16-Dec-15 1:13am.
|
|
|
|
|
Here's an interesting article[^] from Google employee Paul Lewis who works on the Chrome Developer Relations Team.
His contention is that Javascript frameworks are primarily aimed at making the life of the software developer easier, rather than providing any real benefits to the end-user.
He may be a well respected employee from the mighty Google, but I find his contention to be wrong. For starters, as anyone who has ever worked with Javascript will tell you, it is probably the most idiosyncratic scripting language out there. Saying that a framework built using this quirky and idiosyncratic language is purely to increase the developer experience is risible.
Frameworks are merely abstractions that make using the underpinning technology easier by proving a consistent programming paradigm. This obviously provides developer benefits by abstracting away the underlying details of the technology, but also by ensuring the code is more comprehensible and therefore more maintainable by enforcing a set of standards and a consistent programming paradigm.
This in turn ensures that new features can be more easily added and that bugs can be fixed more quickly precisely because a framework was used. This is obviously good for the end-user.
Javascript is the language of the web, and so its use is ubiquitous and mandatory. Therefore its use is not up for discussion. Therefore the discussion needs to be centred on both making its use easier for the developer, whilst also ensuring that the end results are acceptable to the end-user experience.
One thing that I do agree with is this final comment from Paul Lewis.
Quote: Using a framework is probably a good idea, but it’s an even better idea for developers to ensure they’re savvy about what the frameworks are trying to abstract.
I think that's something we can all agree on.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I read Uncle Bob Martin's Programmer's Oath[^] with interest and thought it would be useful to add a few of my own to the list. So here goes.
I promise that:
1. I will ensure that the software can be built and deployed using a repeatable and fully automated process
2. I will always employ best practice when developing software and make use of design patterns whenever appropriate
3. I will develop software in an ethical manner such that it does not compromise either my integrity or that of my employer or damage the reputation of either
4. I will willingly pass on knowledge to that of my colleagues, be they fellow developers or colleagues from other parts of the business
5. I will take constructive criticism in the spirit in which it is intended to ensure that I improve as a developer
6. I will always make a stand for quality to ensure the highest standards are met
7. I will represent my profession in the best way that I can and to be an ambassador to my profession
8. I will strive to ensure that the software I create and the process that produces it will be to the best of my abilities
9. I will strive to ensure that the software I create adds value to the business and to put the needs of the business at the heart of any technological decisions I make
10. I will use the most appropriate tools and technologies when developing software
11. I will make every effort to ensure that myself and other developers abide by this (and the original) Programmer's Oath
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
In this article[^] three architects explain the age old question of how do they balance the need to have a broad technical knowledge with having to simultaneously be an expert in certain specific technologies. For example, as a software architect you may be working on a project that consists of a Unix server running a COBOL application that needs to communicate with a set of web services that are needed by the front end e-commerce application written in PHP. To work on a project such as this you obviously need a broad general knowledge of each of the underlying technologies, as well as a deeper knowledge of those you will be working closely alongside.
I won't repeat the advice in that article (as you can read it for yourself), however, it reminded me of the point I was making in one of my earlier posts titled Seniority and T-shaped[^].
In that post I describe the concept of being a T-shaped individual i.e. one that has broad technical knowledge combined with a deeper understanding of a particular technology. Having a broad technical knowledge is obviously essential, as you can quickly get a helicopter view of the solution and see how the various components inter-relate. This needs to be coupled with a deeper understanding of the specific technology at hand, so you are able to make appropriate decisions that relate to that technology.
So to be a good software architect (although this applies equally well to developers and designers too), you need to be T-shaped. Someone who has a broad understanding of IT in general, coupled with a deeper understanding of at least one specific technology.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Dominic Burford wrote: Someone who has a broad understanding of IT in general
Dominic Burford wrote: deeper understanding of at least one specific technology.
and in my honest opinion; this only comes from years of experience.
|
|
|
|
|
Slacker007 wrote: and in my honest opinion; this only comes from years of experience.
And I would agree completely 
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
After reading this article[^] on the management style of Linus Torvalds, the creator of the Linux operating system, you'd be forgiven for checking the date to check you hadn't been transported back to a time when workers had few rights and their employers could treat them as badly as they wanted with impunity.
The fact that this sort of anachronistic, bullying behaviour still exists is a tragedy. The fact that someone as high profile as Linus Torvalds is guilty of such behaviour is an even bigger tragedy. And not only that, but his bullying, intimidating style of management has set the tone for everyone else who works within the Linux kernel community. The Linux kernel community is a toxic place to work, where tearing people down in public is the norm.
The modern workforce has no place for such people or their styles of management. What Linus Torvalds doesn't realise is that this is not the way to get the best out people. No one rises to greatness because they were publicly humiliated. No one becomes inspired because they were verbally bullied.
Linus Torvalds openly admits that he doesn't care for people, he only cares about the technology. That's fine, in which case he should immediately stop having any dealings with those people for whom he doesn't care. He should delegate someone else with better people management skills (which shouldn't be difficult) to do the job, and let him focus on the technology.
What he fails to grasp is that he has probably prevented many top programmers from coming anywhere near his product as they (rightly) don't want to work for a bully in a toxic environment.
Linus Torvalds may be a driven, motivated technological genius, but where he fails so spectacularly is as a decent human being. It costs absolutely nothing to be considerate and respectful to those around you. These are the basic traits you expect from someone else, and so should likewise be the way you treat other people.
It also doesn't endear you to anyone. No one is going to go the extra mile for someone who doesn't have their best interests at heart. In business terms, you will quickly be isolated as no one wants to do business with you (evidenced by his rant at NVIDIA the graphics giant for not providing decent support for the Linux operating system). You will also lose top talent, as evidenced when Sarah Sharples left the Linux kernel community as she could no longer work in such a toxic environment.
So his management style has isolated him within the wider technological community, and lost him top talent too. If that doesn't speak volumes then I don't know what does.
So even if it was only for purely self interested reasons, being a decent human being wins the hearts and minds of those you want to do business with, and they will far more likely be willing to help you realise your vision.
If you treat people poorly, then don't complain when they don't want to help you any more.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Dominic Burford wrote: If you treat people poorly, then don't complain when they don't want to help you any more.
|
|
|
|
|
Having read the the following article[^] I can't quite make up my mind if the article is simply clickbait or if the author genuinely believes the position they have described. I will give them the benefit of the doubt and assume that they are being genuine.
The article certainly is lengthy and the author could easily have made the same point using half the words, but let's forgo that for the time being.
The main gist of the article is that programmer are not engineers and should stop calling themselves engineers (as in software engineers). I think we can all agree that there have been a lot of high profile failings that have been attributed to software failings, especially in the area of data security breaches (I will take huge exception to the example of Volkswagen though. This was an example of corporate fraud mandated by those at the very top of the Volkswagen pyramid, and not the lowly engineers at the bottom).
Those examples aside, to dismiss those people who create software for industries such as aircraft navigation or nuclear power plant safety where mistakes in the software can be fatal is insulting. Or those working in the banking and finance sector who ensure our mortgages get paid on time and that we can get to our money on any high street. I could go on, but the point is that there are a great number of people working in the software industry who develop robust and fault tolerant software. Who use industry best practice and write software of the highest quality as the consequences of doing anything less would be catastrophic.
I'm not sure what underlies the author's stance, but they are wrong. They are perfectly entitled to their opinion, but it is one that I personally do not share.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
In his book The Art of Unix Programming[^] Eric Raymond proposed the Rule of Modularity.
Quote: Developers should build a program out of simple parts connected by well defined interfaces, so problems are local, and parts of the program can be replaced in future versions to support new features. This rule aims to save time on debugging complex code that is complex, long, and unreadable.
The Rule of Modularity is at the heart of Object-Oriented Design. Decomposing complex problems into a succession of smaller and more comprehensible problems which a human brain can reason about. Abstraction and encapsulation are fundamentally ways of managing complexity, and both have their roots in the Rule of Modularity.
The human brain is not yet evolved to tackle complex problems head on. A brain that was originally wired to hunt and build simple tools continues to struggle to fathom the complexity at the heart of software development.
The Rule of Modularity and the book from which it is derived is as relevant today as it was when first published over a decade ago in 2003. The book describes many of the ideas and wisdom from the early, pioneering days of computing dating back to the late 1960s and distills them into a book that is applicable to modern software development.
Software development is concerned with solving problems, and these can often be big, complex problems. Ultimately this means managing complexity. It shouldn't be in the least bit surprising that any mechanism that allows a human brain to manage this complexity should continue to be so successful.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
I have written an article previously on the topic of Domain-Driven-Design[^] (DDD) and so was intrigued when I came across this free condensed version of Eric Evans's book called Domain-Driven-Design Quickly[^]. Having just finished reading it I can recommend it to anyone wanting to learn about DDD but may find reading the original book by Eric Evans a little daunting (it's around 500 pages so not a quick read).
For those people who have already read the original book, it provides a very useful summary of the book. It doesn't assume that you have read the original book or have any familiarity with DDD at all.
I found this book to be a very useful summary of the original book by Eric Evans. If you are serious about learning DDD then I would highly recommend you purchase a copy of the original DDD book by Eric Evans. If you have already read the original or just want a concise summary of the main ideas of DDD then this is the perfect book.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Nice. I subscribe to your blog, thus I am notified when you post something new. Keep it coming.
I know nothing about DDD, but have heard about it. I think I shall look at this further. Might help my team and I out with some issues for future work designs.
|
|
|
|
|
Quote: Nice. I subscribe to your blog, thus I am notified when you post something new. Keep it coming.
Ah you're the one
Glad you enjoy my posts.
I've been looking at DDD for a while now, and can definitely see its value. It's not a design pattern or design methodology, it's a way of modelling your software so that its a true reflection of what the domain behaviour. You develop software in conjunction with domain experts. You share a common language to ease common understanding. Your software should be easily understood by anyone with similar level of domain knowledge.
The good thing about DDD is that it doesn't require any new tools or technologies, just a different approach to designing your software.
I'd definitely recommend looking into DDD and see what benefits it can bring to your next project
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
There is a well known story that about a woodcutter who stops periodically to sharpen his axe will. This woodcutter cuts down more wood than the other woodcutter who doesn't. By periodically sharpening his axe, the woodcutter is more productive than those that keep on cutting without stopping, as eventually their axes become blunted over time and they become less efficient.
A similar analogy can be made with software development. The analogy being that the developer who periodically stops writing code to research new ideas will be more productive than the developer who doesn't.
There are many ways of keeping your skills up-to-date. Here are just a few.
- Reading articles
- Writing articles (if you understand it well enough to describe it, then you understand it)
- Contributing to communities, forums, open-source projects etc
- Using social media to keep abreast of what's happening e.g. Twitter is great for this
It's important that it doesn't become a chore. Keep it fun and you'll keep doing it. I try to spend a little time each evening reading around various articles that I find on Twitter. I also enjoy wrtiting technical articles. Not only do I enjoy the warm fuzzy feeling of passing on my knowledge to
others, but it also forces me to research a subject and thus increase my knowledge.
Keep it fun and make it a regular part of your daily routine.
Remember.....keep your axe sharp
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Agreed.
Doctors and nurses have to keep their skill set up-to-date as well.
|
|
|
|
|
Absolutely, many other professions need to keep their skills up to date. Sometimes this is a professional requirement as it is with medicine.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
Following on from Truths about software development Part I[^] and Truths about software development Part II[^]
1. If I had a pound (dollar) for every time I heard the phrases "How long will it take" or "How much will it cost" I'd be a very rich man. Good job I'm not waiting to hear the phrase "How about the quality"
2. You will always think of a better solution to the problem you resolved 5 minutes after it gets released to the customer
3. You look at code you wrote just last week and wonder what the hell you were thinking
4. There is always that one developer who writes awful code no matter how much time they have to write it
5. No matter how much effort you put into staying current you'll always be asked about that one technology you haven't got round to looking at yet
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
|
I think there is a subtle difference between staying current and improving your knowledge. Admittedly both allow you to gain new skills and / or knowledge, but whereas one builds on your already existing knowledge, the other brings you new knowledge.
For example, I have read Eric Evans's excellent book on Domain-Driven-Design recently, and it made me look at software development and architecture in a whole new light. That was improving my current knowledge because it built on top of my already existing design and architectural knowledge. I have also recently been learning Node.js, which is staying current, as I am new to Node.js and don't have any previous knowledge to build upon.
It's important to keep building upon your existing knowledge, as well generating new knowledge. Good software developers need to do both.
"There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. The first method is far more difficult." - C.A.R. Hoare
Home | LinkedIn | Google+ | Twitter
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
