Search Results

Search found 9 results on 1 pages for 'mrlane'.

Page 1/1 | 1 

• Odd company release cycle: Go Distributed Source Control?

  - by MrLane

  sorry about this long post, but I think it is worth it! I have just started with a small .NET shop that operates quite a bit differently to other places that I have worked. Unlike any of my previous positions, the software written here is targetted at multiple customers and not every customer gets the latest release of the software at the same time. As such, there is no "current production version." When a customer does get an update, they also get all of the features added to he software since their last update, which could be a long time ago. The software is highly configurable and features can be turned on and off: so called "feature toggles." Release cycles are very tight here, in fact they are not on a shedule: when a feature is complete the software is deployed to the relevant customer. The team only last year moved from Visual Source Safe to Team Foundation Server. The problem is they still use TFS as if it were VSS and enforce Checkout locks on a single code branch. Whenever a bug fix gets put out into the field (even for a single customer) they simply build whatever is in TFS, test the bug was fixed and deploy to the customer! (Myself coming from a pharma and medical devices software background this is unbeliveable!). The result is that half baked dev code gets put into production without being even tested. Bugs are always slipping into release builds, but often a customer who just got a build will not see these bugs if they don't use the feature the bug is in. The director knows this is a problem as the company is starting to grow all of a sudden with some big clients coming on board and more smaller ones. I have been asked to look at source control options in order to eliminate deploying of buggy or unfinished code but to not sacrifice the somewhat asyncronous nature of the teams releases. I have used VSS, TFS, SVN and Bazaar in my career, but TFS is where most of my experience has been. Previously most teams I have worked with use a two or three branch solution of Dev-Test-Prod, where for a month developers work directly in Dev and then changes are merged to Test then Prod, or promoted "when its done" rather than on a fixed cycle. Automated builds were used, using either Cruise Control or Team Build. In my previous job Bazaar was used sitting on top of SVN: devs worked in their own small feature branches then pushed their changes to SVN (which was tied into TeamCity). This was nice in that it was easy to isolate changes and share them with other peoples branches. With both of these models there was a central dev and prod (and sometimes test) branch through which code was pushed (and labels were used to mark builds in prod from which releases were made...and these were made into branches for bug fixes to releases and merged back to dev). This doesn't really suit the way of working here, however: there is no order to when various features will be released, they get pushed when they are complete. With this requirement the "continuous integration" approach as I see it breaks down. To get a new feature out with continuous integration it has to be pushed via dev-test-prod and that will capture any unfinished work in dev. I am thinking that to overcome this we should go down a heavily feature branched model with NO dev-test-prod branches, rather the source should exist as a series of feature branches which when development work is complete are locked, tested, fixed, locked, tested and then released. Other feature branches can grab changes from other branches when they need/want, so eventually all changes get absorbed into everyone elses. This fits very much down a pure Bazaar model from what I experienced at my last job. As flexible as this sounds it just seems odd to not have a dev trunk or prod branch somewhere, and I am worried about branches forking never to re-integrate, or small late changes made that never get pulled across to other branches and developers complaining about merge disasters... What are peoples thoughts on this? A second final question: I am somewhat confused about the exact definition of distributed source control: some people seem to suggest it is about just not having a central repository like TFS or SVN, some say it is about being disconnected (SVN is 90% disconnected and TFS has a perfectly functional offline mode) and others say it is about Feature Branching and ease of merging between branches with no parent-child relationship (TFS also has baseless merging!). Perhaps this is a second question!

  Read the article

