New answers tagged

2

What are some reasons you may choose a worse runtime algorithm? By far the most common reason is that the "worse" algorithm is a lot simpler, or is the first solution I think of, and getting mathematically optimal performance just doesn't matter in the part of the code I'm currently working on. Which is most parts of the code. Another common reason is ...


0

a) The design is correct and consistent with and traceable to requirements. Traceability is achieved by formally documenting the relationships between the various individual system requirements and the individual design elements. Both upstream and downstream relationships need to be captured and documented for bi-directional traceability. c) ...


1

Decoupling-wise, what you might want is to create an adapter/abstraction layer only present in the core app package and make your core app depend on this newly created layer. Moving the management of Kafka to a different project is not a bad idea, however, even then the core app should not directly depend on this newly created web application, but provide ...


0

I would suggest this difference is simply an anachronism from the age of HTML and LaTeX. HTML, having evolved out of SGML (as did Docbook), actually got a lot of it's structural elements (i.e. <h1>, etc) from IBM's GML/GMLguide languages. In GML, as with LaTeX, the focus of the language designers was on the presentation of content, rather than the ...


0

I think you need to use the State monad from scalaz -> http://eed3si9n.com/learning-scalaz/State.html The data type would be State[Stage, Data] where Stage consists of your stages and data the value that accompanies the current stage. case class Stage(id: String, someStateInfo: String) case class Data(someData: String, anotherData: String) Create a ...


1

The single best thing you can do is introduce some standards. Everything you say is caused by a mess of "do whatever" appearing in the codebase. Keeping this concept of "add some more cool tech (eg EF migrations...)" will only add to the problem. You need to reduce the scope of maintenance, not increase it. The best way to do that is to start to reduce the ...


0

So, I think what the OP has done is create 2 Aggregate Roots called ActiveCustomer and InactiveCustomer, and in those has added a property of type Customer. This is an entity, which represents a Customer in his system. This is where I think the confusion/issue has arisen. Effectively this has made the aggregate root a wrapper around the entity, but it ...


0

You've included the "tdd" tag in your question, which suggests at least a passing interest in agile approaches. The agile approach to this question is highlighted by an aphorism attributed to Ward Cunningham: "Do the simplest thing that could possibly work." Generally, this means to pick the smallest subset of your plans for the new project that would be ...


0

To my experience it is better to implement one function and get it to work properly, then add the next function and so on. This implies perhaps for the first function that you have to hard code some example things that will later be delivered by other not-yet-implemented functions. The benefit of this is that you only write code that you actually need. If ...


1

You're going to need an overflow area, perhaps a stack, or some chunk of memory. You'll also want to get the generated code correct before optimizing it, because optimizing broken code is basically impossible. So , given a stack, you should have something like: PUT b,2; Push b; Put b,7; Put c,3; ADD; Pop b; MUL and if using memory, PUT b,2; Store b @1; ...


1

Do not generate code, generate values instead. Why you need encapsulation I would suggest that you avoid code generation from one language to another for two reasons: It makes the code difficult to read; small snippets of JavaScript in among lines of PHP cannot be picked up by IDEs and is difficult to follow even for programmers well versed in both ...


2

Is your work a derivative work of the project licensed under the AGPL? Can it stand on its own as its own work? As you've described it so far, the answer to this is 'no'. You are changing the design. Your modifications would be a derivative work of the original project and thus would need to be licensed under the AGPL to anyone you distribute the ...


3

As you are creating an app that faces the general public, it doesn't really matter how the contracts are stored internally and what access controls are used by those different systems. If the company offers a portal to its customers to see their contracts and associated data, then as a customer, I expect to have a single login to the "My Company X" app and ...


6

Single-sign on makes it very convenient for your users to log-on to all your system, and it also provides improved security. Imagine that it will be extremely cumbersome for users if they have to log-on to ten different databases with different accounts and different passwords each day over-and over again. That leads them to ignore any recommendation about ...


0

A unit test should be able to use any code or logic that itself is properly tested. A unit test should have minimal logic in it. It should be straight forward as to its test and that one can look at it and reason about it. Reimplementing an equals method violates DRY. In doing so, it introduces the possibility of having equals diverge and a bug slip in to ...


3

Generally, it is often a good idea to separate the responsibilities of testing something like externally provided settings, and the "core businesss code" like GiveApples. On the other hand, having functions which group together what belongs together is also a good idea. You can accomplish both goals by refactoring your code like this: private void ...


4

