Search Results

Search found 3321 results on 133 pages for 'patterns'.

Page 30/133 | < Previous Page | 26 27 28 29 30 31 32 33 34 35 36 37  | Next Page >

• I know of three ways in which SRP helps reduce coupling. Are there even more? [closed]

  - by user1483278

  I'd like to figure all the possible ways SRP helps us reduce coupling. Thus far I can think of three: 1) If class A has more than one responsibility, these responsibilities become coupled and as such changes to one of these responsibilities may require changes to other of A's responsibilities. 2) Related functionality usually needs to be changed for the same reason and by grouping it togerther in a single class, the changes can be made in as few places as possible ( at best changes only need be made to the class which groups together these functionalities) 3) Assuming class A performs two tasks ( thus may change for two reasons ), then number of classes utilising A will be greater than if A performed just a single task ( reason being that some classes will need A to perform first task, other will need A for second task, and still others will utilise it for both tasks ).This also means that when A breaks, the number of classes ( utilising A ) being impaired will be greater than if A performed just a single task. Can SRP also help reduce coupling in any other way, not described above? Thank you

  Read the article

• How to control messages to the same port from different emitters?

  - by Alex In Paris

  Scene: A company has many factories X, each emits a message to the same receive port in a Biztalk server Y; if all messages are processed without much delay, each will trigger an outgoing message to another system Z. Problem: Sometimes a factory loses its connection for a half-day or more and, when the connection is reestablished, thousands of messages get emitted. Now, the messages still get processed well by Y (Biztalk can easily handle the load) but system Z can't handle the flood and may lock up and severely delay the processing of all other messages from the other X. What is the solution? Creating multiple receive locations that permits us to pause one X or another would lose us information if the factory isn't smart enough to know whether the message was received or not. What is the basic pattern to apply in Biztalk for this problem? Would some throttling parameters help to limit the flow from any one X? Or are their techniques on the end part of Y which I should use instead ? I would prefer this last one since I can be confident that the message box will remember any failures, which could then be resumed.

  Read the article

• Interfaces on an abstract class

  - by insta

  My coworker and I have different opinions on the relationship between base classes and interfaces. I'm of the belief that a class should not implement an interface unless that class can be used when an implementation of the interface is required. In other words, I like to see code like this: interface IFooWorker { void Work(); } abstract class BaseWorker { ... base class behaviors ... public abstract void Work() { } protected string CleanData(string data) { ... } } class DbWorker : BaseWorker, IFooWorker { public void Work() { Repository.AddCleanData(base.CleanData(UI.GetDirtyData())); } } The DbWorker is what gets the IFooWorker interface, because it is an instantiatable implementation of the interface. It completely fulfills the contract. My coworker prefers the nearly identical: interface IFooWorker { void Work(); } abstract class BaseWorker : IFooWorker { ... base class behaviors ... public abstract void Work() { } protected string CleanData(string data) { ... } } class DbWorker : BaseWorker { public void Work() { Repository.AddCleanData(base.CleanData(UI.GetDirtyData())); } } Where the base class gets the interface, and by virtue of this all inheritors of the base class are of that interface as well. This bugs me but I can't come up with concrete reasons why, outside of "the base class cannot stand on its own as an implementation of the interface". What are the pros & cons of his method vs. mine, and why should one be used over another?

  Read the article