• What layer to introduce human readable error messages?

  - by MrLane

  One of the things that I have never been happy with on any project I have worked on over the years and have really not been able to resolve myself is exactly at what tier in an application should human readable error information be retrieved for display to a user. A common approach that has worked well has been to return strongly typed/concrete "result objects" from the methods on the public surface of the business tier/API. A method on the interface may be: public ClearUserAccountsResult ClearUserAccounts(ClearUserAccountsParam param); And the result class implementation: public class ClearUserAccountsResult : IResult { public readonly List<Account> ClearedAccounts{get; set;} public readonly bool Success {get; set;} // Implements IResult public readonly string Message{get; set;} // Implements IResult, human readable // Constructor implemented here to set readonly properties... } This works great when the API needs to be exposed over WCF as the result object can be serialized. Again this is only done on the public surface of the API/business tier. The error message can also be looked up from the database, which means it can be changed and localized. However, it has always been suspect to me, this idea of returning human readable information from the business tier like this, partly because what constitutes the public surface of the API may change over time...and it may be the case that the API will need to be reused by other API components in the future that do not need the human readable string messages (and looking them up from a database would be an expensive waste). I am thinking a better approach is to keep the business objects free from such result objects and keep them simple and then retrieve human readable error strings somewhere closer to the UI layer or only in the UI itself, but I have two problems here: 1) The UI may be a remote client (Winforms/WPF/Silverlight) or an ASP.NET web application hosted on another server. In these cases the UI will have to fetch the error strings from the server. 2) Often there are multiple legitimate modes of failure. If the business tier becomes so vague and generic in the way it returns errors there may not be enough information exposed publicly to tell what the error actually was: i.e: if a method has 3 modes of legitimate failure but returns a boolean to indicate failure, you cannot work out what the appropriate message to display to the user should be. I have thought about using failure enums as a substitute, they can indicate a specific error that can be tested for and coded against. This is sometimes useful within the business tier itself as a way of passing via method returns the specifics of a failure rather than just a boolean, but it is not so good for serialization scenarios. Is there a well worn pattern for this? What do people think? Thanks.

  Read the article

• Ninject/DI: How to correctly pass initialisation data to injected type at runtime

  - by MrLane

  I have the following two classes: public class StoreService : IStoreService { private IEmailService _emailService; public StoreService(IEmailService emailService) { _emailService = emailService; } } public class EmailService : IEmailService { } Using Ninject I can set up bindings no problem to get it to inject a concrete implementation of IEmailService into the StoreService constructor. StoreService is actually injected into the code behind of an ASP.NET WebForm as so: [Ninject.Inject] public IStoreService StoreService { get; set; } But now I need to change EmailService to accept an object that contains SMTP related settings (that are pulled from the ApplicationSettings of the Web.config). So I changed EmailService to now look like this: public class EmailService : IEmailService { private SMTPSettings _smtpSettings; public void SetSMTPSettings(SMTPSettings smtpSettings) { _smtpSettings = smtpSettings; } } Setting SMTPSettings in this way also requires it to be passed into StoreService (via another public method). This has to be done in the Page_Load method in the WebForms code behind (I only have access to the Settings class in the UI layer). With manual/poor mans DI I could pass SMTPSettings directly into the constructor of EmailService and then inject EmailService into the StoreService constructor. With Ninject I don't have access to the instances of injected types outside of the objects they are injected to, so I have to set their data AFTER Ninject has already injected them via a separate public setter method. This to me seems wrong. How should I really be solving this scenario?

  Read the article

• Windows 32-bit and 64-bit and GPT

  - by MrLane

  I know similar questions have been asked before across several sites, but the answers at least to me have been confusing and conflicting. My understanding has always been that 64-bit Windows will create and use GPT disks just fine, but will not boot from them without a UEFI BIOS. Also my understanding WAS that 32-bit Windows could not use GPT at all and so is always restricted to 2.2TB disks, which was another reason to move to 64-bit on top of the 4GB memory limit. But I have now read that this isn't correct: 32-bit Windows will create and use GPT disks just as 64-bit does. The only resriction is that you can't boot 32-bit Windows even if you DO have a UEFI BIOS? I don't think much of the literature has explained this well. There are several tools floating around for creating virtual disks or 2.2+.8GB partition schemes and such for 32-bit systems. Why when it seems you can use GPT in 32-bit Windows anyway. It also seems that people blame MS for lagging behind with respect to all of this: but it seems the issue is with BIOS manufactures not supporting UEFI rather than MS not supporting GPT... Is my new understanding now correct?

  Read the article

• WCF: Per-Call and Per-Session services...need convincing that Per-Call is worthwhile

  - by mrlane

  Hello all. We are currently doing a review of our WCF service design and one thing that is bothering me is the decision between Per-Call and Per-Session services. I believe I understand the concept behind both, but I am not really seeing the advantage of Per-Call services. I understand that the motivation for using Per-Call services is that a WCF services only holds a servier object for the life of a call thereby restricting the time that an expensive resource is held by the service instance, but to me its much simpler to use the more OO like Per-Session model where your proxy object instance always corrisponds to the same server object instance and just handle any expensive resources manually. For example, say I have a CRUD Service with Add, Update, Delete, Select methods on it. This could be done as a Per-Call service with database connection (the "expensive resource") instanciated in the server object constructor. Alternately it could be a Per-Session service with a database connection instanciated and closed within each CRUD method exposed. To me it is no different resource wise and it makes the programming model simpler as the client can be assured that they always have the same server object for their proxies: any in-expensive state that there may be between calls is maintained and no extra parameters are needed on methods to identify what state data must be retrieved by the service when it is instanciating a new server object again (as in the case of Per-Call). Its just like using classes and objects, where the same resource management issues apply, but we dont create new object instances for each method call we have on an object! So what am I missing with the Per-Call model? Thanks

  Read the article

• What is the practical difference between transport and message reliability in WCF?

  - by mrlane

  I am looking at differences between using WPF in .NET or using Silverlight 4 for the GUI front end of an app that connects to WCF services. I have read that net.tcp binding in Silverlight 4 only supports transport level reliability. With a WPF desktop app we can use message level reliability. What is the actual difference? If transport level reliability ensures that all TCP packets get through, doesnt that also mean that all WCF SOAP messages will also get through?

  Read the article

• Accessing Static Methods on a Generic class in c#

  - by mrlane

  Hello, I have the following situation in code, which I suspect may be a bit dodgey: I have a class: abstract class DataAccessBase<T> : IDataAccess where T : AnotherAbstractClass This class DataAccessBase also has a static factory method which creates instances of derived classes of itself using an enum value in a which statement to decide which derived type to create: static IDataAccess CreateInstance(TypeToCreateEnum) Now, the types derived from DataAccessBase<T> are themselves NOT generic, they specify a type for T: class PoLcZoneData : DataAccessBase<PoLcZone> // PoLcZone is derived from AnotherAbstractClass So far I am not sure if this is pushing the limits of good use of generics, but what I am really concerned about is how to access the static CreateInstance() method in the first place: The way I am doing this at the moment is to simply pass any type T where T : AnotherAbstractClass. In particular I am passing AnotherAbstractClass itself. This allows compilation just fine, but it does seem to me that passing any type to a generic class just to get at the statics is a bit dodgey. I have actually simplified the situation somewhat as DataAccessBase<T> is the lower level in the inheritance chain, but the static factory methods exists in a middle tier with classes such as PoLcZoneData being the most derived on the only level that is not generic. What are peoples thoughts on this arrangement?

  Read the article

• WCF Callback Contract InvalidOperationException: Collection has been modified

  - by mrlane

  We are using a WCF service with a Callback contract. Communication is Asynchronous. The service contract is defined as: [ServiceContract(Namespace = "Silverlight", CallbackContract = typeof(ISessionClient),SessionMode = SessionMode.Allowed)] public interface ISessionService With a method: [OperationContract(IsOneWay = true)] void Send(Message message); The callback contract is defined as [ServiceContract] public interface ISessionClient With methods: [OperationContract(IsOneWay = true, AsyncPattern = true)] IAsyncResult BeginSend(Message message, AsyncCallback callback, object state); void EndSend(IAsyncResult result); The implementation of BeginSend and EndSend in the callback channel are as follows: public void Send(ActionMessage actionMessage) { Message message = Message.CreateMessage(_messageVersion, CommsSettings.SOAPActionReceive, actionMessage, _messageSerializer); lock (LO_backChannel) { try { _backChannel.BeginSend(message, OnSendComplete, null); } catch (Exception ex) { _hasFaulted = true; } } } private void OnSendComplete(IAsyncResult asyncResult) { lock (LO_backChannel) { try { _backChannel.EndSend(asyncResult); } catch (Exception ex) { _hasFaulted = true; } } } We are getting an InvalidOperationException: "Collection has been modified" on _backChannel.EndSend(asyncResult) seemingly randomly, and we are really out of ideas about what is causing this. I understand what the exception means, and that concurrency issues are a common cause of such exceptions (hence the locks), but it really doesn't make any sense to me in this situation. The clients of our service are Silverlight 3.0 clients using PollingDuplexHttpBinding which is the only binding available for Silverlight. We have been running fine for ages, but recently have been doing a lot of data binding, and this is when the issues started. Any help with this is appreciated as I am personally stumped at this time.

  Read the article

• WCF: What is the practical difference between transport and message reliability?

  - by mrlane

  Hello I am looking at differences between using WPF in .NET or using Silverlight 4 for the GUI front end of an app that connects to WCF services. I have read that net.tcp binding in Silverlight 4 only supports transport level reliability. With a WPF desktop app we can use message level reliability. What is the actual difference? If transport level reliability ensures that all TCP packets get through, doesnt that also mean that all WCF SOAP messages will also get through? I am also concerned that Silverlight only supports async message but thats a different issue. Thanks

  Read the article

1