In my current application, which is quite simple, I have a class responsible for keeping track of all the customers. It adds new customers, updates details, assigns managers etc. All in all, it performs some logic and keeps track of what is there.
Now, I need to display this database in a complicated way, with certain string formatting, column widths etc. Should this behaviour be part of an external class that would take a list of cusomers, or should it rather stay within the Database itself, as it is the "closest" to the customer objects? What are pros/cons of both approaches? What makes more sense semantically?
Thx in advance.
I would use an external class because the code will be reusable for other applications. If you tie the formatting to the database, then you'll end up with very specific code that will cost you time further on down the road.
That being said, the elegant solution is not always the fastest. If there's a looming deadline, and you find it easier and faster to hard code your formatting info, then it may be more prudent to brute force your way through it so you don't end up with an angry client, an unfinished project and an unpaid invoice.
Related
Let say a company has an internal program called Service Checklist.
Because the program named Service Checklist, the programmer creates a name on variables, pages, database tables, stored procedures and anything else based on the program name.
For example :
Variable named ListServiceChecklist or ListSC
A page namedCreateServiceChecklist or CreateSC
Stored Procedure named GetServiceChecklist or GetSC
Table named ServiceChecklist
This program has been used for years, and new small improvements added every year.
Then someday the manager decided to rename the program from Service Checklist to E-Checklist, and he needs it to be done fast. So if a text that is shown to the user contain words Service Checklist, it must be changed to E-Checklist
For example :
Text Menu List Service Checklist must be changed to List E-Checklist
Alert message Success create Service Checklist changed to Success create E-Checklist
So the programmer started to change all the text from Service Checklist to E-Checklist on the front end side. But what about all the variables, pages name, database tables, stored procedures, etc?
If the programmer leaves it, other programmers will be confused as the name doesn't make any sense anymore.
If the programmer renames all the variables, etc, it will take a lot of time and a huge pain in the ass.
As a programmer what's the best way to solve this problem?
Like most things in programming, it depends. There isn't a one rule fits all.
Ideally everything gets changed to help code readability but in many cases the amount of time this would take doesn't justify the benefits.
You have to take into consideration the amount of time it will take to do these updates and measure it against how much time it will save you in the future.
It also depends on the size of the project, how many times the code gets updates, how much time the team has to work on this type of things and probably a few others I can't think of right now.
I am new to SuiteScript and want to make our code more efficient. Looking at our code it seems there are many script of the same type for the same record type. For example, 3 clientscripts on a sales order. Is it bad practice to roll all of these scripts into the same script?
I also want to centralise the code. The last 3 years I've written in C# and any reusable code was placed in a relevant class. I want to rewrite the code we have in the same manner. For example, any method that is to do with a sales order is placed in a module called SalesOrderServices. This module can then be added to any of the scripts and the methods are all available if needed. My concern is this would make things less efficient due to loading all the modules in the Services module, even if they are not really needed. So as a second part to this question, is this a good idea or will it make our code be less efficient?
There is quite a lot to consider in a question like this, and there won't be one correct answer, but I'll chime in with my perspective.
It is not necessarily bad practice to combine the similar scripts into one, but it also is not bad practice to keep them separate. That's really a decision that only you and your team can decide on what is most efficient for you to maintain.
I do think you are right to want to break out any reusable functionality into separate modules, but I would be careful putting "everything related to a Sales Order" into one module. My personal preference is to design and group code based on features and business processes rather than around record types. If you try to modularize based on record type, what happens when you have an approval process that touches both Purchase Orders and Vendor Bills? Where will that live? I prefer small, focused modules rather than large monolithic ones, but that is just my preference. That doesn't work best for everyone and every team.
Have you proven that loading additional modules or Script records is a performance bottleneck for your system? I would be very surprised if that were the case, and so I would caution against premature optimization of these sorts of things. There are many facets of NetSuite that operate on the order of seconds and are out of your control, so saving a few micro- or milliseconds here and there isn't going to do anything appreciable for your users.
I'm using CQRS on an air booking application. one use case is help customer cancel their tickets. But before the acutal cancellation, the customer wants to know the penalty.
The penalty is calculated based on air rules. Some of our provider could calculate the penalty through exposing an web service while the others don't. (They publish some paper explaining the algorithm instead). So I define a domain service
public interface AirTicketService {
//ticket demand method
MonetaryAmount penalty(String ticketNumber);
void cancel(String ticketNumber, MonetaryAmount penalty);
}
My question is which side(command/query) is responsible for invoking this domain service and returning result in a CQRS style application?
I want to use a Command: CalculatePenlatyCommand, In this way, it's easy to resuse the domain model, but it's a little odd because this command does not modify state.
Or should I retrieve a readmodel of ticket if this is a query? But the same DomainService is needed on both command and query side, it's odd too.
Is domain derivation a query?
There is no need to shoehorn everything in to the command-query pipeline. You could query this service independently from the UI without issuing a command or asking the read-model.
There is nothing wrong with satisfying a query using an existing model if it "fits" both the terminology and the structure of that model. No need to build up a separate read model for that purpose. It's not without risk, since the semantics and the context of the query should be closely tied to the model that is otherwise used for write purposes only. The risk I allude to is the fact that the write and read concerns could drift apart (and we're back at square one, i.e. the reason why people pick CQRS in the first place). So you must keep paying attention as new requirements come in.
Queries that fit this model really well are what I call "simulators', where you want to run a simulation using current state to e.g. to give feedback to an end user. On more than one occasion I've found that the simulation logic could be reused both as a feedback mechanism and as an execution (of a write operation/command) steering mechanism. The difference is in what we do with the outcome of the simulation. Again, this is not without risk and requires careful judgement.
You may bring arguments that Calculate Penalty Command is not odd at all.
The user asks the system to do something - command enough.
You can even have a Penalty Calculation Requested Event event in your domain, and it would feel right. Because, at some time, you may be interested in, let's say, unsure clients, ones that want to cancel tickets but they change their mind every time etc. The calculation may be performed asynchronously, too - you can provide the result (penalty cost) to the user in various ways afterwards...
Or, in some other way: on your ticket booked event, store cancellation penalty, too. Then, you can make that value accessible any time, without the need to recompute it... But this may be wrong (?) because penalty would largely depend on time, right (the late you cancel your ticket, the more you pay)?
If all this would like over-complications etc., then I guess I agree with rmac's answer, too :)
I am looking for an alternative spreadsheet to Excel, preferably but not necessarily open source, that allows a programmer to create a plugin that can update cells in the sheet from an external data source in real time. The spreadsheet would then internally compute all dependent calculation chains upon change of value.
This is similar functionality to what the RTD method does with Microsoft Excel. The rate of external data change could be moderate to high (whatever such relativistic terms mean).
Also the reverse process would be useful, i.e. detecting a change in cells and then sending that information to a plugin that can communicate with external processes.
Any recommendations or experience in trying this?
I am afraid you will not find any. The main consumers of the real-time spreadsheets (grids) are big banks and they usually invest in their own solutions. [Because they can afford and they used to see it as their advantage over the competition] Some of the solutions are very dated, but still going strong! Three years ago I worked on a system which was written in C++ (with TibcoRv as a backbone) and it was already five years old. It is still alive and kicking.
One of the strong points of the bespoke grid are "Excel-like formulae" where a user can use a field from the provided data dictionary. So rather than reference cells, you reference data from your systems. It makes formulae easier to implement and read. And of course you can export or share them; users really like that.
The following could be of some help:
http://www.dadisp.com
http://www.quantrix.com
http://www.resolversystems.com/products/
http://pyspread.sourceforge.net/
http://matrex.sourceforge.net/
This may not exactly satisfy your real time requirement but worth exploring.
For an ecommerce website how do you measure if a change to your site actually improved usability? What kind of measurements should you gather and how would you set up a framework for making this testing part of development?
Multivariate testing and reporting is a great way to actually measure these kind of things.
It allows you to test what combination of page elements has the greatest conversion rate, providing continual improvement on your site design and usability.
Google Web Optimiser has support for this.
Similar methods that you used to identify the usability problems to begin with-- usability testing. Typically you identify your use-cases and then have a lab study evaluating how users go about accomplishing certain goals. Lab testing is typically good with 8-10 people.
The more information methodology we have adopted to understand our users is to have anonymous data collection (you may need user permission, make your privacy policys clear, etc.) This is simply evaluating what buttons/navigation menus users click on, how users delete something (i.e. changing quantity - are more users entering 0 and updating quantity or hitting X)? This is a bit more complex to setup; you have to develop an infrastructure to hold this data (which is actually just counters, i.e. "Times clicked x: 138838383, Times entered 0: 390393") and allow data points to be created as needed to plug into the design.
To push the measurement of an improvement of a UI change up the stream from end-user (where the data gathering could take a while) to design or implementation, some simple heuristics can be used:
Is the number of actions it takes to perform a scenario less? (If yes, then it has improved). Measurement: # of steps reduced / added.
Does the change reduce the number of kinds of input devices to use (even if # of steps is the same)? By this, I mean if you take something that relied on both the mouse and keyboard and changed it to rely only on the mouse or only on the keyboard, then you have improved useability. Measurement: Change in # of devices used.
Does the change make different parts of the website consistent? E.g. If one part of the e-Commerce site loses changes made while you are not logged on and another part does not, this is inconsistent. Changing it so that they have the same behavior improves usability (preferably to the more fault tolerant please!). Measurement: Make a graph (flow chart really) mapping the ways a particular action could be done. Improvement is a reduction in the # of edges on the graph.
And so on... find some general UI tips, figure out some metrics like the above, and you can approximate usability improvement.
Once you have these design approximations of user improvement, and then gather longer term data, you can see if there is any predictive ability for the design-level usability improvements to the end-user reaction (like: Over the last 10 projects, we've seen an average of 1% quicker scenarios for each action removed, with a range of 0.25% and standard dev of 0.32%).
The first way can be fully subjective or partly quantified: user complaints and positive feedbacks. The problem with this is that you may have some strong biases when it comes to filter those feedbacks, so you better make as quantitative as possible. Having some ticketing system to file every report from the users and gathering statistics about each version of the interface might be useful. Just get your statistics right.
The second way is to measure the difference in a questionnaire taken about the interface by end-users. Answers to each question should be a set of discrete values and then again you can gather statistics for each version of the interface.
The latter way may be much harder to setup (designing a questionnaire and possibly the controlled environment for it as well as the guidelines to interpret the results is a craft by itself) but the former makes it unpleasantly easy to mess up with the measurements. For example, you have to consider the fact that the number of tickets you get for each version is dependent on the time it is used, and that all time ranges are not equal (e.g. a whole class of critical issues may never be discovered before the third or fourth week of usage, or users might tend not to file tickets the first days of use, even if they find issues, etc.).
Torial stole my answer. Although if there is a measure of how long it takes to do a certain task. If the time is reduced and the task is still completed, then that's a good thing.
Also, if there is a way to record the number of cancels, then that would work too.