Place the guard within the method itself. The consumer of GiveApples() or GiveBananas() shouldn't be responsible for managing the guards of GiveApples(). From a design standpoint SomeMethod() should only knows that it needs fruit and shouldn't care about what your application needs to do in order to get it. The abstraction of fruit retrieval becomes ...


2

To my experience, it is good to be prepared that names in your code need to be changed afterwards, for lots of possible reasons, feature rebranding is just one of many reasons why this may occur. Therefore it is always a good idea to take some measures beforehand to make renamings in your code as simple as possible. Refactoring tools will help. Statically ...


11

I think of guards as something the method must obey. In your example, the method must not give apples if Settings.GiveApples is false. If that is the case then the guard definitely belongs inside the method. This prevents you from accidentally calling it from another point in your application without checking the guards first. On the other hand if the ...


1

A few pitfalls you need to be aware of: Authentication. Unless you want anyone in the world to operate your machine, you need to make sure only authorized people connect to your hardware controller. A good way to do this might be to use TLS with client- and server certificate. As a bonus this also gives you encryption to protect from eavesdroppers and ...


3

Yes, this separation of layers is always a good thing, even if its not going to be written for a distributed system. Many systems work by making UI or DB components as isolated as possible to allow for easier maintenance or replacement in the future. Other system write the main program as a command line app and then write a GUI to drive that. That allows it ...


1

Your question might be too broad and is quite abstract (not enough implementation details are given: which operating system? which hardware: an Arduino like embedded processor is not the same as an ARM motherboard running some real-time variant of Linux; what machinery ? : a sewing machine is not the same as a nuclear power plant). Also, what kind of users? ...


3

Now, the business constraint I want to enforce via the type-system is this: it should not be possible to instantiate an unauthenticated NightwatchCommand. Now, maybe I'm missing some piece of context here, but this has me very puzzled for the following reason: why would a "business constraint" care about what NightWatchCommands get instantiated or not? ...


0

