Helper Application – DiffMerge – File Comparison and Merge tool
Interesting Find
As Software Consultants we are always on the prowl for tools and applications that can speed up the development and delivery process. One of our fearless leaders, Peter Drum, recently shared a tool with us and I thought I would pass this along. The tool is called DiffMerge and is distributed by SourceGear. From the SourceGear site, here are some features for DiffMerge:
DiffMerge is an application to visually compare and merge files for Windows, Mac OS X and Linux.
Product Features
- Diff. Graphically shows the changes between two files. Includes intra-line highlighting and full support for editing.
- Merge. Graphically shows the changes between 3 files. Allows automatic merging (when safe to do so) and full control over editing the resulting file.
- Folder Diff. Performs a side-by-side comparison of 2 folders, showing which files are only present in one file or the other, as well as file pairs which are identical or different.
- Configurable. Rulesets and options provide for customized appearance and behavior.
- International. Compatible with 42 different character encodings.
- FREE. Full featured. Not a demo!
Why another tool (you may ask)? One of the tools that I had used until most recently was WinMerge. Some key points from the Keith Craig on the SourceGear blog regarding differences between WinMerge and DiffMerge below (the main point being that based on what you main intent is (comparing or merging) the tool you use may be different).
Things I really like about DiffMerge include:
You can select text from any of the panes and patch it together in the merge result window as necessary It displays differences within a line, which can be a huge time-saver! It does true three-way merges (it uses the common ancestor of a file to determine what it can merge automatically) It is completely free for commercial or personal usage
I believe that one of most disappointing “features” of most compare tools has been an lack of displaying in line changes between files, most tools will show that a line has changed, but does not show the actual portion of the line that has changed. Chasing down an errant carriage return, or spelling change in a long line of code can take awhile. From the screen shots in the Blog above, you can see that this is addressed.
Happy Comparing and Merging!
login.salesforce.com – New API Login Endpoint
Interesting finding
Whilst perusing some of the Salesforce.com blogs noticed this interesting tidbit:
We will soon be updating the API login endpoint found in the enterprise and partner WSDL files. For the longest time, this endpoint was https://www.salesforce.com. Last year, we quietly launched a new endpoint: https://login.salesforce.com and in a future release this will become the official endpoint listed in the WSDL files. The old endpoint will continue to work, but you will shave off a bit of request time if you switch to the new endpoint, so why not do it right away?
Note that this change only impacts the login endpoint. As always, once you have logged in, you will receive the organization specific endpoint in the SOAP response and these endpoints have not changed.
So why does this matter? Well a couple of reasons:
- As mentioned, you will shave off a bit of request time switching over to the new endpoint. I’m sure this is in the order of milliseconds, but if you make hundreds of thousands of API calls per day, this could add up to saved wait time over a long period of time. It’s easy to change, so why not do it?
- While not explicitly stated, who’s to say that the current (www.salesforce.com) endpoint will continue to be supported ad infinitum? All documentation points to the new endpoint (login.salesforce.com) as the preferred method, meaning that new applications should use this endpoint.
Nothing we can do about bullet 2, but bullet 1 got me thinking, what sort of time savings are we talking about? After running many different trials on logins against both of the endpoints, I must say that my findings are inconclusive (please see graphs below). Over a sample of 100 logins, the average seemed to converge together with mere milliseconds separating the alternate login endpoints. Not only this, I believe other factors such as network latency which cause spikes in some of the login requests, lead me to believe that there is really no noticeable difference between the two endpoints.
So if nothing else than to code to the standard url endpoint specified in the WSDL, I would go with the salesforce.com suggestion of using the new login endpoint for new applications and not touch any of your legacy applications. That is, until there is an official communication that the old endpoint is no longer supported (if that time ever comes!).
Graphs (Y Axis in Milliseconds)
10 Logins
100 Logins
500 Logins
Are you tired of working with consulting companies who give you what you ask for, but not what you need? If you want to partner with us to extend your IT capabilities and produce real results, contact us
Pragmatism in Business & Technology Strategy
Wiktionary defines pragmatic as:
pragmatic – Practical, concerned with making decisions and actions that are useful in practice, not just theory.
As a technology consulting organization we frequently get asked to assist people in defining or refining their business and technology strategy, or to explain why we’re an organization that people should work with.
My normal response when giving advice or answering this question is pretty simple: we focus on results – achieving a positive outcome for the business (in our case our customer’s business). I then go on to explain a little more of my thinking…
It’s rare to find a problem that has only a single possible solution – in most cases there are are a number, with some being better or worse, easier or harder, cheaper or more costly etc. How do we weigh up the options and help people pick the right approach? One word comes to mind: pragmatic.
Here are some ideas that we consider when helping our customers make pragmatic strategy choices.
Look Back as well as Forward!
Reality dictates that unless your business is a startup any strategy must co-exist with products, processes, systems and technology that are already in place. While we shouldn’t be bound by the past and present if there’s a good reason to move in a different direction, we should at least consider the implications for a business in moving to a new strategy.
Of course, this is also a good way to avoid making the mistakes of the past all over again.
Plan for Change
I’ve often heard people say that change is the only constant! Organizations grow, shrink, get acquired or dramatically change course all the time. Making strategic choices that recognize this and are at least partly proof to the winds of change may not be obvious to everyone at the time, but just about everyone can see them after the fact.
The first question from many of you will be “How do I know what will change, and when?”. The answer (of course) is that many times you won’t know precisely what will change, but you can often predict what is more likely to change. An example might be taxation rules or rates – if these factor into your decisions you had better assess the impact of them changing because you can be certain that over time they will!
Technology is a Tool, Not a Goal
I’m sure many of us know someone who just has to have the latest gadget or toy, and can find some “reason” why it’s valuable. We see the same thing in business surprisingly often – with the same lack of real results.
Weeding this out of your strategy can sometimes be a bit tougher than we think since simply not keeping pace with technology trends can mean death to some businesses. But even when we undertake pure technology modernization projects we should always consider whether we’re satisfying a true business need, and getting “value for money” compared to not doing it at all. If not, maybe we’re too focused on the technology, and not enough on the real goal.
No One Answer
Sometimes a single right answer may be unrealistic. A solution in one environment may simply add complexity or cause pain when applied to another. Don’t be afraid to choose two options if one is not enough. Or after reviewing all the options, the one where you do nothing at all may be the best!
Avoid Short Term Syndrome
How many “short-term” solutions become long term problems? It’s important to overcome resistance to looking forward, and to consider the same fundamentals – including future flexibility.
Agile Strategy
Finally, you might be wondering how the above fits alongside our stated preference for using an Agile approach to implementing technology solutions? My answer is that ultimately we believe the outcome is what is important, not the approach to getting there. Our current thinking (and we’re obviously not alone!) just happens to be that Agile approaches help organizations get there faster and more effectively than the alternatives right now.
To back this up from a slightly different perspective, Elisabeth Hendrickson recently discussed why she defines Agile in terms of results:
Where people define Agile in terms of practices, I see more instances of Cargo Cult adoption (”We’re Agile because we stand up every morning!”) and religious dogmatism (”You don’t TDD?!? You can’t possibly be Agile!”).
Where people define Agile in terms of values, I see more instances of Agile-as-an-excuse (”Documentation? No. We don’t document anything. We’re Agile!”).
But where people define Agile in terms of results, I see greater focus on the ultimate goal: value to the business.
I really couldn’t put it much better: attention to results keeps everyone focused on what’s ultimately important.
Are you tired of working with consulting companies who give you what you ask for, but not what you need? If you want to partner with us to extend your IT capabilities and produce real results, contact us


