I getting started with Django. I want to build a work_manager website with the following content:
hour calculation - enter shifts per day and can view the hours per day, week and month.
shift for each week(maybe a month too) - view table for all the schedules of the employees.
salary calculation per employee for month.
And maybe in the future more things.
For start I have this DB structures:
Now, my question is what is the recommended way to organize the project?
I searched here and find some people the recommended putting all in one app because strong relations between the models can cause problems if you split into several apps.
And some other people recommended to split it that each I can explain each app with one sentence (like I did here up).
So, what is the best practice for that? If to split so how to arrange the models?
Thank You!
it depend on you requirement.
if you want to reuse this app to some other project. then splitting is very good idea.
splitting a project in multiple app are very easy to maintain. if you want to add some more functionality to your app it will be easy for you. only draw back i see in splitting multiple app is it increase burden of importing models and other stuff.
other hand if you put every thing in one app it will also work very well. but it will be tough to maintain and scale n future.
my suggestion is to split app as many as possible.
We have an application with 10 millions lines of code in 4GL(Progress) and a database also OpenEdge with 300 Tables. My Boss says we should migrate it to a new Programming language and a new Database Management system.
My questions are:
Do you think we should migrate it? Do you think Progress has a "future"?
If we should migrate it, how, are there any tools? Or should we begin with programming from scratch?
Thank you for the help.
Ablo
Unless your boss has access to an unlimited budget, endless user patience and a thirst for frustration and agony you should not waste any time thinking about rewrites.
http://www.joelonsoftware.com/articles/fog0000000069.html
Yes, Progress has a future. They probably will never be as sexy an option as Microsoft or Oracle or whatever the cool kids are using this week. But they have been around for 30 years and they will still be here when you and your boss retire.
There are those who will rain down scorn on Progress because it isn't X or it doesn't have Y. Maybe they can rewrite your 10 million lines of code next weekend and prove just how right they are. I would not, however, pay them for those efforts until after the user acceptance tests are passed and the implementation is completed.
A couple of years later (the original post being from 2014 and the answers being from 2014 to 2015) :
The post, which has gotten the most votes is argumenting basically two fold :
a. Progress (Openedge) has been around for a long time and is not going anywhere soon
b. Unless your boss has access to an unlimited budget, endless user patience and a thirst for frustration and agony you should not waste any time thinking about rewrites: http://www.joelonsoftware.com/articles/fog0000000069.html
With regard to a:
Yes, the Progress OpenEdge Stack is still around. But from my experience the difficulty to find experienced and skilled Openedge has gotten even more difficult.
But also an important factor here, which i think has evolved to much greater importance, since this discussion started:
The available Open Source Stacks for application development have gotten by factors better, both in terms of out-of-box functionality and quality and have decisively moved in direction of RAD.
I am thinking for instance of Spring Boot, but not only, see https://stackshare.io/spring-boot/alternatives. In the Java realm Spring Boot is certainly unique. Also for the development of rich Webui's many very valid options have emerged, which certainly are addressing RAD requirements, just some "arbitrary" examples https://vaadin.com for Java, but also https://www.polymer-project.org for Javascript, which are interestingly converging both with https://vaadin.com/flow.
Many of the available stacks are still evolving strongly, but all have making life easier for the developer as strong driver. Also in terms of architectures you will find a convergence of many of this stacks with regard basic building blocks and principles: Separation of Interfaces from Implementation, REST API's for remote communication, Object Relational Mapping Technologies, NoSql / Json approaches etc etc.
So yes the Open Source Stack are getting very efficient in terms of Development. And what must also be mentioned, that the scope of these stacks do not stop with development: Deployment, Operational Aspects and naturally also Testing are a strong ,which in the end also make the developers life easier.
Generally one can say the a well choosen Mix and Match of Open Source Stacks have a very strong value proposition, also on the background of RAD requirements, which a proprietary Stack, will have in the long run difficulty to match - at least from my point of view.
With regard to b:
Interestingly enough i was just recently with a customer, who is looking to do exactly this: rewrite their application. The irony: they are migrating from Progress to Progress OpenEdge, with several additional Open Edge compliant Tools. The reason two fold: Their code is getting very difficult to maintain and would refactoring in order to address requirements coming from Web Frontends. Also interesting, they are not finding enough qualified developers.
Basically: Code is sound and lives , when it can be refactored and when it can evolve with new requirements. Unfortunately there many examples - at least from my experience - to contrary.
Additionally End-of-Lifecyle of Software can force a company, to "rewrite" at least layers of their software. And this doesn't necessarily have to bad and impossible. I worked on a Project, which migrated over 300 Oracle Forms forms to a Java based UI within less then two years. This migration from a 2 tier to a 3 tier architecture actually positioned the company to evolve their architecture to address the needs of Web Ui's. So actually in the end this "rewrite" and a strong return of value also from the business perspective.
So to cut a (very;-)) long story short:
One way or another, it is easy to go wrong with generalizations.
You need not begin programming from scratch. There is help available online and yes, you can contact Progress Technical Support if you find difficulties. Generally, ABL code from previous version should work with only little changes. Here are few things that you need to do in order to migrate your application:
Backup databases
Backup source code and .r files
Truncate DB bi files
Convert your databases
Recompile ABL code and test
http://knowledgebase.progress.com articles will help you in this. If you are migrating from some older versions like 9, you can find a good set of new features. You can try them but only after you are done with your conversion.
If you are migrating from 32-bit to 64-bit and if you are using 32-bit libraries, you need to replace them with 64-bit
The first question I'd come back with is 'why'? If the application is not measuring up that's one thing, and the question needs to be looked at from that perspective.
If the perception is that Progress is somehow a "lesser" application development and operating environment, and the desire is only to move to a different development and operating environment - you'll end up with a lot of resources in time, effort, and money invested - not to mention the opportunity cost - and for what? To run on a different database platform? Will migrating result in a lower TCO? Faster development turn-around time? Quicker time to market? What's expected advantage in moving from Progress, and how long will it take to recover the migration cost - if ever?
Somewhere out there is a company who had similar thoughts and tried to move off of Progress and the ABL. The effort failed to meet their target performance and functionality metrics, so they eventually gave up on the migration, threw in the towel, and stayed with Progress - after spending $25M on the project.
Can your company afford that kind of risk / reward ratio?
Progress (Openedge) has been around for a long time and is not going anywhere soon. And rewriting 10 Million lines of code in any language just to use the current flavor of the month would never be worth it unless your current application is not doing what you need. Even then bringing it up to current needs would normally be a better solution.
If you need to migrate your current application to the latest version of Openedge (Progress) you would normally just make a copy of your database(s) and convert it/them to the new version of Openedge and compile your your code against the new databases and shake the bugs out. You may have some keyword issues, but this is usually pretty minor.
If you need help with programming I would suggest contacting Progress Software and attending the yearly trade show or going to https://community.progress.com/ and asking/looking for local user groups. The local user groups would be a stellar place to find local programming talent.
Hope this helps.....
Getting started in a design of an application that tracks expenses.
Using MongoDB only to get familiar with document oriented DBs.
If I start with a doc design that has one doc per day, and that doc has info like where each dollar was spent, and the amount, am I necessarily starting off in the wrong direction?
I eventually want to slice and dice all of the data like how much was spent at Target between two dates, how much was spent in restaurants for a month, stuff like that.
My question is if I start by having a design that is day oriented, will I get into any trouble right away?
I think that would be just fine. You can make the _id anything you want, but consider making it milliseconds since the Epoch. That might make range queries easier to work with. You can also embed the string version of the date in each document so you don't always have to parse the _id field.
I don't think you'll get into trouble with that design, but prepare to learn a lot when it comes to writing queries in Mongo. Try to stay within their recommendations for writing queries or things can get very slow.
I am working on a business directory in django and am trying to figure out the best method for representing a store's business hours, with an open and close time for each day of the week.
So far the options that I have been unsatisfied are:
- Use one CommaSeparatedIntegerField to hold versions of the times in one parseable unit, but I'd rather deal with time objects if I can, with their various attributes and such.
Explicitly create a TimeField for each day's open and close, but this just sounds like a terrible idea that would take time and be too complicated.
Build a ScheduleField that would handle it, but then I am sort of unclear on the best road for relating to a pre-existing model field or work with the database.
I know any of you can beat any of those. Care to share?
I have a django model for an appointment in a calendar that I am attempting to write a very comprehensive test driver for. The recurring appointment occurs at some point in time and can either run on infinitely or recur for a fixed number of times. The appointment mirrors the functionality available for a Google Calendar appointment (can recur monthly/annually/weekly, every two weeks, every 3 years.)
I'm trying to come up with a unit test that will exhaustively test the basics of this implementation. I am looking for the edge cases that will define the most basic tests.
I have a lot of basic ones, but am looking for suggestions to help identify the most important cases:
1) Create a single appointment
2) Create an appointment that recurs weekly
3) ... recurs monthly
4) recurs every 2 weeks
5) recurs every 2 months
6) recurs annually
Test with final days of months, leap years, and whether it will go crazy when the year has an extra second (this one hit a driver in the zune player).
Test it behaves well when crossing years.
That said, consider whether you are re-testing something that is part of the framework. Testing date logic can get ugly real fast, so you want to draw a line on what is part of your application and what is part of the framework.
Don't forget to test annual recurrence for Feb 29 on a leap year ;)
Before you start rattling off scenarios, you really need to come up with a test plan based on your understanding of the Requirements.
Consider your user base and any other possible/future user bases (as a lower priority). What will they mostly be using it for and how much are those use cases worth to them in their business?
Ideally, create a model of the app and start from there.
Come up with a Risk Analysis of what you plan on doing. Then plan to do functional, security, localization testing, etc.
Then you can start thinking about scenarios based on how "risky" they are (from the Risk Analysis). Focus on writing and executing the "riskier" ones first.
Get Business input (signoff if possible) on your analysis of risk and how the intend to use it.
Just throwing random scenarios out there is not a good test practice and deserves all the ridicule you can get from developers. Testing should be a more engineered, planned exercise. They can hire anyone off the street to run scenarios that come to the top of their head.
That being said, I agree that the previously mentioned scenarios are tried and true. Good ideas. Also throw in Daylight Savings testing. Use different Email clients. Try publishing free/busy date. Get the developers to explain how they are publishing this information. Is it through a web service? Do they expect only Exchange users to use this? Anyone in different countries where dates are formatted differently? You can then find weaknesses and find more bugs.
Happy Testing.