I've previously posted on how to move compiled binaries into a remote GAC automatically from your development environment to your SharePoint environment using SysInternal's PsExec utility.
But what about moving content files from your SharePoint environment to your development environment? When I'm developing content for layout pages (ASPX, js, css), for the most part, I don't want to develop in Visual Studio; I will usually use EditPlus (my weapon of choice) and edit the files directly on the remote server.
However, this poses a problem: synchronizing files between the SharePoint environment and the development environment. It's quite time consuming and painful to do it manually since you may have to dig through various directories and keep tabs on which files you've edited on the server.
Enter 2BrightSparks' SyncBack utility. Using this, I can create a synchronization automation between my SharePoint environment and my development environment. And because I've set up my files to have the same structure on both sides, it's easy to set up the synchronization settings.
The image above shows the layout of my project. You can see in the image below at the directory layout mirrors the project layout, making automated synchronization a snap.
Working smarter > working harder.
I've come across a small number of AJAX animation progress generators and a few pages with a fixed listing of generators, but Ajaxload is by far the best one I've found so far:
Very well designed (and useful) little utility.
The best devtool ever? Or the best devtool ever? You decide; I present the fantabulous Terminals.
Once you've lived with it, you can't live without it.
It addresses several shortcomings with the default RDP/Terminal Services client in Windows, namely:
- Lack of support for tabbed viewing of connections (who likes to have 5 different Remote Desktop windows open?). Terminals supports tabbed browsing of Remote Desktop connections.
- The need to save one .rdp file for each connection...what a pain in the butt! Terminals supports saving of the client connection information for you automatically. Not only that, it can add configured connections to a toolbar for easy access (instead of hunting down saved files).
- Lack of tools for connectivity testing. With the default MSTSC, it requires you to jump to the command line to run ping and other utilities when testing for connectivity. Terminals has it built in! Awesome.
- No support for connection groups. Quite often, when working with VMs or remote machines during development, you have to access the same group of machines at the same time (for example, a server and a client). With the default MSTSC, you have to manually start the two connections or write a batch file to open them at the same time. Terminals has a grouping feature which allows you to initiate grouped connections automatically.
During development, even with VMWare running locally, I prefer to use a terminal services connection instead since it's way more responsive to user input.
Terminals is definitely awesome. There are still a few issues like auto-scaling and auto-resizing which don't work quite right yet, but otherwise, it is fantastic. Note that it also doesn't support connecting disks and printers and what not (maybe next release).
Okay, so this isn't strictly a development tool, but Gantt Project has a pretty nifty, free, project management application.
With GanttProject you can break down your project into a tree of tasks and assign human resources that have to work on each task. You can also establish dependencies between tasks, like "this task can't start until this one is finished". GanttProject renders your project using two charts: Gantt chart for tasks and resource load chart for resources. You may print your charts, generate PDF and HTML reports, exchange data with Microsoft(R) Project(TM) and spreadsheet applications.
The site also mentions a good point with regards to Project:
Good (and growing!) set of basic features. This set is enough for most people (remember that 80% of MSProject customers use 20% of it's numerous features)
Easy learning. You don't need thick manuals to start working with GanttProject. If you are familiar with the notion of tasks, assignments and dependencies, you'll become an expert in GanttProject in a couple of hours.
Check it out if you're in the market for a free, simple, task based project management.
Wow, it's been a looong time since I've added one of these. I have a whole backlog of tools that I could add, but let's get to one of the important ones:
One of the really annoying things about Visual Studio is that renaming a project in the IDE doesn't change the name of the directory in the file system (or your source control). Of course, updating the string in the code files is not so bad, but then you also have to go through all of the project and solution files to change all of those occurrences.
That's where the _REPLACE.EXE utility comes in. Using a series of commands like the following:
_replace.exe "<old-string>" "<new-string>" /i /s /ext=.csproj
_replace.exe "<old-string>" "<new-string>" /i /s /ext=.sln
_replace.exe "<old-string>" "<new-string>" /i /s /ext=.cs
_replace.exe "<old-string>" "<new-string>" /i /s /ext=.resx
_replace.exe "<old-string>" "<new-string>" /i /s /ext=.config
_replace.exe "<old-string>" "<new-string>" /i /s /ext=.xml
You can pretty much replace most of the string names in your project by using that set of commands (and additional ones for any other file extensions). What's cool is that you can also use the /t command line switch to do a dry run.
Very handy indeed. Do keep in mind that you still have to go in and manually change the directory names but it's far more efficient than twiddling around with a text editor to replace the string in each of the project/solution files.
So my interest in NHibernate is picking back up again. The 1.2 beta release that's circulating now (the candidate release has been out since February of this year) addresses various issues with NHibernate in my previous time with it.
Specifically, the biggest issue was native support for generic types. In addition, it seems like there are various other goodies in the 1.2 release such as stored procedure support.
And to think, I just got the team to standardize on Microsoft Enterprise Library 3.0. I'm wondering how to break this to the team.
I guess in a sense, they are not completely incompatible. Roll your own queries and data access routines are still the way to go for more complex queries (does NHibernate handle FOR XML EXPLICIT?) and anywhere high performance is critical.
The beauty of this whole thing is that as NHibernate has gained traction since the first time I used it like 2 years ago, the tool support has evolved tremendously. Combined with MyGeneration and user templates, I was up and running (although the generated output had some minor errors in the XML mapping file) in minutes. Not only has the tool support improved, the documentation has improved as well.
There is still some conflict, internally, as I was just ragging on LINQ last week with another group of developers for the simple fact that it creates a tight coupling between code and the raw data. Whereas with stored procedures, you can have dedicated DBAs write highly performant code and you can modify the underlying data retrieval and layout so long as you maintain the same resultset, with dynamic queries, you lose a lot of that flexibility. In addition, you lose a bit of testability as well since many times, it's just really helpful to be able to test the SPROC independently of any code (or perhaps breakdown subqueries in the SPROC to test small subsets of data).
In actuality, I think that having the mappings as XML is probably better than using LINQ since the XML mapping files can be loaded at runtime, meaning that the deployed mappings can still be manually updated whereas LINQ would necessitate a recompile of the source (my understanding of it).
So if you haven't checked out NHibernate for a while, now's a good time to get a refresher and re-evaluate the library. I think it will still stick around even after LINQ is released.
Anyone who has used the .Net XmlSerializers have surely encountered the dreaded namespace bloat which makes the serialized objects grow to ridiculous sizes.
If you're using WSCF, on the client stub, I've gotten into the habit of writing custom serialization overrides in partial classes which ensure that if the client needs to serialize objects into XML, I'm doing so in an efficient manner. It'd be nice to see it added to the server side class constructors as well. Add your vote for this feature over at the WSCF dicussion boards.
Now first of all, I know many developers have an averse reaction to the use of the phrase "application framework" and immediately reject such things without second consideration. I always hear tales that begin like so: "Well, on this one project, we used an application framework and it ended up not doing anything exactly the way we wanted and we had to modify it anyways..."
Four thoughts on this:
- No two applications are exactly alike. If that were so, we'd all be out of jobs as software engineers because it'd probably have already been done before. As well, no two application frameworks are alike (although on some level, Spring is interchangeable with Castle).
- Spring, I have found, does not restrict me in anyway in terms of my solution design. If anything, it frees me to use more flexible designs and allows me to create much cleaner and better designs. Inversion of Control is your friend.
- Spring includes the source. Dude, if it doesn't do exactly what you want it to, you are 100% free to modify and reuse it (and maybe even resubmit it to the project if it's well written and useful).
- The documentation and development team on Spring (and Castle to a lesser degree) are great. The documentation is very thorough and well organized and the developers are constantly monitoring the discussion forums and reaching out to users. Many times, with any sort of large library, you may be under the impression that it doesn't do something (thus leading you to believe that you have to write it anyways and believing that it was pointless to use the framework), but it may actually be the case that you simply haven't found the facilities in the library to accomplish your task.
On top of this, the support forums and developers working on the framework are great resources for hashing out design ideas (outside of one's normal circle of peers).
Yes, it's true, Spring requires the use of what can become massive XML configuration file(s). Yes, it can be difficult for first timers to grasp inversion of control, understand what exactly it is that Spring offers, and in general, find anything in Spring that would significantly make one's life easier as a developer without a learning curve. Yes, Spring is huge; it encapsulates a lot of "stuff" that can be confusing and seem like bloat one's first time encountering it (I myself only ever use a small subset of the features of Spring).
However, in the end, I think Spring brings so much to the table (too much for me to list here), it's hard to discount it without at least giving it a real evaluation. For any sort of non-trivial application, Spring allows the designer to add much more flexibility and decrease the complexity of the codebase by encapsulating a lot of the dirty work. (I would agree that there is a complexity cutoff where if your application sits below this cutoff, it's simply not worth it to include Spring in the discussion, as the time it takes to understand and find its usages in your scenario would not be worth it).
I've been using Spring for almost a year now and I simply can't imagine writing an application without it. With the latest release, the introduction of the data access library, Spring becomes even more compelling by removing a lot of the boilerplate code that one would write when performing data access. Admittedly, in a sense, it is a replacement of one set of boilderplate code for another, but it is a much more elegant design than using raw ADO or even Enterprise Library for that matter. Spring introduces the usage of a delegate/callback pattern for "rendering" the returned data rows and sets into domain objects and sets.
Having used NHibernate previously, I have to say that in many cases, I still prefer performing my own data access code and domain object rendering as it allows me much more flexibility and control. There is less processing overhead and not to mention (when I last checked) NHibernate still does not natively support generic types.
I've mostly been sticking with Enterprise Library, which is basically just a step above raw ADO, but I'm gonna give this a shot since it's yet another step or two above Enterprise Library.
On another note, it seems like Microsoft's Patterns and Practices Group is finally releasing the next version of Enterprise Library. In a sense, EL is a "necessary evil". As far as 2.0 goes, I cannot say that it does anything particularly better than other libraries that fill the same purpose as any given block, but what it does do is it encapsulates multiple functional spaces (logging, data access, exception handling, configuration) into one. In addition, having the Microsoft Seal of Approval also helps with acceptance. As an example, the rolling flat file trace listener has had a counter part in log4net since I've been using it (over 1.5 years now). The data access application block, while it does clean up data access code, is still pretty close to raw ADO.Net usage patterns; in other words, it brings almost nothing to the table (almost; I still endorse it over raw ADO.Net to be sure).
It'll be interesting to see what this Object Policy Application Block actually does. It seems like it's conceptually similar to Spring's IApplicationContext or Castle's Windsor Container. I'm not one to latch onto a product simply because it's from Microsoft's P&PG, so I'm hoping they can actually bring something new to the table to make their library more compelling than Spring or Castle (both of which are much more mature by now and encapsulate a far greater set of features).
As for the any concern over the longevity of Spring and Castle, I feel pretty confident that what happened to NDoc, will not be happening to Spring or Castle.
Well, what we have today is a general tool that's sure to help anyone out.
As a developer, I spend so much time launching a variety of applications. Visual Studio, web browers, digging through my project directories, Query Analyzer, and so on. It can be quite tedious to have to trod through the Windows Start menu.
Fortunately, there are a variety of application taskbars out there like ObjectDock, for example. But I've found ObjectDock to be a little too fancy for my simple needs and a little too resource intensive on my laptop. In addition, I recently had a weird error with it on my wife's laptop where it would cause the task bar to disappear (even though I did not set the option in ObjectDock)...took quite a while to figure out that it was ObjectDock causing it.
Enter Kana Launcher. This is exactly what I've been looking for in terms of application task bars. It's small, simple, lightweight, easy to use, and performant. What I like best about it is that the little floating task bar shows up where your mouse is, so getting to the application you want to launch only requires the minimal amount of mouse movement.
Kana Launcher also has a full size listing (like a context menu) with folders where you can organize all of your applications and what not (the floating task bar is a subset of the full list).
Best of all, it's free (and we always like free on the Random DevTools list)!
Note that you can add all sorts of launchers to it. You can open up to a specific folder. You can open up FireFox or Internet Explorer to a specific URL. You can launch command line applications with arguments in it. All you have to do is create an application shortcut on your desktop and then drag it over to the Kana Launcher.
Web development in IE just got a whole lot better (well, at least for me).
Enter Microsoft's Internet Explorer Developer Toolbar (link).
This is one area where IE has been just left behind in the dust by FireFox. But this is definitely a nifty add-on!
Just a short outline of the features:
- Built in validation from a dropdown. Nifty and convenient.
- Built in onscreen ruler! This is awesome.
- Ability to quickly resize the window.
- DOM browser like FireFox.
And a ton of other stuff.
If you make webpages for a living, then all I can say is: Must. Download. Now!
Note that after installing it, you have to enable it by selecting it from the View->Toolbars menu item (it's instinctive to look in the Tools menu and get baffled by the lack of new menu items).
Update: there's also a non-Microsoft, FireFox analogue.