• Correct way to inject dependencies in Business logic service?

  - by Sri Harsha Velicheti

  Currently the structure of my application is as below Web App -- WCF Service (just a facade) -- Business Logic Services -- Repository - Entity Framework Datacontext Now each of my Business logic service is dependent on more than 5 repositories ( I have interfaces defined for all the repos) and I am doing a Constructor injection right now(poor mans DI instead of using a proper IOC as it was determined that it would be a overkill for our project). Repositories have references to EF datacontexts. Now some of the methods in the Business logic service require only one of the 5 repositories, so If I need to call that method I would end up instantiating a Service which will instatiate all 5 repositories which is a waste. An example: public class SomeService : ISomeService { public(IFirstRepository repo1, ISecondRepository repo2, IThirdRepository repo3) {} // My DoSomething method depends only on repo1 and doesn't use repo2 and repo3 public DoSomething() { //uses repo1 to do some stuff, doesn't use repo2 and repo3 } public DoSomething2() { //uses repo2 and repo3 to do something, doesn't require repo1 } public DoSomething3() { //uses repo3 to do something, doesn't require repo1 and repo2 } } Now if my I have to use DoSomething method on SomeService I end up creating both IFirstRepository,ISecondRepository and IThirdRepository but using only IFirstRepository, now this is bugging me, I can seem to accept that I am un-necessarily creating repositories and not using them. Is this a correct design? Are there any better alternatives? Should I be looking at Lazy instantiation Lazy<T> ?

  Read the article

• Design pattern: static function call with input/output containers?

  - by Pavlo Dyban

  I work for a company in software research department. We use algorithms from our real software and wrap them so that we can use them for prototyping. Every time an algorithm interface changes, we need to adapt our wrappers respectively. Recently all algorithms have been refactored in such a manner that instead of accepting many different inputs and returning outputs via referenced parameters, they now accept one input data container and one output data container (the latter is passed by reference). Algorithm interface is limited to a static function call like that: class MyAlgorithm{ static bool calculate(MyAlgorithmInput input, MyAlgorithmOutput &output); } This is actually a very powerful design, though I have never seen it in a C++ programming environment before. Changes in the number of parameters and their data types are now encapsulated and they don't change the algorithm callback. In the latest algorithm which I have developed I used the same scheme. Now I want to know if this is a popular design pattern and what it is called.

  Read the article

• Visitor-pattern vs inheritance for rendering

  - by akaltar

  I have a game engine that currently uses inheritance to provide a generic interface to do rendering: class renderable { public: void render(); }; Each class calls the gl_* functions itself, this makes the code hard to optimize and hard to implement something like setting the quality of rendering: class sphere : public renderable { public: void render() { glDrawElements(...); } }; I was thinking about implementing a system where I would create a Renderer class that would render my objects: class sphere { void render( renderer* r ) { r->renderme( *this ); } }; class renderer { renderme( sphere& sphere ) { // magically get render resources here // magically render a sphere here } }; My main problem is where should I store the VBOs and where should I Create them when using this method? Should I even use this approach or stick to the current one, perhaps something else? PS: I already asked this question on SO but got no proper answers.

  Read the article

• Motivation for service layer (instead of just copying dlls)?

  - by BornToCode

  I'm creating an application which has 2 different UIs so I'm making it with a service layer which I understood is appropriate for such case. However I found myself just creating web methods for every single method I have in the BL layer, so the services basically built from methods that looks like this: return customers_bl.Get_Customer_Prices(customer_id); I understood that a main point of the service layer is to prevent duplication of code so I asked myself - well, why not just import the BL.dll (and the DAL.dll) to the other UI, and whenever making a change re-copy the dll files, it might not be so 'neat', but is the all purpose of the service layer to prevent this? {I know something is wrong in my approach, I'm probably missing the importance of service layer, I'd like to get more motivation to create another layer, especially because as it is I found that many of my BL functions ALREADY looks like: return customers_dal.Get_Customer_Prices(cust_id) which led me to ask: was it really necessary to create the BL just because on several functions I actually have LOGIC inside the BL?} so I'm looking for more motivation to creating ONE MORE layer, I'm sure it's not just to make it more convenient that I won't have to re-copy the dlls on changes? Am I grasping it wrong? Any simple guidelines on how to design service layer (corresponding to all the BL layer functions or not? any simple example?) any enlightenment on the subject?

  Read the article

• Should this code/logic be included in Business Objects class or a separate class?

  - by aspdotnetuser

  I have created a small application which has a three tier architecture and I have business object classes to represent entities such as User, Orders, UserType etc. In these classes I have methods that are executed when the Constuctor method of, for example, User is called. These methods perform calculations and generate details that setup data for attributes that are part of each User object. Here is the structure for the project in Visual Studio: Here is some code from the business object class User.cs: Public Class User { public string Name { get; set; } public int RandomNumber { get; set; } etc public User { Name = GetName(); RandomNumber = GetRandomNumber(); } public string GetName() { .... return name; } public int GetRandomNumber() { ... return randomNumber; } } Should this logic be included in the Business Object classes or should it be included in a Utilities class of some kind? Or in the business rules?

  Read the article

• How do you plan your asynchronous code?

  - by NullOrEmpty

  I created a library that is a invoker for a web service somewhere else. The library exposes asynchronous methods, since web service calls are a good candidate for that matter. At the beginning everything was just fine, I had methods with easy to understand operations in a CRUD fashion, since the library is a kind of repository. But then business logic started to become complex, and some of the procedures involves the chaining of many of these asynchronous operations, sometimes with different paths depending on the result value, etc.. etc.. Suddenly, everything is very messy, to stop the execution in a break point it is not very helpful, to find out what is going on or where in the process timeline have you stopped become a pain... Development becomes less quick, less agile, and to catch those bugs that happens once in a 1000 times becomes a hell. From the technical point, a repository that exposes asynchronous methods looked like a good idea, because some persistence layers could have delays, and you can use the async approach to do the most of your hardware. But from the functional point of view, things became very complex, and considering those procedures where a dozen of different calls were needed... I don't know the real value of the improvement. After read about TPL for a while, it looked like a good idea for managing tasks, but in the moment you have to combine them and start to reuse existing functionality, things become very messy. I have had a good experience using it for very concrete scenarios, but bad experience using them broadly. How do you work asynchronously? Do you use it always? Or just for long running processes? Thanks.

  Read the article

• Using packages (gems, eggs, etc.) to create decoupled architectures

  - by Juan Carlos Coto

  The main issue Seeing the good support most modern programming platforms have for package management (think gem, npm, pip, etc), does it make sense to design an application or system be composed of internally developed packages, so as to promote and create a loosely coupled architecture? Example An example of this would be to create packages for database access, as well as for authentication and other components of the system. These, of course, use external packages as well. Then, your system imports and uses these packages - instead of including their code within its own code base. Considerations To me, it seems that this would promote code decoupling and help maintainability, almost in a Web-based-vs.-desktop-application kind of way (updates are applied almost automatically, single code base for single functionality, etc.). Does this seem like a rational and sane design concept? Is this actually used as a standard way of structuring applications today? Thanks very much!

  Read the article

• Best practice to collect information from child objects

  - by Markus

  I'm regularly seeing the following pattern: public abstract class BaseItem { BaseItem[] children; // ... public void DoSomethingWithStuff() { StuffCollection collection = new StuffCollection(); foreach(child c : children) c.AddRequiredStuff(collection); // do something with the collection ... } public abstract void AddRequiredStuff(StuffCollection collection); } public class ConcreteItem : BaseItem { // ... public override void AddRequiredStuff(StuffCollection collection) { Stuff stuff; // ... collection.Add(stuff); } } Where I would use something like this, for better information hiding: public abstract class BaseItem { BaseItem[] children; // ... public void DoSomethingWithStuff() { StuffCollection collection = new StuffCollection(); foreach(child c : children) collection.AddRange(c.RequiredStuff()); // do something with the collection ... } public abstract StuffCollection RequiredStuff(); } public class ConcreteItem : BaseItem { // ... public override StuffCollection RequiredStuff() { StuffCollection stuffCollection; Stuff stuff; // ... stuffCollection.Add(stuff); return stuffCollection; } } What are pros and cons of each solution? For me, giving the implementation access to parent's information is some how disconcerting. On the other hand, initializing a new list, just to collect the items is a useless overhead ... What is the better design? How would it change, if DoSomethingWithStuff wouldn't be part of BaseItem but a third class? PS: there might be missing semicolons, or typos; sorry for that! The above code is not meant to be executed, but just for illustration.

  Read the article

• What Design Pattern is seperating transform converters

  - by RevMoon

  For converting a Java object model into XML I am using the following design: For different types of objects (e.g. primitive types, collections, null, etc.) I define each its own converter, which acts appropriate with respect to the given type. This way it can easily extended without adding code to a huge if-else-then construct. The converters are chosen by a method which tests whether the object is convertable at all and by using a priority ordering. The priority ordering is important so let's say a List is not converted by the POJO converter, even though it is convertable as such it would be more appropriate to use the collection converter. What design pattern is that? I can only think of a similarity to the command pattern.

  Read the article

• What are the caveats of the event system built on Messenger rather than on classic .NET events?

  - by voroninp

  MVVM Light and PRISM offer messenger to implement event system. the approximate interface looks like the following one: interface Messanger { void Subscribe<TMessageParam>(Action<TMessageParam> action); void Unsubscribe<TMessageParam>(Action<TMessageParam> action); void Unsubscribe<TMessageParam>(objec actionOwner); void Notify<TMessageParam>(TMessageParam param); } Now this model seems beneficial comparing to classic .net events. It works well with Dependency Injection. Actions are stored as weak references so memory leaks are avioded and unsubscribe is not a must. The only annoyance is the need to declare new TMessageParam for each specific message. But everything comes at a cost. And what I'm really worried about is that I see no shortcomings of this approach. Has anoyne the experience of some troubles with this design pattern?

  Read the article

• Is it dangerous for me to give some of my Model classes Control-like methods?

  - by Pureferret

  In my personal project I have tried to stick to MVC, but I've also been made aware that sticking to MVC too tightly can be a bad thing as it makes writing awkward and forces the flow of the program in odd ways (i.e. some simple functions can be performed by something that normally wouldn't, and avoid MVC related overheads). So I'm beginning to feel justified in this compromise: I have some 'manager programs' that 'own' data and have some way to manipulate it, as such I think they'd count as both part of the model, and part of the control, and to me this feels more natural than keepingthem separate. For instance: One of my Managers is the PlayerCharacterManager that has these methods: void buySkill(PlayerCharacter playerCharacter, Skill skill); void changeName(); void changeRole(); void restatCharacter(); void addCharacterToGame(); void createNewCharacter(); PlayerCharacter getPlayerCharacter(); List<PlayerCharacter> getPlayersCharacter(Player player); List<PlayerCharacter> getAllCharacters(); I hope the mothod names are transparent enough that they don't all need explaining. I've called it a manager because it will help manage all of the PlayerCharacter 'model' objects the code creates, and create and keep a map of these. I may also get it to store other information in the future. I plan to have another two similar classes for this sort of control, but I will orchestrate when and how this happens, and what to do with the returned data via a pure controller class. This splitting up control between informed managers and the controller, as opposed to operating just through a controller seems like it will simplify my code and make it flow more. My question is, is this a dangerous choice, in terms of making the code harder to follow/test/fix? Is this somethign established as good or bad or neutral? I oculdn't find anything similar except the idea of Actors but that's not quite why I'm trying to do. Edit: Perhaps an example is needed; I'm using the Controller to update the view and access the data, so when I click the 'Add new character to a player button' it'll call methods in the controller that then go and tell the PlayerCharacterManager class to create a new character instance, it'll call the PlayerManager class to add that new character to the player-character map, and then it'll add this information to the database, and tell the view to update any GUIs effected. That is the sort of 'control sequence' I'm hoping to create with these manager classes.

  Read the article

• Any recommended books/resources on component-based design?

  - by user1163640

  I come from a background with heavy use of the classical object-oriented paradigm for software development. The company I am a part of switched to Unity not too long ago, and we're all very excited to get started using it However, one aspect that have sparked my interested, and which I think will become a very important part of our future development, is Unity's approach to component-based design with scripting; with less focus on typical hierarchical aspect. Question I was wondering if anyone could recommend any good books on this subject? I have had trouble finding any books or books with reliable reviews, and was wondering if anyone more experienced here had something to say on the issue? Any other kind of resource would be excellent too, I'm just interested in getting to learn everything I can about it. This is not meant as a discussion about best books or resources on the topic, but simply a question regarding any resources that any of you find useful. Thank you all for your time!

  Read the article

• When decomposing a large function, how can I avoid the complexity from the extra subfunctions?

  - by missingno

  Say I have a large function like the following: function do_lots_of_stuff(){ { //subpart 1 ... } ... { //subpart N ... } } a common pattern is to decompose it into subfunctions function do_lots_of_stuff(){ subpart_1(...) subpart_2(...) ... subpart_N(...) } I usually find that decomposition has two main advantages: The decomposed function becomes much smaller. This can help people read it without getting lost in the details. Parameters have to be explicitly passed to the underlying subfunctions, instead of being implicitly available by just being in scope. This can help readability and modularity in some situations. However, I also find that decomposition has some disadvantages: There are no guarantees that the subfunctions "belong" to do_lots_of_stuff so there is nothing stopping someone from accidentally calling them from a wrong place. A module's complexity grows quadratically with the number of functions we add to it. (There are more possible ways for things to call each other) Therefore: Are there useful convention or coding styles that help me balance the pros and cons of function decomposition or should I just use an editor with code folding and call it a day? EDIT: This problem also applies to functional code (although in a less pressing manner). For example, in a functional setting we would have the subparts be returning values that are combined in the end and the decomposition problem of having lots of subfunctions being able to use each other is still present. We can't always assume that the problem domain will be able to be modeled on just some small simple types with just a few highly orthogonal functions. There will always be complicated algorithms or long lists of business rules that we still want to correctly be able to deal with. function do_lots_of_stuff(){ p1 = subpart_1() p2 = subpart_2() pN = subpart_N() return assembleStuff(p1, p2, ..., pN) }

  Read the article

• Main class passes dbConn obj to all its services, I need to change the dbConn for one of its services. - suggestion for design pattern

  - by tech_learner

  There is this main class and there are several services ( which uses db connection to retrieve data ) These services are initialized in the main class db properties are obtained from the property file and then dbconnection is opened by calling a method dbOpen() written in the main class and the resultant connection object is set to the service objects by iterating through the list of services and by calling setConnection method on the service note: that the services are instantiated in the main class and the main class is not a superclass for services. I also need to mention that there is this recycle db connection scenario only main class is aware of. /** connects to DB, optionally recycling existing connection), * throws RuntimeException if unable to connect */ private void connectDb(boolean recycle) { try { if (recycle) { log.status( log.getSB().append("Recycling DB Connection") ); closeDb(); } openDb(); for ( int i = 0 ; i < service.length ; i++ ) { service[i].setConnection(db); } } One of the service needs to use a different database, what is the best design pattern to use?

  Read the article

• Many ui panels needs interaction with same object

  - by user877329

  I am developing a tool for simulating systems like the Gray-Scott model (That is systems where spatial distribution depends on time). The actual model is loaded from a DLL or shared object and the simulation is performed by a Simulation object. There are at least two situations when the simulation needs to be destroyed: The user loads a new model The user changes the size of the domain To make sure nothing goes wrong, the current Model, Simulation, and rendering Thread are all managed by an ApplicationState object. But the two cases above are initiated from two different UI objects. Is it then ok to distribute a reference to the ApplicationState object to all panels that need to access at least one method on the ApplicationState object? Another solution would be to use aggregation so that the panel from which the user chooses model knows the simulation parameter panel. Also, the ApplicationState class seems somewhat clumsy, so I would like to have something else

  Read the article

• Motivation for a service layer (instead of just copying dlls)?

  - by BornToCode

  I'm creating an application which has 2 different UIs so I'm making it with a service layer which I understood is appropriate for such scenario. However I found myself just creating web methods for every single method I have in the BL layer, so the services basically built from methods that looks like this: return customers_bl.Get_Customer_Prices(customer_id); I understood that a main point of the service layer is to prevent duplication of code so I asked myself - why not just import the BL.DLL (and the dal.dll) to the other UI, and whenever making a change re-copy the dlls, it might not be so 'neat', but still less hassle than one more layer? {I know something is wrong in my approach, I'm probably missing the importance of service layer, I'd like to get more motivation to create another layer, especially because as it is I found that many of my BL functions ALREADY looks like: return customers_dal.Get_Customer_Prices(cust_id) which led me to ask: was it really necessary to create the BL just because on several functions I actually have LOGIC inside the BL?} so I'm looking for more motivation to creating ONE MORE layer, I'm sure it's not just to make it more convenient that I won't have to re-copy the dlls on changes? Am I grasping it wrong? Any simple guidelines on how to design service layer (corresponding to all the BL layer functions or not? any simple example?) any enlightenment on the subject?

  Read the article

• Lazy Processing of Streams

  - by Giorgio

  I have the following problem scenario: I have a text file and I have to read it and split it into lines. Some lines might need to be dropped (according to criteria that are not fixed). The lines that are not dropped must be parsed into some predefined records. Records that are not valid must be dropped. Duplicate records may exist and, in such a case, they are consecutive. If duplicate / multiple records exist, only one item should be kept. The remaining records should be grouped according to the value contained in one field; all records belonging to the same group appear one after another (e.g. AAAABBBBCCDEEEFF and so on). The records of each group should be numbered (1, 2, 3, 4, ...). For each group the numbering starts from 1. The records must then be saved somewhere / consumed in the same order as they were produced. I have to implement this in Java or C++. My first idea was to define functions / methods like: One method to get all the lines from the file. One method to filter out the unwanted lines. One method to parse the filtered lines into valid records. One method to remove duplicate records. One method to group records and number them. The problem is that the data I am going to read can be too big and might not fit into main memory: so I cannot just construct all these lists and apply my functions one after the other. On the other hand, I think I do not need to fit all the data in main memory at once because once a record has been consumed all its underlying data (basically the lines of text between the previous record and the current record, and the record itself) can be disposed of. With the little knowledge I have of Haskell I have immediately thought about some kind of lazy evaluation, in which instead of applying functions to lists that have been completely computed, I have different streams of data that are built on top of each other and, at each moment, only the needed portion of each stream is materialized in main memory. But I have to implement this in Java or C++. So my question is which design pattern or other technique can allow me to implement this lazy processing of streams in one of these languages.

  Read the article

• Dynamic Strategy Pattern [migrated]

  - by Karl Barker

  So I'm writing a web service architecture which includes FunctionProvider classes which do the actual processing of requests, and a main Endpoint class which receives and delegates requests to the proper FunctionProvider. I don't know exactly the FunctionProviders available at runtime, so I need to be able to 'register' (if that's the right word) them with my main Endpoint class, and query them to see if they match an incoming request. public class MyFunc implements FunctionProvider{ static { MyEndpoint.register(MyFunc); } public Boolean matchesRequest(Request req){...} public void processRequest(Request req){...} } public class MyEndpoint{ private static ArrayList<FunctionProvider> functions = new ArrayList<FunctionProvider>(); public void register(Class clz){ functions.add(clz); } public void doPost(Request request){ //find the FunctionProvider in functions //matching the request } } I've really not done much reflective Java like this (and the above is likely wrong, but hopefully demonstrates my intentions). What's the nicest way to implement this without getting hacky?

  Read the article

• What is the good way of sharing specific data between ViewModels

  - by voroninp

  We have IAppContext which is injected into ViewModel. This service contains shared data: global filters and other application wide properties. But there are cases when data is very specific. For example one VM implements Master and the second one - Details of selected tree item. Thus DetailsVm must know about the selected item and its changes. We can store this information either in IAppContext or inside each concerned VM. In both cases update notifications are sent via Messenger. I see pros and cons for any of the approaches and can not decide which one is better. 1st: + explicitly exposed shared proerties, easy to follow dependencies - IAppContxt becomes cluttered with very specific data. 2nd: the exact opposite of the first and more memory load due to data duplication. May be someone can offer design alternatives or tell that one of the variants is objectively superior to the other cause I miss something important?

  Read the article

• Implenting ActiveRecord with inheritance?

  - by King

  I recently converted an old application that was using XML files as the data store to use SQL instead. To avoid a lot of changes I basically created ActiveRecord style classes that inherited from the original business objects. For example SomeClassRecord :SomeClass //ID Property //Save method I then used this new class in place of the other one, because of polymorphism I didn't need to change any methods that took SomeClass as a parameter. Would this be considered 'Bad'? What would be a better alternative?

  Read the article

• Is "convention over configuration" not violating basic programming principles?

  - by Geerten

  I was looking at the WPF MVVM framework Caliburn.Micro and read that a lot of standard things are based on naming conventions. For example, automatic binding of properties in the View to properties in the ViewModel. Although this seems to be convenient (removes some boilerplate code), my first instinct reaction is that it isn't completely obvious to a new programmer that will read this code. In other words, the functionality of the application is not completely explained by its own code, but also by the documentation of the framework. EDIT: So this approach is called convention over configuration. Since I could not find any questions concerning this, I altered my question: My question is: Is convention over configuration a correct way of simplifying things, or is it violating some programming principles (and if so, which ones)?

  Read the article

• Guidelines or Design pattern to develop configurable software

  - by Rumit Parakhiya

  I want to develop an application which would have it's own framework, using which developer can implement functionality very easily. Developer shouldn't have to code for each and every page or report. But, he can do it very easily by just configuring it using the framework provided. Some nice examples of it is SAP and Tally. They have got their own framework, using which anybody having knowledge of it can customize or extend functionality of the product. But, as I am beginner in this direction, I don't have any idea about where to start. Can anybody point me to some design pattern which I can follow or some similar open source software which I can refer?

  Read the article

< Previous Page | 26 27 28 29 30 31 32 33 34 35 36 37  | Next Page >