How about something like this (testing this code is an exercise for the reader): {-# LANGUAGE Rank2Types, GeneralizedNewtypeDeriving #-} class Authorized a where fromIncomingMsg :: String -> IO (AuthNightwatchCommand) instance Authroized AuthNightwatchCommand where fromIncomeMsg = error "Todo" newtype Auth = Auth {unAuth :: forall a. ...


1

for a repeating timer. Use setitimer() here is info from the man page NAME getitimer, setitimer - get or set value of an interval timer SYNOPSIS #include <sys/time.h> int getitimer(int which, struct itimerval *curr_value); int setitimer(int which, const struct itimerval *new_value, ...


3

It is not generally sensible to limit the number of threads, if these threads are used only for concurrency. I.e. aside from the extra resource use, spawning threads is fine to manage blocking operations, increase responsiveness, …. A good example is a web crawler that might want to download multiple small resources, and uses multiple threads to compensate ...


1

I do have some further insight that I can provide. First, about your classes, since the name of an institution should probably remian the same and not change, upon instantiation is the only time that you should allow external implementation to modify that string for the Name -- make it immutable from the class perspective. This would be proper encapsulation; ...


4

There's numerous ways to acheive this, all depending on what kind of environment you're working with. Another concern is of course the latency you can afford. If you are working on a modern operating system, you most likely have an API that will put your thread to sleep until the given time has arrived. Posix has nanosleep() and C11 has the thread_sleep() ...


0

I think that, exactly like you've pointed out, the big considerations would be What would happen if the implementation on the client or server side changes. How would future developers extend the API if it was written that way How would this design impact modularity/reuseability of the API What you're proposing would tightly couple part of the API to ...


3

There are many reasons a customer may be reticent to push on to the latest software version. Some reasons I've come across: Known quantity The customer may simply be very happy with a legacy version. They know all the foibles, how to fix things should they go wrong and how to get the very best out of the software. Time The customer may not have time to ...


1

One thing I would like to point out is that all your Add methods are not necessary. If you expose the List<T> like you do, you can use them for adding. And you can use the collection initializer syntax for that: var institutions = new List<Institution> { new Institution("My college") { Terms = { new ...


2

Why would you use Windows 7, while Microsoft released newer versions meanwhile? Similarly, one can decide to keep an older version of Linux, or an older version of Python. Some factors one should take in account : The price of the new version. The operations cost of upgrading. The time needed to learn the new version. Backwards compatibility: if you have ...


4

There can be several reasons to stay with an older release: New releases may cost money for a new license. If the older release is sufficient, why spend the money? New releases may cost money and/or time (a.k.a. money) to learn and/or install. Again, why bother if the older release works? New releases may break things. This may be intentional (removing ...


8

Older versions can bring stability to a software deployment. New versions of software may introduce new bugs, potentially crippling bugs. For anything mission-critical, only battle-tested software should be deployed in order to reduce risk. If you want the latest and greatest then put it on a desktop or other non-critical system. This is the thought ...


1

You're right not to use inheritance, and in fact I think your design is fine. Let's take a look at one of your uses of your code. MessageBox.Show(Institutions[0].Terms[0].Courses[0].Assignments[0].Name); While the [0] uses here are standard for testing, in most uses of a class-based design, you would not be accessing the lists directly by some index, eg ...


2

It's not bad for a newbie. You're right to be concerned about accessing objects through multilevel lists. Also, hard coding the indexes will hurt you eventually (but it's OK for now). You might try changing AddNewxxx() to return what was added. For example, if you change Term's AddNewClass to public Course AddNewCourse(string NewCourseName) { ...


1

One possibility, not yet mentioned, is that you don't stick an incomplete record in the database at all - you just hold it as a blob (serialized by some means) somewhere (could be in the database, could be elsewhere). It rather depends on what, if anything, is done with incomplete records (this is about workflow and related). Specifically if 90% of the code ...


0

The requirement is self-contradictory: the required fields must all be optional. But okay, let's laugh at the person who wrote the spec and then move on. I think creating two tables is a very bad idea. This would mean that all the field definitions must be duplicated. It's likely that many queries would have to be duplicated -- your basic insert at a ...


3

You could have a separate table for works in progress. You would use more or less the same table scheme, just with each field set as nullable. When a record is initially created, it goes into the incomplete records table (you could have a check to put first time completed records directly into your completed records table, of course). Once a record has ...


3

What you have here is a typical use-case of runtime multiple-dispatch, and depending on the actual object-oriented language you intend to use, this is either built-in or requires some work. I am sorry this answer cannot be more precise, but this depends largely on the actual programming language. Assuming a Java-esque language, you could quickly devise a ...


1

Language designers generally try to avoid adding new keywords, especially for language features added after the language has already gained some popularity. Every keyword they add is an identifier that programs aren't allowed to use for other purposes, so adding a keyword could potentially break existing programs. Language designers have to weigh the ...


2

Quis custodiet ipsos custodes? Your test framework had bugs in it, which means that your tests were buggy. This is the problem with complex tests and complex testing systems. One way to deal with this is to create unit tests for the complex parts, and then confirm that they behave correctly. In other words, it's just software, and if it isn't dead ...


2

It is about getting your dependencies straight. If you need some new functionality, you always have a choice to either keep it private to your problem domain code or put it in a package with general support stuff that is accessible to all. If you keep it private, it is yours. You can change, fix, extend it whenever you like and you can be sure you will not ...


1

You will need to run all tests eventually as you're making a fundamental change. However you don't have to run all tests at once. Rather then fixing the bug, you could deprecate the bug causing functionality, create a new and correct bit of functionality which over time replaces the old functionality.


0

Validation is part of your business logic, your domain, it ensures the state of your domain never becomes invalid, so when you persist it, the data that is saved is always valid. Good domain model highlights encapsulation and is such, which never becomes invalid, it has checks on operations which may break its valid state (be it raising exceptions or simply ...


4

When you change the behaviour of a component in your framework, then just unit-testing that component is not sufficient. You must also re-run the integration- and higher-level tests that involve that component to verify what effect your changes have on the rest of the system. If you find that the effect of your change is very large, the either you should ...


1

The most useful way I've found to understand the Single Responsibility Principle is to interpret "responsibility" as "reason why the code might change". This is because the primary goal of SRP is to group together code that will change together, and (as far as possible) keep code that will change for different reasons separated from it. By doing this, we ...


0

Validation rules are business logic. Even a simple "NULL" check is a business rule -- someone decided it was OK for "Middle Name" to be missed but "County" must always be filled in. Most validation rules are not that simple and may even require access to external services e.g. "is the guy on the credit agencies s**t list". So forget about Validation as a ...


0

First of all, if you have a Account aggregate, and a Customer aggregate, and the business rule for modifying an account by adding a Customer requires looking at the customer state and at the account state, then either your business rules or your model are wrong. The aggregate boundary is to include all of the state needed to enforce the business invariant. ...


2

Some valuable comments provided already (@Florian, Basile), but let me add ... OP says, We will provide front-end interface to manage the devices. However some advanced administrators may want to configure the application on their own But also remarks: I did not want this question to be platform or language specific You must consider your target ...



Top 50 recent answers are included