What reading would you recommend on general debugging techniques? I am more interested in principles and best practices than in specific platform solutions. For the record I mainly work with .NET (F#, C#), and dabble in Haskell and Ocaml.
One of these Friday evenings we talked about debugging with my colleague on our walk home. I was surprised to learn that one can view and modify the state of live objects from the VisualStudio debugger. He also mentioned that another developer he knew, a "Java guru," had once shown him some debugging magic and given an article or booklet on debugging, which challenged my colleague's initial "there's nothing to it" attitude. Having spent more time than I wished hunting bugs, I am ready to be challenged as well. Are there any links you would recommend?
I'd recommend reading everything you can find on Test-driven development (TDD). From the Wikipedia article:
Programmers using pure TDD on new
("greenfield") projects report they
only rarely feel the need to invoke a
debugger.
From a personal standpoint, it's been my experience that the more unit tests I write, the less time I spend in the debugger.
Specifically for .NET, here's a nice article on Easier Debugging with Attributes.
I highly recommend the excellent book Debugging by David Agans.
While not specifically about programming, the principles are universal. One of the techniques in here provided the biggest quantum leap in my diagnostic capabilities, namely, backing out your fix to prove that just your fix has corrected the problem.
I've studied a lot of debugging books and thoughts. Probably the best one is Debugging By Thinking. I think it covers everything that needs to be said, in a logical fashion, in an easy-to-read package.
It takes a native approach (win32) but Advanced Windows Debugging is a great book.
I like Ian Taylor's.
Tess Ferrandez's blog If broken it is, fix it you should is both directly relevant to specific real-life scenarios you're likely to encounter in .Net debugging, (typically involving ASP.Net), and more generally thought provoking.
John Robbins' debugging books and blog are similarly worth reading.
Mike Stall's .Net Debugging Blog likewise.
Mark Russinovich's blog is remarkable - his knowledge of Windows internals combined with great forensic skill is impressive.
My first introduction to debugging was this tutorial. It uses GDB to debug a sample C++ code, but the principles are generally applicable. The thing I really like is the way the author explains his train of thought about what might be wrong, and then the specific commands needed to test the possibilities. It's pretty fun! If you're new to debugging, it's a great insight into the process.
Related
I have been developing websites for quite some time and I am not so good in designing websites? My Boss is refering me to take some lessons on it.
But I really want to stick to development rather than designing?
You don't need to be a designer. But I would highly recommend you understand the process and some of the techniques used. Having that knowledge will assist in both working with designers and providing better back ends.
I'd do the course, but make it clear to my boss that it's not what I want to do as a main job.
Answer yourself these questions:
What is your objective, the dream? developer or designer?
What are you best with?
Will I be able to justify with my design requirements?
It this common that a developer should be a designer too?
Will you be able to to concentrate on both, the ever changing trends and techs.
Having said that, I have seen such people having both skills but still they don't weigh equal in both parts.
Developer as well as designer:
Chris Coyier of css-tricks.com
Pekka
It depends on what you want to be in the future. Actually, designing and programming are two different skills. Obviously, for websites two things are both required. As a developer, if you have some basic knowledge about design, it would help you and also the designer to make the website much easier to maintain. But personally, I do not thinking you have to dive into design.
a good developer knows a lot about design, but dont have to be good at designing something.
i've seen to many developers building up a given design and making so much mistakes, because they don't see the little intricacies that are enormously important for a well designed website.
One particular design aspect I find many developers (good ones) are not necessarily extremely strong at is understanding of colors harmony. Even though it seems like easy thing to do, find the right combination of colors on a page, it is not always that easy. That course may be helpful in that regard.
I started of as a developer and then progressed into being a Developer/Designer.
You start to understand design aspects, UX aspects and the likes.
So i believe a good developer should also have a good understanding of design aspects as well
The bottom line is your boss thinks you'd benefit from a bit of immersion in design, and you probably will.
It doesn't sound like he wants you to become a designer, just get a feel for it. He's not asking for a career change.
There's always benefits in learning something new. And if your boss is backing you taking some time to do it got for it.
As a developer you should know something about usability and software ergonomics. You should know the basic structure of a website. And you should be able to implement a given design.
I think it is not the job of a developer to create a design.
Try to answer: "Why does your boss want you to improve skills in design? "
Your team is too expensive and boss is going to fire designer. He is wondering is it possible.
Your designer complains to boss that developers constantly ask him to refactor insignificant details interrupting from common tasks. So your boss wants to delegate small design decision to developers.
If it's so, I think nothing is a bad to improve design skills if your boss doesn't want you to convert to designer.
I also agree with all those people, who state: Developer and designer are two different roles.
Well, if developing is the field you are comfortable with, stick with it.
But learning is never bad. Try to gain knowledge first, after taking the classes, you can answer this question yourself
Wow, I'm actually in the exact opposite of your situation. I'm a designer just crossing the line of web development. But in my case, it was my own decision and it wasn't imposed by anyone.
It's always a plus if you have web development skills on top of design skills. I guess it holds true if you're a web developer and have design skills as well.
It never hurts to learn the basic, like others have mentioned, but keep in mind to stick on what you're good at and master it. Its better to be a master of something rather than being a jack of all trades. With so much competition out there, you really have to excel at your craft.
Learn both, but master one, I'd say. I personally see myself as a developer foremost, but I do know a thing or two about design - and, more specifically, implementing it (think CSS and the like).
However, I gratuitously admit that I am not good at making a design that looks good. A functional one, maybe, but not good. You could say something like that to your boss - that yes, you are capable of learning to design, however that you will never be as good as a real designer. Likewise, a designer learning to program will never be as good as a dedicated developer.
I'm looking to find any articles/books on usability. I'd like to get a handle on best practices when designing a UI, this can be anything from which user controls are more intuitive to a new user, to how to phrase text that is displayed to the user to avoid confusing dialogs. I mainly do Windows desktop applications, but most usability standards, I assume, would stand true regardless of the platform.
As an example, here's an MSDN article about the Windows User Experience Guidelines:
http://msdn.microsoft.com/en-us/library/aa511258.aspx
Try reading this book: Don't Make Me Think. While it's focused on web usability it is applicable to all facets of UI design.
The Design of Everyday Things by Donald A. Norman is a standard book on general usability considerations that can be applied to just about everything in day-to-day life. It's not specifically about software, but it's worth it to read it.
Universal Principles of Design is a recommended textbook for my university's Engineering Methods of Software Usability course. Myself, and others who have taken this course, have found this book to be more useful than the required textbook. There appears to be an updated version, called Universal Principles of Design, Revised and Updated: 125 Ways to Enhance Usability, Influence Perception, Increase Appeal, Make Better Design Decisions, and Teach through Design, but I can't speak about that one.
Designing for People Who Have Better Things To Do With Their Lives
by Joel Spolsky (one of the guys behind this site)
when designing UI, please do consider accessibility as well. it's mostly relevant for web sites, but could also be applicable for rich client (desktop apps).
so, these links has a lot of info on the subject, though it's not pure usability info.
a good resource on usability and accessibility:
Design Guidelines for Electronic Publications, Multimedia and the Web
you might find this check list useful:
Checklist of Checkpoints for Web Content Accessibility Guidelines 1.0
and also this tool that will check your web site accessibility:
web aim
Designing Interfaces by Jenifer Tidwell is pretty good.
Well, a long-standing favorite specifically for user interface design is Alan Cooper's About Face. It should touch most important topics when designing Windows desktop applications.
Then there are also various UX patterns which are well-presented in Quince (needs Silverlight).
Jef Raskin's The Humane Interface is also rather good, but very radical in his ideas. Still, this book points out many fallacies in modern UI design. If you need to stick to the WIMP world, then following his suggestions might be a little hard as he tends to suggest to overthrow everything we're used to. But well-written and good for provoking thoughts, even if you don't follow all his advice.
As for books/articles on usability in general or on slightly different topics:
Jakob Nielsen's website useit.com. While not particularly fancy-designed it is a trove of thoughts and advice on usability in general.
Steve Krug's Don't Make Me Think. Web usability, but also a very good read.
Donald Norman's The Design of Everyday Things. Usability in general and has many pointers on how to think about usability without going into specific technologies. It's applicable to desktop application usability anyway, though.
Regarding articles, try Boxes and Arrows
Designing Visual Interfaces by Mullet and Sano provides a great foundation for different layout-related issues. Not a book on usability per se but still relevant, I'd say.
As for web resources, try:
useit.com: Jakob Nielsen's Website
Usable Web
A List Apart on usability
For book inspiration, see Suggested Readings in Human-Computer Interaction (HCI), User Interface (UI) Development, & Human Factors (HF) (and all the great answers in this thread).
My favorite usability blog contains very well-constructed, insightful and thoughtful posts, by David Hamill.
You can find his blog at goodusability.co.uk
Enjoy.
I read articles from http://ui-patterns.com/ and http://www.uxbooth.com/. Those have been helpful for me.
I would like to second uxbooth.com - we recently had an article published there which might be what you are looking for - check it out at http://www.uxbooth.com/blog/usability-testing-dont-guess-test/
usefulusability.com
is another good site, they regularly have good articles up there.
Oh, and another article we had published recently:
www.1stwebdesigner.com/development/usability-ux-pitfalls-howto-avoid/
I think this one provides some pretty good examples of issues that frequently pop up, and how to avoid them.
And if you are looking to run a simple usability test, what not check us out at IntuitionHQ.com
Good luck!
Where would one find information or just rather good ideas on what is considered proper programming ethics or methodology of how to format the code, comments, or even variable names so that it is easier to read the code at a later time?
Thanks!
The book Code Complete 2 is a timeless reference for good coding practice.
The absolute 'must-read' for you is Robert C. Martin's book Clean Code. Do give it a try. It makes some awesome points. I keep recommending to everyone ever since I bought it 6 months ago.
Edit
I thought reading my Amazon review could help :)
You're asking for Coding Standards, which are language specific.
For C# check out The IDesign C# Coding Standard (on the right-side of the screen in the middle of the page)
For .NET in general see Design Guidelines for Developing Class Libraries
For C++ check here
For Java see Sun's resource Code Conventions for the JavaTM Programming Language
For C++ I use the C++ google style guide
Including Code Complete and Clean Code I would recommend you to read "The pragmatic programmer" and "Ship it!". The last books mentioned are not so much about how to format the code, comments, ect. but rather about best practices for developers and development.
Three books I consider essential for beginning OO programmers.
"Refactoring: Improving the Design of Existing Code".
Although modern IDEs often support automatic refactor, this book is still useful. By knowing the reason (or code smell) behind a particular refacoring, you can strive to write the correct code the first time.
"Pragmatic Programmer"
A wealth of best practices.
"Design Pattern"
Most advanced book, but still useful.
Clean Code is certainly a good book. Martin's Agile Principles, Patterns, and Practices in C# is my recommendation if you want a more .NET specific book.
I watched few videos/webcasts about "Oslo" but I still fail to see how it all comes together.
I understand that Oslo is a modeling platform.
What's the process to create a DSL?
Is it more than just a tool to create DSLs?
I understand that MGramma is used to create a DSL's syntax.
What is M language for?
What is MSchema?
After creating an MGrammar and compiling it to .mgx, what's the next step?
That Wikipedia article is pretty opaque.
The Microsoft project page for Oslo might be a better starting point. It begins:
About "Oslo"
”Oslo” is the codename for Microsoft’s
forthcoming modeling platform.
Modeling is used across a wide range
of domains and allows more people to
participate in application design and
allows developers to write
applications at a much higher level of
abstraction.
IMHO, it does seem more "fully buzzword compliant" than a real product. That said, it looks like there is some kind of demo or technology preview available for download. One might hope that they have included some samples that make it clearer what kinds of problems it is intended to solve.
Think of oslo as an excel/access replacement. Something for end users to model and process their data, without the need of developers.
MGrammer is where things get interesting for us, but the bits that are interesting are more of a v2 thing. You could think of it as excel macros done right.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I was certain that somebody would have specifically asked this question, but from what I can see no-one has (there's been a question about learning win32 but that doesn't cover whether it's worthwhile doing so).
I am very interested in gaining a deeper understanding of all the systems I use (I mostly program in C#, at least professionally), so I wondered, very simply - is learning win32 worthwhile, or is it overkill? Am I wasting my time? Is the knowledge I'd gain worth the effort?
Similar / related questions on StackOverflow:
Does it still make sense to learn low level WinAPI programming?
How relevant is Win32 programming to modern professionals?
Having a working knowledge of how Win32 works at the lowest level will certainly be invaluable if you are planning on doing Windows development in the future. It gives you a level of insight into things like Windows, Messaging and GDI that are hidden by the time you get to the level of .NET.
I wouldn't recommend you try and use Win32 for writing all your applications, but I feel that any Windows developer would benefit from writing a simple Win32 application using C/C++.
This is less true for things like WPF where there is less dependency on Win32, but just knowing how Win32 works will help you understand or appreciate some of the design decisions in WPF.
I advocate learning the concepts behind low level windows programming if all of the following are true.
You are going to do any windows programming.
You want to be the "go to" guy when the unexplainable happens.
You love to learn.
Abstraction layers like .NET work create and allow developers to do incredible things without having to know a lot. However, when .NET is used in a way unanticipated by its authors which reveals one of its subtle bugs, then that is the time where some win32 API knowledge goes a long way.
Will you ever have to write a message pump? I doubt it. Can it help diagnose problems? You betcha!
The question is much like, "Is learning assembly worthwhile"; and the answer is the same:
"Yes, because you will understand the fundamentals, and be able to perceive deeper than those who only work at the top level of abstraction".
However, by the same token, you probably won't be writing Win32 API directly 99.5% of the time.
When they invented C to replace assembly language, people where probably asking: "is it worthwhile to learn assembly language?" The value in knowing both was being able to drop to assembly to do the things which were impossible to accomplish in C (eg. trigger an interrupt).
The same can be said for Win32. There are some things which are impossible to do in C#. If you didn't know the win32 api, then you would dismiss some things as being impossible. However, once you know what you are missing, in those rare situations, you would be able to "drop to win32" and do them.
Another way of looking at it is this: programming is all about being able to think in multiple levels of abstraction at the same time. For example, if you know your language uses immutable strings, you don't write an algorithm that adds a single character to one 10000 times, because it will be slow. If you know the win32 api, you will be able to think about how each line you write in C# is actually implemented and that will help you write better code.
At least for me, learning an API (I'm assuming that "in-depth" is implied) that I don't use is a waste of time. I'd rather spend my limited amount of time and brain power learning new concepts or exploring new tools than becoming intimately familiar with an existing tool that I don't need to use now. When I need a particular tool that I don't have or have to use a tool that I'm not familiar with, that's the time to learn it in some depth. Before that I might do enough investigation to know whether it is going to be useful to me or not, but not much more.
Yes, the principles of the Win32 API are useful to learn - these principles are the foundation on which everything else is built.
The .NET APIs for GUI development, both Windows.Forms and WPF, do what they do within the constraints of what is possible on top of the Win32 API. Key architectural decisions of these frameworks were constrained and informed by the Win32 API.
On the other hand, you are less likely to get a lot of value from diving deep into the API, as there is a lot to learn, and given that you spend most of your time working in C#, you'll have less opportunity to use the knowledge directly.
BTW, the same applies to other technologies as well - like networking, cryptography and hardware design. Learning the fundamentals will help you become a better developer.
Yes, you should learn the basics of how Windows (a lot of this stuff predates Win32) operates. Why? For the same reason as I understand how a mortise and tenon joint operates, even though I don't make my own furniture, or why I understand how an internal combustion engine works even though I don't do my own car maintenance.
You work at a higher level of abstraction, which is nice, but when that abstraction leaks - that's not an "if", that's a "when" - if you don't understand the basics of Windows, you'll be lost. If you don't know at least some of the API, you won't have a clue where to look if you need to P/Invoke functionality not available in .Net.
Quite apart from that, isn't curiousity reason enough?
If you are trying to write a VB6 application then the Win32 API allows you to do a lot of things that are not natively supported by VB6.
If you're writing a C# WinForms app then I would recommend learning the vast reaches of the .NET Framework first.
Edit
If you really want to know what's going on under the hood in Windows then you might want to check out a copy of Programming Windows 3.1 by Charles Petzold.
I personally think it's still worthwhile learning the Win32 API.
As far as I recall when I started learning Win32 (after doing some VB(A), Pascal, etc.) I learned a lot about Windows and understood how thing works in Windows. Everything was so clearer. :)
So, as per your question - you will learn a lot about Windows through learning Win32.
As you said - you're a C# programmer and I'm not sure if you'll use it often, because almost everything you need is already there, in .NET.
I won't repeat over and over what the others said many times already.
Here's a link to a Win32 tutorial with which I am currently learning along the basics of Win32's. I find it pretty interesting and easy to follow.
This tutorial helps me get what I didn't understand first, back when I've begun to program in my secondary school years.
If I were to start today, I wouldn't learn the entire API. However, I do think that the basic concepts are important to understand, with an understanding of how message loops work as the top priority.
You'll never be able to just "learn" the entire win32 API, it's too much to take in, and it will be a moving target. If you develop in C#, there's no real point.
That said, try creating Notepad using plain C and just API calls. That will teach you enough for a C# developer to at least appreciate it.
A lot of the "No" answers here seem to focus on learning the actual methods, structs, and what not available in the API. I'd say yes, but focus not on the individual components of the API, but the overall design and the way it functions. It's much easier to troubleshoot even .NET code when you understand what's happening at the core level of the operating system.
This question looks a bit dated, but I'll answer anyway.
Answer: Complicated: yes. Simple: probably not necessary.
It really depends on what you need to do. If you need to use a feature not current supported by .NET, have-at-er. But be careful, most of the coddling the Framework provides Win32 does not, and if you do something incredibly stupid, your machine WILL bluescreen.
I know when .NET first came out, I had have no interest to learn Win32, .NET was here and it was such an improvement. But the sad fact about Windows is this: all new features in Windows are implemented in native code first, period. If you want to use any part of Windows before .NET wraps it, you're either using Win32 from C++ or Win32 from C# or from VB.NET. .NET is a wrapper, for all the stuff in Win32. So if you can't wait, yes, you can Interop into the lower bowels of the OS if you'd like.
Knowing Win32 and probably one day Win64 (whatever they happen to call it) will always be a useful skill. Any whizzbang technology requires underpinnings somewhere.
.NET is implemented using win32 api, anyone wishing to possess deeper understanding of .NET would greatly benefit from having at least marginal knowlege of win32api.
In your career it will be unlikely that you will only be creating greenfield applications where you will have the freedom to choose the technology and programming languages used.
Sooner or later you will have to integrate with old code written in Win32 and C/C++. In that case, knowledge of Win32 will help, especially if you are integrating using PInvoke or C++/CLI.
Misuse the .NET framework and Win32 and your machine will blue screen? Somehow I doubt that.
The biggest value to knowing Win32 (or assembly language) is that when something doesn't work as expected and you have to debug it. The more you know about the underlying system, the easier time you will have debugging the problem.
I like to further add to this. I never formally studied Win32 API/MFC. I started using Visual C++ 4 when I first got interested in GUI programming. Anyway, I wish I kept that foundation then, as I never caught on quick enough (I was rather young then, actually), so I studied Visual Basic instead.
For some reason, Delphi never interested me even though I knew Pascal well enough, but I digress. These days, I work in IT and develop installer scripts in NSIS - and every so often I need additional functionality that NSIS doesn't provide, so I make my own plugin and to keep it quick and dependency free, I opt for Win32 API opposed to MFC or even full blown C++.
The main reason for this comment, is that my own curiosity got me hooked. I like to know more, so where is the best resource for learning the API. A book? Website?
Would MFC still be worth tackling as well? I did see a website about a fellow that develops Win32 GUI apps, in assembly! I think that is overkill, honestly, but it is compact, fast code, interesting, the concept, but I never was able to get the hang of 80x86 assembly (hell, even RISC assembly in college I never was able to do!)
I think it's always interesting to know how a system works if your work relies on it. I don't mean you should learn every bit of it, but still get a good understanding, at least to be able to search more by yourself the day you will have to.
Software is not magic - well... ok... for 99% of the cases :-)
Here is a link to an excellent article about "magical thinking" and "GUID goblins" from Eric Lippert's about that subject: It's not Magic