Search Results

Search found 15860 results on 635 pages for 'document oriented databas'.

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

• How can a collection class instantiate many objects with one database call?

  - by Buttle Butkus

  I have a baseClass where I do not want public setters. I have a load($id) method that will retrieve the data for that object from the db. I have been using static class methods like getBy($property,$values) to return multiple class objects using a single database call. But some people say that static methods are not OOP. So now I'm trying to create a baseClassCollection that can do the same thing. But it can't, because it cannot access protected setters. I don't want everyone to be able to set the object's data. But it seems that it is an all-or-nothing proposition. I cannot give just the collection class access to the setters. I've seen a solution using debug_backtrace() but that seems inelegant. I'm moving toward just making the setters public. Are there any other solutions? Or should I even be looking for other solutions?

  Read the article

• What if globals make sense?

  - by Greg

  I've got a value that many objects need. For example, a financial application with different investments as objects, and most of them need the current interest rate. I was hoping to encapsulate my "financial environment" as an object, with the interest rate as a property. But, sibling objects that need that value can't get to it. So how do I share values among many objects without over-coupling my design? Obviously I'm thinking about this wrong.

  Read the article

• Generate a Word document from list data

  - by PeterBrunone

  This came up on a discussion list lately, so I threw together some code to meet the need.  In short, a colleague needed to take the results of an InfoPath form survey and give them to the user in Word format.  The form data was already in a list item, so it was a simple matter of using the SharePoint API to get the list item, formatting the data appropriately, and using response headers to make the client machine treat the response as MS Word content.  The following rudimentary code can be run in an ASPX (or an assembly) in the 12 hive.  When you link to the page, send the list name and item ID in the querystring and use them to grab the appropriate data. // Clear the current response headers and set them up to look like a word doc.HttpContext.Current.Response.Clear();HttpContext.Current.Response.Charset ="";HttpContext.Current.Response.ContentType ="application/msword";string strFileName = "ThatWordFileYouWanted"+ ".doc";HttpContext.Current.Response.AddHeader("Content-Disposition", "inline;filename=" + strFileName);// Using the current site, get the List by name and then the Item by ID (from the URL).string myListName = HttpContext.Current.Request.Querystring["listName"];int myID = Convert.ToInt32(HttpContext.Current.Request.Querystring["itemID"]);SPSite oSite = SPContext.Current.Site;SPWeb oWeb = oSite.OpenWeb();SPList oList = oWeb.Lists["MyListName"];SPListItem oListItem = oList.Items.GetItemById(myID);// Build a string with the data -- format it with HTML if you like. StringBuilder strHTMLContent = newStringBuilder();// *// Here's where you pull individual fields out of the list item.// *// Once everything is ready, spit it out to the client machine.HttpContext.Current.Response.Write(strHTMLContent);HttpContext.Current.Response.End();HttpContext.Current.Response.Flush();

  Read the article

• How to verify the Liskov substitution principle in an inheritance hierarchy?

  - by Songo

  Inspired by this answer: Liskov Substitution Principle requires that Preconditions cannot be strengthened in a subtype. Postconditions cannot be weakened in a subtype. Invariants of the supertype must be preserved in a subtype. History constraint (the "history rule"). Objects are regarded as being modifiable only through their methods (encapsulation). Since subtypes may introduce methods that are not present in the supertype, the introduction of these methods may allow state changes in the subtype that are not permissible in the supertype. The history constraint prohibits this. I was hoping if someone would post a class hierarchy that violates these 4 points and how to solve them accordingly. I'm looking for an elaborate explanation for educational purposes on how to identify each of the 4 points in the hierarchy and the best way to fix it. Note: I was hoping to post a code sample for people to work on, but the question itself is about how to identify the faulty hierarchies :)

  Read the article

