Search Results

Search found 10 results on 1 pages for 'kazark'.

Page 1/1 | 1 

• Does software rot refer primarily to performance, or to messy code?

  - by Kazark

  Wikipedia's definition of software rot focuses on the performance of the software. This is a different usage than I am used to; I had thought of it much more in terms of the cleanliness and design of the code—in terms of the code's having all the standard quality characteristics: readability, maintainability, etc. Now, performance is likely to go down when the code becomes unreadable, because no one knows what is going on. But does the term software rot have special reference to performance? or am I right in thinking it refers to the cleanliness of the code? or is this perhaps a case of multiple senses of the term being in common usage—from the user's perspective, it has do with performance; but for the software craftsman, it has to do more specifically with how the code reads?

  Read the article

• Design patterns to avoiding breaking the SRP while performing heavy data logging

  - by Kazark

  A class that performs both computations and data logging seems to have at least two responsibilities. Given a system for which the specifications require heavy data logging, what kind of design patterns or architectural patterns can be used to avoid bloating all the classes with logging calls every time they compute something? The decorator pattern be used (e.g. Interpolator decorated to LoggingInterpolator), but it seems that would result in a situation hardly more desirable in which almost every major class would need to be decorated with logging.

  Read the article

• Precising definition of programming paradigm

  - by Kazark

  Wikipedia defines programming paradigm thus: a fundamental style of computer programming which is echoed in the descriptive text of the paradigms tag on this site. I find this a disappointing definition. Anyone who knows the words programming and paradigm could do about that well without knowing anything else about it. There are many styles of computer programming at many level of abstraction; within any given programming paradigm, multiple styles are possible. For example, Bob Martin says in Clean Code (13), Consider this book a description of the Object Mentor School of Clean Code. The techniques and teachings within are the way that we practice our art. We are willing to claim that if you follow these teachings, you will enjoy the benefits that we have enjoyed, and you will learn to write code that is clean and professional. But don't make the mistake of thinking that we are somehow "right" in any absolute sense. Thus Bob Martin is not claiming to have the correct style of Object-Oriented programming, even though he, if anyone, might have some claim to doing so. But even within his school of programming, we might have different styles of formatting the code (K&R, etc). There are many styles of programming at many levels. Sp how can we define programming paradigm rigorously, to distinguish it from other categories of programming styles? Fundamental is somewhat helpful, but not specific. How can we define the phrase in a way that will communicate more than the separate meanings of each of the two words—in other words, how can we define it in a way that will provide additional meaning for someone who speaks English but isn't familiar with a variety of paradigms?

  Read the article

• What is the precise definition of programming paradigm?

  - by Kazark

  Wikipedia defines programming paradigm thus: a fundamental style of computer programming which is echoed in the descriptive text of the paradigms tag on this site. I find this a disappointing definition. Anyone who knows the words programming and paradigm could do about that well without knowing anything else about it. There are many styles of computer programming at many level of abstraction; within any given programming paradigm, multiple styles are possible. For example, Bob Martin says in Clean Code (13), Consider this book a description of the Object Mentor School of Clean Code. The techniques and teachings within are the way that we practice our art. We are willing to claim that if you follow these teachings, you will enjoy the benefits that we have enjoyed, and you will learn to write code that is clean and professional. But don't make the mistake of thinking that we are somehow "right" in any absolute sense. Thus Bob Martin is not claiming to have the correct style of Object-Oriented programming, even though he, if anyone, might have some claim to doing so. But even within his school of programming, we might have different styles of formatting the code (K&R, etc). There are many styles of programming at many levels. So how can we define programming paradigm rigorously, to distinguish it from other categories of programming styles? Fundamental is somewhat helpful, but not specific. How can we define the phrase in a way that will communicate more than the separate meanings of each of the two words—in other words, how can we define it in a way that will provide additional meaning for someone who speaks English but isn't familiar with a variety of paradigms?

  Read the article

• Name for Osherove's modified singleton pattern?

  - by Kazark

  I'm pretty well sold on the "singletons are evil" line of thought. Nevertheless, there are limited occurrences when you want to limit the creation of an object. Roy Osherove advises, If you're planning to use a singleton in your design, separate the logic of the singleton class and the logic that makes it a singleton (the part that initializes a static variables, for example) into two separate classes. That way, you can keep the single responsibility principle (SRP) and also have a way to override singleton logic. (The Art of Unit Testing 261-262) This pattern still perpetuates the global state. However, it does result in a testable design, so it seems to me to be a good pattern for mitigating the damage of a singleton. However, Osherove does not give a name to this pattern; but naming a pattern, according to the Gang of Four, is important: Naming a pattern immediately increases our design vocabulary. It lets us design at a higher level of abstraction. (3) Is there a standard name for this pattern? It seems different enough from a standard singleton to deserve a separate name. Decoupled Singleton, perhaps?

  Read the article

