Expand all Collapse all
Dr. Greg Low has been running a technical user group for years. In Building Technical User Communities, he shares what he has learned - what works; what doesn't work; and advice that may or may not fit your group.
As a longtime user group contributor and leader, I had already considered many of his recommendations, but I found most of them to be solid advice. In fact, at my group we were already doing many of the things that contained in this book.
For example, we found that members appreciate a consistent meeting place and time for our group. We have also used our group as an opportunity for new speakers to build their skills in a low-risk environment.
Like Dr. Low, I have found the best way to grow a group's attendance is by word of mouth - get to other user groups and technical events in the area and promote your group; and encourage your members to invite their friends and co-workers to the next meeting.
You don't need to take every bit of advice. For example, Dr. Low recommends 2 speakers per meeting, while my group has been successful with just one.
A month after the expiration of my term as user group president may not be the perfect time to read a book on how to lead a user group. But it's a good time to evaluate such a book.
If you are part of the leadership of a technical user group or you are considering forming your own group, an evening spent with this guide will give insight into what can make it successful.
Reviewed by David Giard
The format of Restful Web Services Cookbook is different than I’m used to. The book presents ideas in the form of a problem, a solution, and a discussion of the solution. It starts with simple concepts like HTTP verbs (GET, POST, PUT, etc.), and moves onto more complex topics, such as content negotiation and sending queries via HTTP.
Most eye-opening for me is the concept of providing in the data sent to the client links to perform related actions on the data, such as updating the record or rolling back changes to a previous version.
In my career, I typically focus on the tools of software development. This book ignored the tools to create and consume web services and focused on the format of the messages passed. It got me thinking at a lower level – about message headers and HTTP verbs – than I am used to thinking.
One hast to get past the fact that Allamaraju does not provide code for generating the requests and responses he describes. He does so in order to keep it technology-neutral and language-neutral. The reader has to apply the concepts to their own development skills in order to implement these recipes.
Restful Web Services Cookbook gave me new insight into the workings of HTTP. It took me out of my comfort zone and taught me a lot.
It has been almost a decade since I first learned C#. It didn’t take me long to become productive in this language; but years later, I am still uncovering its secrets. There are two reasons for this:
In Effective C#, 2nd Edition, Bill Wagner attempts to demystify C# by explaining much of the inner workings of the language and by providing specific advice points to improve your coding.
The book assumes a basic understanding of C# syntax. It builds on this understanding in two ways:
The second edition of this book includes new features introduced in C# 3.0 and 4.0, such as lambda expressions and LINQ.
The book is split into 50 chapters and each chapter advises developers on a specific coding preference. Wagner backs up his advice with an explanation of the inner workings of the C# language. Among the questions that Wagner answers are:
With 50 chapters of solid advance and concise explanations, everyone beyond a beginner level in C# can benefit from this book.
I began reading Agile Principles, Patterns and Practices in C# by Robert C Martin and Micah Martin after a friend recommended the chapters on pair programming. My friend was right, of course. The Martins not only decribed pair programming but included an entertaining script of two developers pairing on a programming problem.
But, as I dove deeper into this book, I found a wealth of other information.
The book begins with a section on agile development, defining some basic terms and concepts recommended practices. It follows with a detailed section on good design practice. This second section is the most interesting, as it describes the famous SOLID principles. SOLID is an acronym for a set of good design practices:
S=Single Responsibility Principle: Each class should serve only one purpose and have only one reason to change. O=Open-Close Principle: Classes should be open for extension but closed for modification L=Liskov Substitution Principle: It should always be possible to substitute a derived class with its base class I=Interface Segregation Principle: Interfaces implemented by a class are defined by the client objects that use that class; a class should implement a separate interface for each client that calls it. D=Dependency Inversion Principle: To maintain flexibility, you should write code that depends on abstractions, such as interfaces.
Next, the authors present an overview of Unified Markup Language (UML), a graphical language used to describe software designs and requirements. Common UML diagrams and shapes are described and the author offers opinions of which ones are most useful and when to best use them.
The last half of the book is a case study of a Payroll System in which the authors use examples to illustrate the concepts introduced in the first half of the book.
Although C# is included in the title, the book does not focus on C# and almost none of the concepts are specific to any particular language. All the code examples are in C#, which makes it a bit more accessible if that is your strongest language.
The book is filled with lots of information and good advice. For example, the authors recommend an iterative approach to writing software, a test-first approach to development and encourage developers to refactoring their code frequently.
Whether you read all of Agile Principles, Patterns and Practices in C# or pick through the sections of interest, you will benefit from this book.
Cliff Atkinson's Beyond Bullet Points proposes a radically new approach to creating presentations based on Microsoft Power Point.
Atkinson provides a template (available for download); an outline that splits a presentation into lengths of 5, 15 and 45 minutes; and an abundance of advice on improving your presentations.
After reading the book, I discarded the template and the outline but I embraced many of his ideas.
Here is some of the book's best advice:
Allow your presentation to tell a story. The first presentation I did after reading this book included a story about consultants Juan and Amal, who had nearly identical skills and accomplishments but received very different performance reviews. Most of my presentations are instructions on how to use software, which doesn't lend itself well to a story format. If possible, however, I try to weave a story into the presentation.
Minimize the text in your slides. Atkinson recommends eliminating all bullet points from every slide. The only text on each slide should be a headline. I haven't gone that far, but I have drastically reduced the amount of text on each slide. When I open an existing deck, I move much of the slide text into the Notes section. This simplifies the presentation, but keeps the text with the slides when I distribute them to users. During presentation, I make the former bullet points part of my verbal presentation, rather than something the audience reads off the screen. This keeps the audience's focus on me, rather than on the screen.
Use simple graphics A simple graphic communicates an idea visually. I have been replacing the bullet points in my slides with a headline and a single photograph that relates to the slide topic. The slides become more interesting but less distracting.
Rehearse your talk I already knew this but the book's reinforcement helped remind me how important it is to be familiar with one's material. Nothing achieves this goal like a couple dry runs through your presentation. Ideally this should be in front of other people (to provide feedback) and in a room similar to the one in which you will be presenting; however, filming your presentation and reviewing it yourself is also very helpful.
I have not bought entirely into the Beyond Bullet Points approach. But I have internalized many of the ideas in this book and my presentations have improved as a result.
GANG meets on the third Wednesday of each month, at 6:00 PM in the Microsoft office in Southfield, Michigan.
Click here for map
______________________________________
Sitefinity ASP.NET CMS