• Law of Demeter confusion [duplicate]

  - by user2158382

  This question already has an answer here: Rails: Law of Demeter Confusion 4 answers I am reading a book called Rails AntiPatterns and they talk about using delegation to to avoid breaking the Law of Demeter. Here is their prime example: They believe that calling something like this in the controller is bad (and I agree) @street = @invoice.customer.address.street Their proposed solution is to do the following: class Customer has_one :address belongs_to :invoice def street address.street end end class Invoice has_one :customer def customer_street customer.street end end @street = @invoice.customer_street They are stating that since you only use one dot, you are not breaking the Law of Demeter here. I think this is incorrect, because you are still going through customer to go through address to get the invoice's street. I primarily got this idea from a blog post I read: http://www.dan-manges.com/blog/37 In the blog post the prime example is class Wallet attr_accessor :cash end class Customer has_one :wallet # attribute delegation def cash @wallet.cash end end class Paperboy def collect_money(customer, due_amount) if customer.cash < due_ammount raise InsufficientFundsError else customer.cash -= due_amount @collected_amount += due_amount end end end The blog post states that although there is only one dot customer.cash instead of customer.wallet.cash, this code still violates the Law of Demeter. Now in the Paperboy collect_money method, we don't have two dots, we just have one in "customer.cash". Has this delegation solved our problem? Not at all. If we look at the behavior, a paperboy is still reaching directly into a customer's wallet to get cash out. Can somebody help me clear the confusion. I have been searching for the past 2 days trying to let this topic sink in, but it is still confusing.

  Read the article