• Should concrete classes avoid calling other concrete classes, except for data objects?

  - by Kazark

  In Appendix A to The Art of Unit Testing, Roy Osherove, speaking about ways to write testable code from the start, says, An abstract class shouldn't call concrete classes, and concerete classes shouldn't call concrete classes either, unless they're data objects (objects holding data, with no behavior). (259) The first half of the sentence is simply Dependency Inversion from SOLID. The second half seems rather extreme to me. That means that every time I'm going to write a class that isn't a simple data structure, which is most classes, I should write an interface or abstract class first, right? Is it really worthwhile to go that far in defining abstract classes an interfaces? Can anyone explain why in more detail, or refute it in spite of its benefit for testability?

  Read the article

• Use a custom value object or a Guid as an entity identifier in a distributed system?

  - by Kazark

  tl;dr I've been told that in domain-driven design, an identifier for an entity could be a custom value object, i.e. something other than Guid, string, int, etc. Can this really be advisable in a distributed system? Long version I will invent an situation analogous to the one I am currently facing. Say I have a distributed system in which a central concept is an egg. The system allows you to order eggs and see spending reports and inventory-centric data such as quantity on hand, usage, valuation and what have you. There area variety of services backing these behaviors. And say there is also another app which allows you to compose recipes that link to a particular egg type. Now egg type is broken down by the species—ostrich, goose, duck, chicken, quail. This is fine and dandy because it means that users don't end up with ostrich eggs when they wanted quail eggs and whatnot. However, we've been getting complaints because jumbo chicken eggs are not even close to equivalent to small ones. The price is different, and they really aren't substitutable in recipes. And here we thought we were doing users a favor by not overwhelming them with too many options. Currently each of the services (say, OrderSubmitter, EggTypeDefiner, SpendingReportsGenerator, InventoryTracker, RecipeCreator, RecipeTracker, or whatever) are identifying egg types with an industry-standard integer representation the species (let's call it speciesCode). We realize we've goofed up because this change could effect every service. There are two basic proposed solutions: Use a predefined identifier type like Guid as the eggTypeID throughout all the services, but make EggTypeDefiner the only service that knows that this maps to a speciesCode and eggSizeCode (and potentially to an isOrganic flag in the future, or whatever). Use an EggTypeID value object which is a combination of speciesCode and eggSizeCode in every service. I've proposed the first solution because I'm hoping it better encapsulates the definition of what an egg type is in the EggTypeDefiner and will be more resilient to changes, say if some people now want to differentiate eggs by whether or not they are "organic". The second solution is being suggested by some people who understand DDD better than I do in the hopes that less enrichment and lookup will be necessary that way, with the justification that in DDD using a value object as an ID is fine. Also, they are saying that EggTypeDefiner is not a domain and EggType is not an entity and as such should not have a Guid for an ID. However, I'm not sure the second solution is viable. This "value object" is going to have to be serialized into JSON and URLs for GET requests and used with a variety of technologies (C#, JavaScript...) which breaks encapsulation and thus removes any behavior of the identifier value object (is either of the fields optional? etc.) Is this a case where we want to avoid something that would normally be fine in DDD because we are trying to do DDD in a distributed fashion? Summary Can it be a good idea to use a custom value object as an identifier in a distributed system (solution #2)?

  Read the article

• Tension between the dependency inversion principle and avoiding "new" in C++?

  - by Kazark

  I have seen a lot of advice that it is better to do Type object; than Type* object = new Type(); in C++ whenever possible. I understand the rational behind this and appreciate it. But according to my understanding, to practice dependency inversion requires pointers, e.g.: Type* object = new Implementation();. (Or am I wrong about that?) Is there an inherent tension between the DIP and avoiding new when using C++? If so, what patterns/principles/practices can be used to mitigate this tension?

  Read the article

• Wallpapers of only some users being dynamically loaded in LightDM

  - by Kazark

  As this answer explains: Ubuntu 12.04 Unity greeter has introduced selected user dynamic background, that means that when selecting a user from the available users list the background will change to reflect the selected user's desktop background. However, I am puzzled, because in my experience this isn't consistently true. On one of my family members' computers, where there are three users, only one of the users' background shows in LightDM. None of the users are newly created. The user whose background is showing has a custom background; one of the users whose background doesn't show also does; and the other one who doesn't has the default switching wallpaper set. It is not a clean install but has been incrementally upgraded from about 8.04. Any idea what could be happening? This is a similar question, though we're also having the opposite problem (default wallpapers not showing). (I do not have access to the computer mentioend above at the moment; when I do I will use some of the criteria given there to analyze the problem further.)

  Read the article

• Vim is spellchecking in XML files where I don't want it to, and only there

  - by Kazark

  I'm trying to use Vim's builtin spellchecking in some XML documents. This happens merely by having the XML syntax loaded, as seen in the following minimalistic example (which reproduces what I also see in large XML documents): Note that given two buffers with exactly the same content, when Filetype is text, the spellchecking works; when it is xml, it does not. spell is set in both buffers. However, given this view of the top three lines of a large XML document, you can see that the spellchecking is certainly on: but it is only checking attributes. The nuisance is that none of the things it is actually finding are mispelled, and it isn't finding any of the numerous misspellings in the document. I would like it at a minimum to find the spelling errors in the body of the document, and being able to turn off the checking on attributes would be a nice option. I've searched for @NoSpell in the xml.vim file, but that returns no hits.

  Read the article

1