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.
Related
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 have over 6,000 excel sheets. While all the sheets describe the same thing, they are independently formatted. They all have between 9 and 13 columns, but they are out of order, the column names are independently misspelled, and they may or may not have a second, or third, column header.
I am currently trying in python to read cells in a left-down-right-up motion to attempt to locate the same data, but there is physically too many differences in structure names, column ordering, and data definitions to lock them in one a time. Is there a tool that I can use to read these documents and conform them to a single format, via a rapid mapping function?
Thanks much.
Thanks
Wow, it's the Ultimate Data Horror Story.
I want to ask how you ever let it get this way... but I actually don't want to know; I'm already going to have nightmares about this.
It's like that Hoarding show on TV, but with data.
No, I'm afraid that if you can't even identify a pattern then there's no magic function that will be able to either.
But that doesn't mean it's a lost cause. It's just going to need some human interaction, and there are ways to minimize the pain.
What you need is a custom interface that will load the documents one by one, and will walk a human through clicking each relevant column or area, and then automatically load the next document.
There would also need to be buttons for sorting things like obvious garbage sheets (blanks?), "unknowns" (that get put in a folder for advanced research later), and other "unpredictables" may come up during the process.
Also, perhaps once you get into it, you'll notice a pattern you're not thinking of, like maybe *"the person who handled the files from 2002 to 2004 set them up this way"*, or, "when Budget is misspelled, it's always either Bugdet or Budteg".
In this scope, little patterns like that can make a big difference.
Depending on your coding skills, you may or may not need outside assistance with this. I assume this is not data that can just get thrown out, or you wouldn't be asking...
If each document took an average of 20 seconds to process, that would be about 33 hours in total. An hour a day an it's done in a month. Or someone full-time, and it's done in a week.
Do you have a budget you can throw at this? Data archaeology is an actual thing! Hell, I'll do it for you for the right price... (wouldn't break the bank, depending on how urgent it is, of course!)
Either way, this ain't going to be fun for "someone"...
Updating can performance test script e.g. with LoadRunner can take a lot of time and be quite frustrating. If there has been some updates with the applications, you usually have to run the script and then find out what has to be changed, update and run again and so on. Does anyone have some concrete best practices how to ease this updating inferno? One obvious thing is good communication with developers.
It depends on the kind of updates. If the update is dramatic, like adding new fields for user to fill in, then, someone has to manually touch up the test scripts.
If, however, the update is minor, for example, some changes to the hidden fields or changes to the internal names of user-facing fields, then it's possible to write a script that checks the change and automatically updates the test script.
One of the performance test platforms, NetGend, automatically takes care of the hidden fields and the internal names of user-facing fields so it's very easy to create a script to performance-test a HTML form. Tester only needs to fill in the values that he/she would have to enter using a browser, so no correlation is necessary there. Please send me a message if you need to know more about it.
There are many things you can do to insulate your scripts from build to build variability. The higher up the OSI stack you go the lower the maintenance charge, but the higher the resource cost for the virtual user type. Assuming changes are limited to page level resources and a few hidden fields here and there for web sites or applications, then you can record in HTML mode. You blast the EXTRARES sections as the page parser in HTML mode will automatically parse the page and load the page resources even without an explicit reference - It can be a real pain to keep these sections in synch if you have developers who are experimenting quite a bit.
Next up, for forms which have a very high velocity in terms of change consider the use of a web_custom_request() for the one form. You can use correlation statements to pick up all of the name|value pairs as needed and build the form submit dynamically. There will be a little bit more up front work for this but you should have pay offs at around the fourth changed build where you would normally have been rebuilding some scripts.
Take a look at all of the hosts referenced in your code. Parameterize all of these items. I have a template that I use for web virtual users which pairs a default value and the ability to change any of the host names via the control panel extra attributes section. Take a look at the example for lr_get_attrib_string() for how you might implement the pickup and pair that with a check for NULL and a population with a default value in your code
This is going to seem counter intuitive, but comment your script heavily for changes that are occurring often so you know where to take the extra labor change up front to handle a more dynamic data set.
Almost nothing you do with any tool can save you from struuctural changes in the design and flow of the app, such as the insertion of a new page in the workflow, but paying attention to the design on the high change pages, of which there are typically a small number, can result in a test code with a very long life.
Of course if your application is web services based then there is a natual long life to the use of exposed public services. Code may change on the back end of the service, but typically the exposed public interface is very stable.
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.
I wish to create a college project on a simple online multiplayer management game which will involve players setting orders for the day/week and then obtaining profits. Being a relative beginner I am unable to figure out the architecture required for this task.
As far as I am concerned I would be needing the following things:
A text interface to display the status of ongoing events and to set orders in a web browser.
A certain application that would calculate the results every minute and update the database.
A database
Sorry for being so newbish, but any advice or links or books on how to proceed will do.
Please comment if any more information is required.
Any programming language would be fine. Pick a lang / arch you or someone in your group are familiar with. I'm mostly a PHP/ZF, Linux, Postgres guy. So I would...
Write a little ZendFramework app to collect your user's data and save to postgres database. I'd host it on a little Linux server. I like slicehost.com $20/mon, but there are cheaper. Or make friends with someone with a server.
Then for the update of the orders, use a cron job to run every minute. If the update process is complex, use another PHP script, else just straight SQL.
Why do you need to run updates every minute? Are people going to be updating it that often, if they are making orders for a day or week?
I would start with deciding on the equations that will be used in your model.
Then, that will help decide what you need in the database, to give the parameters to the model.
Then, once you have the database, you need to get information from the user, so decide what you need from the user.
For example you should have some random event that will make certain items go up or down in demand, or have resources become more common.
So, you may want to have information in the database that lists what each product is composed of.
If the model will have external information, or, if it is based on what others make, so, for example, last week shoes were not produced, so those that made shoes made a profit. This week everyone is making shoes, so there is too many, so the price went down.
This is why I think starting with your model, and testing your assumptions is the first step.
Any language, system, database will work well, just do what you feel comfy with. When you design the UI, do you want it to look fine on iphones and the Blackberry Razor? Then that will have a big impact on how you design the UI.