• Do objects maintain identity under all non-cloning conditions in PHP?

  - by Buttle Butkus

  PHP 5.5 I'm doing a bunch of passing around of objects with the assumption that they will all maintain their identities - that any changes made to their states from inside other objects' methods will continue to hold true afterwards. Am I assuming correctly? I will give my basic structure here. class builder { protected $foo_ids = array(); // set in construct protected $foo_collection; protected $bar_ids = array(); // set in construct protected $bar_collection; protected function initFoos() { $this->foo_collection = new FooCollection(); foreach($this->food_ids as $id) { $this->foo_collection->addFoo(new foo($id)); } } protected function initBars() { // same idea as initFoos } protected function wireFoosAndBars(fooCollection $foos, barCollection $bars) { // arguments are passed in using $this->foo_collection and $this->bar_collection foreach($foos as $foo_obj) { // (foo_collection implements IteratorAggregate) $bar_ids = $foo_obj->getAssociatedBarIds(); if(!empty($bar_ids) ) { $bar_collection = new barCollection(); // sub-collection to be a component of each foo foreach($bar_ids as $bar_id) { $bar_collection->addBar(new bar($bar_id)); } $foo_obj->addBarCollection($bar_collection); // now each foo_obj has a collection of bar objects, each of which is also in the main collection. Are they the same objects? } } } } What has me worried is that foreach supposedly works on a copy of its arrays. I want all the $foo and $bar objects to maintain their identities no matter which $collection object they become of a part of. Does that make sense?

  Read the article

• Handling array passed to object at creation

  - by cecilli0n

  When creating my object I pass it an array of a row from my database. (everything in the array we will need, disregarding unnecessary elements at sql query level) When I need to access certain array elements from within my class, I do so like $this->row['element'] However, As I continue development, I sometimes forget what exactly is in this passed array.(this itself doesn't seem good) I am wondering if their is a professional approach to dealing with this, Or am I the only one who has these "I wonder whats in the array" thoughts. One approach to tackling this could be that when we originally pass the array, in the constructor, we assign each element of the array to its own variable, but is this considered professional practice? Additionally by doing this, we could make those variables constants, in a attempt at immutability. Overall I am trying to adhere to good software craftsmanship. Regards.

  Read the article

• How to improve programming skills?

  - by Mike

  I'm very new to programming. I started learning PHP about half a year ago, so I do know something. I can write small functions, I can export and import information from a database and I can make a website. I don't know OOP principles and I don't know about objects and classes. Should I move to OOP principles and learn about classes, methods and objects? If not, what should I do? Continue writing simple code? How can a programmer write his/her own API? Is OOP necessary to do this? So how can i improve my skills? I love programming. I spend my 24/7 on it, so any help will be appreciated.

  Read the article

• Handling Types for Real and Complex Matrices in a BLAS Wrapper

  - by mga

  I come from a C background and I'm now learning OOP with C++. As an exercise (so please don't just say "this already exists"), I want to implement a wrapper for BLAS that will let the user write matrix algebra in an intuitive way (e.g. similar to MATLAB) e.g.: A = B*C*D.Inverse() + E.Transpose(); My problem is how to go about dealing with real (R) and complex (C) matrices, because of C++'s "curse" of letting you do the same thing in N different ways. I do have a clear idea of what it should look like to the user: s/he should be able to define the two separately, but operations would return a type depending on the types of the operands (R*R = R, C*C = C, R*C = C*R = C). Additionally R can be cast into C and vice versa (just by setting the imaginary parts to 0). I have considered the following options: As a real number is a special case of a complex number, inherit CMatrix from RMatrix. I quickly dismissed this as the two would have to return different types for the same getter function. Inherit RMatrix and CMatrix from Matrix. However, I can't really think of any common code that would go into Matrix (because of the different return types). Templates. Declare Matrix<T> and declare the getter function as T Get(int i, int j), and operator functions as Matrix *(Matrix RHS). Then specialize Matrix<double> and Matrix<complex>, and overload the functions. Then I couldn't really see what I would gain with templates, so why not just define RMatrix and CMatrix separately from each other, and then overload functions as necessary? Although this last option makes sense to me, there's an annoying voice inside my head saying this is not elegant, because the two are clearly related. Perhaps I'm missing an appropriate design pattern? So I guess what I'm looking for is either absolution for doing this, or advice on how to do better.

  Read the article

• How to make a queue switches from FIFO mode to priority mode?

  - by enzom83

  I would like to implement a queue capable of operating both in the FIFO mode and in the priority mode. This is a message queue, and the priority is first of all based on the message type: for example, if the messages of A type have higher priority than the messages of the B type, as a consequence all messages of A type are dequeued first, and finally the messages of B type are dequeued. Priority mode: my idea consists of using multiple queues, one for each type of message; in this way, I can manage a priority based on the message type: just take first the messages from the queue at a higher priority and progressively from lower priority queues. FIFO mode: how to handle FIFO mode using multiple queues? In other words, the user does not see multiple queues, but it uses the queue as if it were a single queue, so that the messages leave the queue in the order they arrive when the priority mode is disabled. In order to achieve this second goal I have thought to use a further queue to manage the order of arrival of the types of messages: let me explain better with the following code snippet. int NUMBER_OF_MESSAGE_TYPES = 4; int CAPACITY = 50; Queue[] internalQueues = new Queue[NUMBER_OF_MESSAGE_TYPES]; Queue<int> queueIndexes = new Queue<int>(CAPACITY); void Enqueue(object message) { int index = ... // the destination queue (ie its index) is chosen according to the type of message. internalQueues[index].Enqueue(message); queueIndexes.Enqueue(index); } object Dequeue() { if (fifo_mode_enabled) { // What is the next type that has been enqueued? int index = queueIndexes.Dequeue(); return internalQueues[index].Dequeue(); } if (priority_mode_enabled) { for(int i=0; i < NUMBER_OF_MESSAGE_TYPES; i++) { int currentQueueIndex = i; if (!internalQueues[currentQueueIndex].IsEmpty()) { object result = internalQueues[currentQueueIndex].Dequeue(); // The following statement is fundamental to a subsequent switching // from priority mode to FIFO mode: the messages that have not been // dequeued (since they had lower priority) remain in the order in // which they were queued. queueIndexes.RemoveFirstOccurrence(currentQueueIndex); return result; } } } } What do you think about this idea? Are there better or more simple implementations?

  Read the article

• Is having 'Util' classes a cause for concern? [closed]

  - by Matt Fenwick

  I sometimes create 'Util' classes which primarily serve to hold methods and values that don't really seem to belong elsewhere. But every time I create one of these classes, I think "uh-oh, I'm gonna regret this later ...", because I read somewhere that it's bad. But on the other hand, there seem to be two compelling (at least for me) cases for them: implementation secrets that are used in multiple classes within a package providing useful functionality to augment a class, without cluttering its interface Am I on the way to destruction? What you say !! Should I refactor?

  Read the article

• overriding implemented base class methods

  - by user793468

  I read somewhere that the chain of inheritance breaks when you alter a behavior from derived class. What does "altering a behavior" mean here? Is overriding an already implemented method in base class considered as "altering behavior"? Or, does the author mean altering method signatures and the output? Also, I ready Duplicating code is not a good practice, and its a maintenance nightmare. Again, does overriding an already implemented method in base class considered "Duplicating code"? If not, what would be considered as "Duplicating code"? I

  Read the article

• Are injectable classes allowed to have constructor parameters in DI?

  - by Songo

  Given the following code: class ClientClass{ public function print(){ //some code to calculate $inputString $parser= new Parser($inputString); $result= $parser->parse(); } } class Parser{ private $inputString; public __construct($inputString){ $this->inputString=$inputString; } public function parse(){ //some code } } Now the ClientClass has dependency on class Parser. However, if I wanted to use Dependency Injection for unit testing it would cause a problem because now I can't send the input string to the parser constructor like before as its calculated inside ClientCalss itself: class ClientClass{ private $parser; public __construct(Parser $parser){ $this->parser=$parser; } public function print(){ //some code to calculate $inputString $result= $this->parser->parse(); //--> will throw an exception since no string was provided } } The only solution I found was to modify all my classes that took parameters in their constructors to utilize Setters instead (example: setInputString()). However, I think there might be a better solution than this because sometimes modifying existing classes can cause much harm than benefit. So, Are injectable classes not allowed to have input parameters? If a class must take input parameters in its constructor, what would be the way to inject it properly? UPDATE Just for clarification, the problem happens when in my production code I decide to do this: $clientClass= new ClientClass(new Parser($inputString));//--->I have no way to predict $inputString as it is calculated inside `ClientClass` itself. UPDATE 2 Again for clarification, I'm trying to find a general solution to the problem not for this example code only because some of my classes have 2, 3 or 4 parameters in their constructors not only one.

  Read the article

• Rails: The Law of Demeter [duplicate]

  - by user2158382

  This question already has an answer here: Rails: Law of Demeter Confusion 4 answers I am reading a book called Rails AntiPatterns and they talk about using delegation to to avoid breaking the Law of Demeter. Here is their prime example: They believe that calling something like this in the controller is bad (and I agree) @street = @invoice.customer.address.street Their proposed solution is to do the following: class Customer has_one :address belongs_to :invoice def street address.street end end class Invoice has_one :customer def customer_street customer.street end end @street = @invoice.customer_street They are stating that since you only use one dot, you are not breaking the Law of Demeter here. I think this is incorrect, because you are still going through customer to go through address to get the invoice's street. I primarily got this idea from a blog post I read: http://www.dan-manges.com/blog/37 In the blog post the prime example is class Wallet attr_accessor :cash end class Customer has_one :wallet # attribute delegation def cash @wallet.cash end end class Paperboy def collect_money(customer, due_amount) if customer.cash < due_ammount raise InsufficientFundsError else customer.cash -= due_amount @collected_amount += due_amount end end end The blog post states that although there is only one dot customer.cash instead of customer.wallet.cash, this code still violates the Law of Demeter. Now in the Paperboy collect_money method, we don't have two dots, we just have one in "customer.cash". Has this delegation solved our problem? Not at all. If we look at the behavior, a paperboy is still reaching directly into a customer's wallet to get cash out. EDIT I completely understand and agree that this is still a violation and I need to create a method in Wallet called withdraw that handles the payment for me and that I should call that method inside the Customer class. What I don't get is that according to this process, my first example still violates the Law of Demeter because Invoice is still reaching directly into Customer to get the street. Can somebody help me clear the confusion. I have been searching for the past 2 days trying to let this topic sink in, but it is still confusing.

  Read the article

• Fitting an established site into a CI framework

  - by David

  I manage a rather large, feature full nightmare of a site which has no end of feature creep settings/options/etc. Up to now its been coded in a procedural/functional way and would like to move to an OO,MVC setup. I'm quite new to it all but have done alot of research and feel that CodeIgniter is a code choice of framework to use to help quicken the transfer. Before looking at a framework, I started constructing a list of objects to create classes out of: photos users forum topics forums blogs blog posts comments The trouble I have now, is I do understand where these generic/universal objects fall into the CI MVC setup. What is the best way to organise this kind of stuff? These classes can generally be used on multiple models/views/controllers.

  Read the article

• Why setter method when getter method enough in PHP OOP

  - by phphunger

  I am practicing OOP with PHP, and I am struck at setter and getter methods. I can directly access the class properties and methods with getter method then what's the use of setter method? See my example. <?php class MyClass{ public $classVar = "Its a class variable"; public function Getter(){ return $this -> classVar; } } $obj = new MyClass; echo $obj -> Getter(); ?>

  Read the article

• Fetching database query through function

  - by Shubham Maurya

  I am sick of connecting database in each script i need a more OOP approach to fetching database results. ex like wordpress use wpdb class to fetch results. This what wordpress does to get data <?php $posts = $wpdb->get_results("SELECT ID, post_title FROM $wpdb->posts WHERE post_status = 'publish' AND post_type='post' ORDER BY comment_count DESC LIMIT 0,4") ?> How can i create the same feature too using any class or function and use it in my script Thank you

  Read the article

• To identify the classes for uml diagrams?

  - by user106535

  I want to implement a software engineering project based on "crime management system". The main modules are: visitors, users, administrator. The main events that are taking place are: registration, report complaint, report crime, report most wanted, view status of reported crime. So could you please help me to identify the classes that are to be used in this project and help me to draw the class diagram?

  Read the article

• Breaking up classes and methods into smaller units

  - by micahhoover

  During code reviews a couple devs have recommended I break up my methods into smaller methods. Their justification was (1) increased readability and (2) the back trace that comes back from production showing the method name is more specific to the line of code that failed. There may have also been some colorful words about functional programming. Additionally I think I may have failed an interview a while back because I didn't give an acceptable answer about when to break things up. My inclination is that when I see a bunch of methods in a class or across a bunch of files, it isn't clear to me how they flow together, and how many times each one gets called. I don't really have a good feel for the linearity of it as quickly just by eye-balling it. The other thing is a lot of people seem to place a premium of organization over content (e.g. 'Look at how organized my sock drawer is!' Me: 'Overall, I think I can get to my socks faster if you count the time it took to organize them'). Our business requirements are not very stable. I'm afraid that if the classes/methods are very granular it will take longer to refactor to requirement changes. I'm not sure how much of a factor this should be. Anyway, computer science is part art / part science, but I'm not sure how much this applies to this issue.

  Read the article

• Questioning one of the arguments for dependency injection: Why is creating an object graph hard?

  - by oberlies

  Dependency injection frameworks like Google Guice give the following motivation for their usage (source): To construct an object, you first build its dependencies. But to build each dependency, you need its dependencies, and so on. So when you build an object, you really need to build an object graph. Building object graphs by hand is labour intensive (...) and makes testing difficult. But I don't buy this argument: Even without dependency injection, I can write classes which are both easy to instantiate and convenient to test. E.g. the example from the Guice motivation page could be rewritten in the following way: class BillingService { private final CreditCardProcessor processor; private final TransactionLog transactionLog; // constructor for tests, taking all collaborators as parameters BillingService(CreditCardProcessor processor, TransactionLog transactionLog) { this.processor = processor; this.transactionLog = transactionLog; } // constructor for production, calling the (productive) constructors of the collaborators public BillingService() { this(new PaypalCreditCardProcessor(), new DatabaseTransactionLog()); } public Receipt chargeOrder(PizzaOrder order, CreditCard creditCard) { ... } } So there may be other arguments for dependency injection (which are out of scope for this question!), but easy creation of testable object graphs is not one of them, is it?

  Read the article

• How to deal with data on the model specific to the technology being used?

  - by user1620696

  There are some cases where some of the data on a class of the domain model of an application seems to be dependent on the technology being used. One example of this is the following: suppose we are building one application in .NET such that there's the need of an Employee class. Suppose further that we are going to implement relational database, then the Employee has a primary key right? So that the classe would be something like public class Employee { public int EmployeeID { get; set; } public string Name { get; set; } ... } Now, that EmployeeID is dependent on the technology right? That's something that has to do with the way we've choose to persist our data. Should we write down a class independent of such things? If we do it this way, how should we work? I think I would need to map all the time between domain model and persistence specific types, but I'm not sure.

  Read the article

• Is OOP hard because it is not natural?

  - by zvrba

  One can often hear that OOP naturally corresponds to the way people think about the world. But I would strongly disagree with this statement: We (or at least I) conceptualize the world in terms of relationships between things we encounter, but the focus of OOP is designing individual classes and their hierarchies. Note that, in everyday life, relationships and actions exist mostly between objects that would have been instances of unrelated classes in OOP. Examples of such relationships are: "my screen is on top of the table"; "I (a human being) am sitting on a chair"; "a car is on the road"; "I am typing on the keyboard"; "the coffee machine boils water", "the text is shown in the terminal window." We think in terms of bivalent (sometimes trivalent, as, for example in, "I gave you flowers") verbs where the verb is the action (relation) that operates on two objects to produce some result/action. The focus is on action, and the two (or three) [grammatical] objects have equal importance. Contrast that with OOP where you first have to find one object (noun) and tell it to perform some action on another object. The way of thinking is shifted from actions/verbs operating on nouns to nouns operating on nouns -- it is as if everything is being said in passive or reflexive voice, e.g., "the text is being shown by the terminal window". Or maybe "the text draws itself on the terminal window". Not only is the focus shifted to nouns, but one of the nouns (let's call it grammatical subject) is given higher "importance" than the other (grammatical object). Thus one must decide whether one will say terminalWindow.show(someText) or someText.show(terminalWindow). But why burden people with such trivial decisions with no operational consequences when one really means show(terminalWindow, someText)? [Consequences are operationally insignificant -- in both cases the text is shown on the terminal window -- but can be very serious in the design of class hierarchies and a "wrong" choice can lead to convoluted and hard to maintain code.] I would therefore argue that the mainstream way of doing OOP (class-based, single-dispatch) is hard because it IS UNNATURAL and does not correspond to how humans think about the world. Generic methods from CLOS are closer to my way of thinking, but, alas, this is not widespread approach. Given these problems, how/why did it happen that the currently mainstream way of doing OOP became so popular? And what, if anything, can be done to dethrone it?

  Read the article

• Models, collections...and then what? Processes?

  - by Dan

  I'm a LAMP-stack dev who's been more on the JavaScript side the last few years and really enjoying the Model + Collection approach to data entities that BackboneJS, etc. uses. It's helped me organize my code in such a way that it is extremely portable, keeping all my properties and methods in the scope (model, collection, etc.) in which they apply. One thing that keeps bugging me though is how to organize the next level up, the 'process layer' as you might call it, that can potentially operate on instances of either models or collections or whatever else. Where should methods like find() (which returns a collection) and create() (which returns a model) reside? I know some people would put a create() in the Collection prototype, but while a collection operates on models I don't think it's exactly right to create them. And while a find() would return a collection I don't think it correct to have that action within the collection prototype itself (it should be a layer up). Can anyone offer some examples of any patterns that employ some kind of OOP-friendly 'process' layer? I'm sorry if this is a fairly well-known discussion but I'm afraid I can't seem to find the terminology to search for.

  Read the article

• Looking for a better Factory pattern (Java)

  - by Sam Goldberg

  After doing a rough sketch of a high level object model, I am doing iterative TDD, and letting the other objects emerge as a refactoring of the code (as it increases in complexity). (That whole approach may be a discussion/argument for another day.) In any case, I am at the point where I am looking to refactor code blocks currently in an if-else blocks into separate objects. This is because there is another another value combination which creates new set of logical sub-branches. To be more specific, this is a trading system feature, where buy orders have different behavior than sell orders. Responses to the orders have a numeric indicator field which describes some event that occurred (e.g. fill, cancel). The combination of this numeric indicator field plus whether it is a buy or sell, require different processing buy the code. Creating a family of objects to separate the code for the unique handling each of the combinations of the 2 fields seems like a good choice at this point. The way I would normally do this, is to create some Factory object which when called with the 2 relevant parameters (indicator, buysell), would return the correct subclass of the object. Some times I do this pattern with a map, which allows to look up a live instance (or constructor to use via reflection), and sometimes I just hard code the cases in the Factory class. So - for some reason this feels like not good design (e.g. one object which knows all the subclasses of an interface or parent object), and a bit clumsy. Is there a better pattern for solving this kind of problem? And if this factory method approach makes sense, can anyone suggest a nicer design?

  Read the article

• Does FP mess up your OOP skills?

  - by bonomo

  I've been learning functional programming in Haskell and F# for awhile and now when I got some skills it gets harder for me to think in OOP way and program in C# and JavaScript. Everything seems to be ass-backwards there with classes, interfaces, objects and I often stare at the screen trying to think of a better way around without using them. This is something that scares me, because I didn't have problems like that before (not knowing that the same stuff can be done in a different way). So I am concerned as I don't want to loose myself as a OOP developer, because this is what I do for living. Is it a normal thing? Shall I rather stop doing FP? How did you manage to cope with it?

  Read the article

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