Related
I'm using gym toolkit to create my own env and keras-rl to use my env within an agent.
The problem is that my actions space changes, it depends from actual state.
For example, i have 46 possible actions, but given a certain state only 7 are available, and i'm not able to find a way to modeling that.
I've read that question open-ai-enviroment-with-changing-action-space-after-each-step
but this did not resolve my problem.
In Gym Documentation there are not instructions to do this, only an issue on their Github repo (still open).
I can't understand how the agent (keras-rl, dqn agent) pick up an action, is it randomically choosen? but from where?
Can somebody help me? Ideas?
I've handled this by just ignoring any invalid actions and letting the exploration mechanics keep it from getting stuck. Quick and simple, but likely better ways to do it.
I think the better option is to somehow set the probability of selecting that action to zero, but I've had trouble figuring out how to do that.
I have a number of attributes I need for various page loads and other backend tasks, and I'm debating on whether storing these things in a database or calculating them on the fly.
For instance, if there are files that users can upload, and you want to track the size, space taken, format, etc. would it be better to calculate these things once and store them along with the location of the file in the database, or just grab the file each time and get the file attributes manually?
Another use case is shopping cart items. Is it better to calculate the price of an item and store that in a row with the shopping cart table, or calculate the given price each time a page loads. In this case, changes to the price based on site-wide sales, discounts, markups, etc. would not be reflected once the item has been added to the cart unless the prices are updated through another method when sales/discounts/markups are applied. This isn't the best example, but hopefully you understand the idea; maybe you have a better example.
In both of these examples, the source material is available to get the answers from which is key to the question. Obviously, one has a lot overhead for every page load would could be a lot depending on the situation, however the other seems to have less dependence on database integrity in terms of making sure it is always accurate and up-to-date (which I think I prefer). I'm not looking for a specific answer here, because I'm sure it will depend on many variables, but I am looking for a best practice or a method to determine the best solution.
NOTE: This is a similar question but has gotten very little response and no answers.
There can be trade offs between
When a user is waiting, elapsed time is critical.
A user will expect up-to-the-second pricing information.
A user will be frustrated if he orders something, only to find out that you are out-of-stock before his order is submitted.
We cannot say how fast it will be to recalculate things in your system. If you have some SQL code, we can help you speed it up.
Sometimes in Computer Science, it is faster to do the computations when the thing changes; sometimes it is faster to compute when it is requested. It sounds like your case is that it is also slower to compute when it is requested. If it is not "too slow", then that option may be viable.
I have a Microsoft Access business critical database that was originally created in the 90's and has been enlarged and upgraded up to Access 2007 at this point. We have been using this database as a front end for a custom written ERP system essentially. We have moved most of the data over to an SQL server long ago, but we are still using MS Access as a front end. AS the project grows, we have a full time developer, we have started having stability problems and extremely frequent crashes of unknown causes.
As an example: 1 time out of 10 or so, a certain form will crash if I change the data in 1 specific field. There is no code firing at the time, the data is in a local temporary table that typically only has 5 rows most of the time. If I change the data in the table nothing goes wrong, but if I change it on the form Access will hard crash and dump me to the desktop. There are other examples I could provide of unexplained crashes
I am looking for advice on where to go at this point -- the access front end has all of the business logic for running our company essentially so I can't just abandon it. Ideally we would re-write the entire front end in some other language. The problem is that as a small company we don't have the resources to re-write the entire system in anything resembling a good time frame, and don't have the cash flow to pay someone else to do it. My ideal solution would be a conversion of some sort from the access front end to another end point -- whether web or local windows -- but my searches here and on google make that seem like a non-starter.
So essentially every avenue I look at seems to be a dead-end:
We can't find the source of the crashes to stabilize our current system,
We can't stop production in our current system for as long as it would take to re-write it,
We can't afford to pay someone else to write a new system,
Automated conversion tools seem like a waste of money
Are there other options or which of the options that I have thought of seems best?
We have an enterprise level program with an Access front end and an SQL Server back end. I wonder if it might not help to split the program up into different pieces for diagnostics. For instance if you have Order Entry and Inventory Management you could have one front end for each function. (Yes I can hear the howling in the background but if it was only for the purpose of diagnosis maybe it would help... )
You can also export the Access Database objects to text files and then import them into a fresh new database to get rid of weird errors in some occasions.
Well, I guess I will rephrase the basic issue here. If you have two Computing Science graduates on staff then they should have long ago anticipated that they reached the limits of Access. I fail to see this as any different than an overworked, oven in a restaurant that now have too many customers or a delivery truck that does not have the capacity to deliver goods to customers.
Since funds don't exist to re-write then your staff failed to put aside funds on a monthly bases to deal with this situation and now your choices as a result of this delayed action to deal with this growing problem places you in a difficult situation.
The computing science people you have on staff should have long ago seen this wall and limit you hit coming. In my experience is with most CS people is they consider Access rather limited, and thus even MORE alarm bells should have been ringing here and this means even less excuse exists for you to be placed in this unfortunate predicament.
So, assuming the computing science staff you have are well maintaining this application (and I graciously accept this is the case), then then a logical conclusion is this application has reached or exceeded the limits of Access. As noted such limits should have been long ago anticipated.
As you well point out that funds now do not exist for a re-write, then few choices exist without such funds.
However, you case may not be so bad since we NOW know you have experienced developers on staff. Given this case, then my suggestion would be to consider breaking out modules or small manageable parts and features one at a time from the application and having your well trained and experienced developers build either a web interface, or perhaps even using something like .net if you wish to stay 100% desktop. So this "window" of opportunity is a great chance to consider a change in architecture)
Since the data limits are SQL server and NOT Access, then both applications (existing access front end) and the new parts can BOTH well and easy operate on the same data. As you do this, you then break out and remove the existing parts from the Access application. This would suggest you eventaully return to accetable stability in the Access applicaiton. At that point , you could continue, or stop to save funds.
As noted, without funds to re-write, then the only choice is to find some means to free up SOME limited resources on a monthly basis to solve this problem.
At the end of the day, the solution to this problem is more resources, but without such resources then few technical choices and options exist here. Based on the information given so far YOU have made it clear you don't have resources here. However, the solution to this problem here requires resource allocation and planning.
In other words a technical fix to this problem without resources allocated is not likely an available option for you.
I apologize sincerely for not being able to give you a technology solution here, but this looks to be a solution that will require resources to be allocated to the problem and no simple shortcut or trick or magic silver bullet exists here.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
This is going to be the noobist of all noob questions, but what exactly is scope creep, what does it entail?
Scope creep "refers to uncontrolled changes in a project's scope. This phenomenon can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered a negative occurrence that is to be avoided."
Source.
You start with a mouse and end up with an elephant.
In other words requirements change on a daily basis and what you are supposed to deliver doesn't look anything like what was supposed to be delivered at the start of the project
Wikipedia expresses it more completely than I could.
Scope creep (also called requirement creep, or kitchen sink syndrome) in project management refers to changes, continuous or uncontrolled growth in a project’s scope, at any point after the project begins. This can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered harmful. It is related to but distinct from feature creep.
Scope creep can be a result of:
poor change control
lack of proper initial identification of what is required to bring about the project objectives
weak project manager or executive sponsor
poor communication between parties
lack of initial product versatility
There are two definitions for scope creep.
Negative. Scope changed in uncontrolled ways adding cost and risk.
Positive. Scope changed in uncontrolled ways because our fantasy project plan was wrong, and we starting learning things we didn't expect to learn.
Most folks seem to like the first one.
The second one, however is more accurate. The few managers who recognize that scope creep -== learning are able to manage it wisely and get stuff done.
The rest of the managers see uncontrolled learning as a threat. The project won't create the hoped-for deliverables in the fantasy schedule or budget. This means that either scope needs to be reduced or budget needs to be expanded.
Note that most Agile methods don't seem to care much about scope or scope creep. With a narrow focus on the next release, the big picture becomes less threatening and scary.
Learning -- in an Agile context -- also leads to scope creep, but it's a good thing. Stuff that won't ever be useful is deferred. Stuff that didn't seem important when we started gets accelerated.
It's when a project incessantly gets larger and more complex than what was originally planned for, and therefore is perpetually behind schedule and over budget.
When you start your project, you set certain parameters. These parameters are your scope. You should think about what your project is supposed to do, how much will it cost, and how much time is it going to take to complete. When more functionality, time, money.... creeps into the project this can be referred to as "scope creep",
Scope creep is when requirements keep being modified or added to current product release. For example, you show a demo to the customer/user and they request new reports/buttons/fields. It can also occur when a developer wants to add new "cool" features, etc without needing them. It is best prevented by managing the project release cycles. People suggesting features is a good thing, but everybody involved needs to understand the impact on the project and budget. Consider adding new feature requests to a list and meeting regularly to decide which new features get added to the "next release".
In the case of feature creep in my view there needs to be an element of contributing to the downfall of a product. For example growth of a city is good - urban sprawl is bad.
Or in the case of UI design.. all related features get stuck on one control screen - new features are continually added to the point where their mear existance confuses more people than would ever find the features useful.
To qualify as feature creep they should pass the test of contributing to unecessary complexity or throwing unecessary wrenches in the lifecycle of the system. Origionally unplanned features that do not meet this critera should not be concidered feature creep.
Scope Creep is concidered in the same light as feature creep only at the level of a products scope... For example:
Your team is building an "Air Sucker"(tm) which sucks air from one location and transports it to a factory two blocks away. The scope of the air sucker is that it moves air.
Then management realizes the sucking device also needs to suck and transport water and sand. The Air Sucker was never designed to transport liquid or granular materials and thus increasing the scope of the air sucker to the point where it must be significantly reengineered to meet the new transport requirements.
If you have appropriate change controls, possibly a cash cow.
There's a famous picture of a big power boat with a little runabout in tow. The runabout is called "The Original Contract", and the power boat is called "The Change Requests"
features, budget, schedule: pick any 2 but not all 3
Scope creep is any change to the originally agreed on specification/project scope/definition. The change could be due to discovery of prior unknowns, internal/external market changes, technology changes or plan ole' sponsors wanting something more. It negatively impacts the project when there is no change control process in place to review and accept or reject the change.
And how does scope creep affect product schedule?
Is there a way to keep scope creep out of your development process?
How does your PM handle scope creep?
What was the best feature to ever come out of a scope creep?
etc. etc.
Scope creep is like pornography: you know it when you see it.
I am throwing puzzle of my mind towards community leaders for some answers.
We friends decided to build products which already have some big names in the industry. Our motto is not to beat all those players (As we can't), but to develop basic product which is cost effective for some segment a customers.
What we are trying to achieve in first step is cheaper option, as we all knows product grow over the time period, not at once.
Now our catch-22 part-
Should we start building the product as there are already big names?
Price is a right option for USP (unique sale point).
As we all are dependent on jobs, what would be the best option to move forward.
As we also have some customers through verbal confirmation, should we go ahead?
What all major principles we should keep in mind during product development.
Please brain storm yourself on the definition of Product.
It's not just a CD that get shipped, but support, and trust.
Using this extended definition, if you can still beat existing
products, go for it.
Also, don't forget the amortized development cost of product has
probably been recovered by existing company already, so they can
reduce cost any day.
All said, don't let this analysis paralysis stop you ... go for it.
Big Names on the Market
I'm in the eve of such a startup, sometimes being small is a definitive advantage. If you believe you can use that not only price-wise but being agile, doing the core job maybe even better than the big names. If you up for that, I think you can easily infiltrate the market.
Job Dependency
Depends of what you do? If you are opening a next-digg or YACW2A (yet another cool web 2.0 application) then stay in your day job, because generally you can do both, especially if you got your friends with you. If it's a bigger scope you might want to stick with your day job until you got a almost there product.
Don't forget, also you can find an investor, sometimes it's best way to go. So you can just quit and still have a salary in your own job.
Verbal Confirmation
It's great that you already got couple of potential clients, now you need to look into and make a business plan. Understand your monthly cost including salaries, and see what percentage of it you can get out of these clients. If it's good then get some more certain answers from these clients and go ahead. If possible establish the company beforehand and get them buy the product. (one of your friends can do it, not all of you need to leave your day job straight away)
Product Development
Being the big market means do the core functionality perfect, it should just work, and it should be easier. Price by itself can not justify a buy unless you get the core functionality right. Ignore useless enterprise features, or any useless feature. You need to be aware that you got so much more limited resources than your competitors therefore 20/80 Rule (Pareto Principle) is for you. Do not try to satisfy 20% of the market by including crazy features, stick with 80%'s requirements. Big players can satisfy or can try to satisfy 100% of the market, if you try to do the same thing you gonna fail miserably.
Finally
Read Getting Real, Do not follow religiously but this book will give you good ideas and will explain advantages of being small.
You didn't mention, but I wanted to write. Make a proper agreement between you and your friends, ensure everything is in the paper before doing anything! I've seen so many similar startups fu*ked up before even start because of this.
If you think you can build a better product than the ones already on the market, sell it a fair price, and reach your target audience with a limited marketing budget. Absolutely, Go for it!
Our motto is not to beat all those players (As we can't)
First, change your motto. There isn't a product in existence that is perfect for everyone all of the time. There is always a niche to exploit. How can the current products be improved or simplified?
Second, don't focus on price. Customers expect to pay a fair price for a quality product, but they won't buy poor software at any price.
Well. Me and my fellows from our current company having the similar aims.
Here's few our ideas about it:
We are developing (web-based) product that we will use too. This is important for us and hope will help to improve our own performance in some areas and will give inspiration for new features.
We are going to develop product in stages. Not just sit and code silver bullet for industry. Going to start with core and minimal feature set.
Pricing. We are going to give options: use product on our hosting or purchase own copy and install it on own server. Additional and obivious things are different feature sets (technically -- different plugins integration).
Even more, think we'll make the core (as framework) and some plugins public. It'd be good (even neccesary in our case) to create community.
We already have few customers that would like to have highly customised versions of product. If this will have progress, we're going to focus on such activity and provide community with more and more free basic plugins.
That's just general ideas set. Hope you'll find some of them useful.
If by doing so you can satisfy your own requirements (e.g. for risk+cost-versus-reward)
You might want another USP as well: for example, ease-of-use
Work on this in your spare time, or have a part-time job
?
If you don't finish, or if customers don't want what you offer, then you don't get paid
Write up a proper business plan. Be sure to include critical risks and defensible barriers to entry. If no one on your team knows how to do that, then you can stop now as you don't have the right team in place yet.
The business plan is not just another marketing brochure that targets VC. Tell the truth. After you are done, turn it over to people you trust and ask for money. If they wouldn't invest in it, then why should you?
Have you identified a market for a reduced feature (and hence reduced price) product? It sounds like you have not.
Does your group have a passion for a particular product? It doesn't sound like you do. It might be difficult for everyone in your group to really inspired by just some program. Especially if you haven't done the market research.
I wouldn't count on the 'verbal confirmation' customers. Of course, it depends on the amount of money involved. The larger the price of the product, and the longer it takes you to make it really work, the less chance they will actually buy when you have it ready. Do you have reason to believe that there will be many more people that would be interested and would actually buy your product?
If you have enough market research, and a marketing plan, you may be able to get some venture capital, quit your current jobs, work on this full time, get paid, and hopefully make some big money when it goes big.
Best of luck.