This commit is contained in:
Binary file not shown.
@@ -1,359 +0,0 @@
|
||||
# “Do the simplest thing that will work.”
|
||||
|
||||
//COMMENT FLAGS:
|
||||
//TODO: means something that needs to be done but is awaiting something else. This is a *MUST* do.
|
||||
//LOOKAT: means something that I want to think about and revisit later but is not urgent
|
||||
//BEFORE_RELEASE: means something that MUST be changed before release, usually special debugging code for development or testing
|
||||
//BUGBUG: means there's a bug here that is known
|
||||
|
||||
|
||||
Error messages / Numbers
|
||||
- All server error codes start with E1000, all API error codes start with E2000
|
||||
- Look for English text in all the messages so far and see if can be localized even crudely by google translate and do so
|
||||
- Make sure error numbers have a consistent system and don't conflict, I think there are two sets of error numbers, there should only be one
|
||||
- Make sure Every error has a number and that is documented in the manual
|
||||
- Translation keys for error numbers?? i.e. E1000, "blah blah error 1000"
|
||||
|
||||
C# code convention:
|
||||
All names are PascalCaseOnly with the following two exceptions:
|
||||
- function paramenter names are ALWAYS camelCased
|
||||
- CONST values are ALL_CAPS with underlines between for spaces
|
||||
|
||||
|
||||
|
||||
DATES, TIMES, TIMESTAMPS - All dates and times sent or retrieved from the REST interface must be in UTC / GMT time zone.
|
||||
It is the client's responsibility to display and accept dates in local format but interaction with the server is in UTC only.
|
||||
|
||||
Localized text - All text prsented by the server will be a translation key only and it is the clients responsibility to display in local text format with the exception of:
|
||||
- Ops logs, Metrics, event logs: these items and any other future pre-generated text items will be localized at the server according to the logged in users' translation
|
||||
|
||||
|
||||
JAVASCRIPT
|
||||
(mostly using AirBNB standard but using Google standard for naming things)
|
||||
https://google.github.io/styleguide/javascriptguide.xml?showone=Naming#Naming
|
||||
In general, use functionNamesLikeThis, variableNamesLikeThis, ClassNamesLikeThis, EnumNamesLikeThis, methodNamesLikeThis, CONSTANT_VALUES_LIKE_THIS, foo.namespaceNamesLikeThis.bar, and filenameslikethis.js.
|
||||
|
||||
C# Naming
|
||||
https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/capitalization-conventions
|
||||
|
||||
OLDER STUFF
|
||||
=-=-=-=-=-=
|
||||
|
||||
#DISTRIBUTION / DEPLOYMENT
|
||||
- Linux folders to use:
|
||||
- Program files in /opt
|
||||
- Data files in /var/lib
|
||||
- Log files /var/log/
|
||||
|
||||
|
||||
|
||||
|
||||
#PROCESS
|
||||
|
||||
- LEAST PRIVILEGE: Code everything for least privilege possible. The principle of “least privilege” mandates that a process should have the lowest level
|
||||
of privilege needed to accomplish its task
|
||||
- Test / Evaluation data generator developed hand in hand with testing and application code
|
||||
- Data generator is very important, take the time to get it right
|
||||
- Production size and complexity data is required for proper development right from the start
|
||||
- As new modules are added need to add data generation for them as well
|
||||
- Test driven development
|
||||
- Dependency injection
|
||||
- https://joonasw.net/view/aspnet-core-di-deep-dive
|
||||
- Separation of concerns: a Customer object should not have to deal with it's persistence at all directly for example.
|
||||
- Rapid release cycles of small features (every 2-4 weeks)
|
||||
- NEVER select *, always specify columns, shouldn't be a problem with EF but remember this, it's for futureproofing and simultaneous versions running in api
|
||||
- AGILE-like PROCESS
|
||||
- (http://jack-vanlightly.com/blog/2017/9/17/you-dont-need-scrum-you-need-agility)
|
||||
- At every decision favor whatever will in future involve the least amount of supervision by me or manual steps or work Roughly "Agile":
|
||||
- Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
|
||||
- Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
|
||||
- Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
|
||||
- Business people and developers must work together daily throughout the project.
|
||||
- Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
|
||||
- The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
|
||||
- Working software is the primary measure of progress.
|
||||
- Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
|
||||
- Continuous attention to technical excellence and good design enhances agility.
|
||||
- Simplicity--the art of maximizing the amount of work not done--is essential.
|
||||
- The best architectures, requirements, and designs emerge from self-organizing teams.
|
||||
- At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
|
||||
|
||||
|
||||
|
||||
- BEST PRACTICES
|
||||
- SECURITY (https://docs.microsoft.com/en-us/aspnet/core/security/)
|
||||
- Enforce SSL: https://docs.microsoft.com/en-us/aspnet/core/security/enforcing-ssl
|
||||
- PERFORMANCE
|
||||
- Don't use session state at all if possible. Better to reload a session based on JWT userID from persistent storage.
|
||||
- LEAST PRIVILEGE: DO NOT REQUIRE ROOT ACCESS Code everything for least privilege possible. The principle of “least privilege” mandates that a process should have the lowest level of privilege needed to accomplish its task
|
||||
- CONFIGURATION: have as few sources of configuration as possible, ideally in one place or one copy replicated.
|
||||
- PASSWORDS: passwords to production databases should be kept separate from any other configuration files. They should especially be kept out of the installation directory for the software
|
||||
- SECRETS: should be using Environment variables in dev and production. MS says in dev do differently but that is not ideal for consistency and testing
|
||||
- We do not want to have to set multiple configs in multiple locations and hunt around or worse yet have it in code.
|
||||
- Track configuration changes somewhere for analysis when shit goes south. If a user changed a config need to know when and what was changed.
|
||||
- Configuration should be highly protected, it contains database passwords and other important stuff
|
||||
- Never keep the configuration file in the application folder, it will be overwritten on install or restore and if hacked it may be available to the hacker compromising other things
|
||||
- Name config properties according to their function not their nature. Don't use Hostname, use AuthenticationServer
|
||||
- A UI might be helpful here, one that can also track old versions of config for reference so user can revert or look back.
|
||||
|
||||
- A database failure should not bring down the webapi server, it should be able to handle that gracefully with helpful diagnostic information
|
||||
- Need stress and failure testing early and often, i.e. kill database server - what happens? etc
|
||||
- Need longevity testing, have the system keep testing in the background continuously for a week or more with high adn low volume transaction testing
|
||||
- SMALL QUERIES: Favor smaller simpler multiple queries through EF rather than trying to get a whole large graph with many joins at once, i.e. build up the object graph from several small queries rather than one huge one.
|
||||
- (this is my own idea based off issues with things in Ayanova leading to enormous SQL
|
||||
- Tailor small objects that satisfy what would take a much heavier query to satisfy UI requirements, i.e. a tailored customer list for a specific need would be better than loading all the customer data for the list
|
||||
- ISOLATE reporting and history / audit log functionality from transactional functionality
|
||||
- we don't want to use reporting objects in transactions as they are often ad-hoc slower to query, not as streamlined
|
||||
- Transactions are more important than reporting, don't let reporting hurt transactions
|
||||
- Consider a separate database for storing anything not required to process transactions like history, audit, INACTIVE objects that are archived, some reporting etc
|
||||
- PURGING "A rigorous regimen of data purging is vital to the long-term stability and performance of your system."
|
||||
- a second long term storage db can be used for purged data to keep it out of the active transaction data.
|
||||
- Transaction code should be vanilla ORM sql issued, avoid hand crafted sql in business transaction code as it makes db tuning much harder
|
||||
- RESOURCE POOLING is critical
|
||||
- Be very careful with it
|
||||
- Do not allow callers to block forever. Make sure that any checkout call has a timeout and that the caller knows what to do when it doesn’t get a connection back
|
||||
- Undersized resource pools lead to contention and increased latency. This defeats the purpose of pooling the connections in the first place. Monitor calls to the connection pools to see how long your threads are waiting to check out connections.
|
||||
- CACHING
|
||||
- Needs a memory limit
|
||||
- Monitor hit rates for the cached items to see whether most items are being used from cache
|
||||
- avoid caching things that are cheap to generate
|
||||
- Seldom-used, tiny, or inexpensive objects aren’t worth caching
|
||||
- PRECOMPUTE anything large and relatively static that changes infrequently so it isn't dynamically generated every time
|
||||
- NETWORK (at data center level, these might not apply but making note here)
|
||||
- good network design for the data center partitions the backup traffic onto its own network segment
|
||||
- Have a separate network for administration purposes (like we do with softlayer)
|
||||
- This is actually very important for security and peformance, a hacker of the public interface can't access admin functionality if it's bound to another NIC / network
|
||||
- App needs to be configurable which network interface is used for which part so that it's not listening on *all* networks exposing danger to the private network
|
||||
- SLA Even if we never have a service level agreement with our users we should implement it internally so we know if we are living up to it
|
||||
- Good section in the "Release it" book about this, but for now
|
||||
- Have some metrics to watch
|
||||
- Have a service that does synthetic transactions to monitor the live service and log issues.
|
||||
- SLA should be concerned with specific features not as a whole because some functionality is more important than others and can have radically different possible SLA because it may or may not rely on 3rd parties.
|
||||
- AN SLA can only ever be as good as the poorest SLA of anything our service relies on. If an integral component has no SLA then we can't have one either.
|
||||
- LOAD BALANCING: Need it in hosting scenario but it relies on the underlying architecture so this is more in the area of the CONTAINERIZATION Research
|
||||
- DESIGN FOR FAILURE MODES UP FRONT: failures will happen, need to control what happens when parts fail properly
|
||||
- One way to prepare for every possible failure is to look at every external call, every I/O, every use of resources, and every expected outcome and ask, “What are all the ways this can go wrong?”
|
||||
|
||||
- Mock client: if hosting, need an external (not co-located) automated mock client that can detect if the system is down
|
||||
- TIMEOUTS - Always use Timeouts for external resources like database connections, other remote servers network comms etc
|
||||
- Instead of handling timeouts all over the place for similar ops, abstract it into an object (i.e.QueryObject) that has the timeout code in it
|
||||
- Use a generic Gateway to provide the template for connection handling, error handling, query execution, and result processing.
|
||||
- Timeouts have natural synergy with circuit breakers. A circuit breaker can tabulate timeouts, tripping to the “off” state if too many occur.
|
||||
- Fail fast: when a resource times out send an error response immediately and drop that transaction
|
||||
- Fail Fast applies to incoming requests, whereas the Timeouts pattern applies primarily to outbound requests. They’re two sides of the same coin.
|
||||
- DONT JUST TRY A TRANSACTION: Check resource availability at the start of a transaction (check with circuit breakers what their state is) and fail fast if not able to processing
|
||||
- Do basic user input validation even before you reserve resources. Don’t bother checking out a database connection, fetching domain objects, populating them, and calling validate( ) just to find out that a required parameter wasn’t entered.
|
||||
|
||||
- CIRCUIT BREAKERS
|
||||
- Coupled with timeouts usually for external resources but could also be used for internal critical code
|
||||
- Very useful to be able to trip them on demand from an OPERATIONS point of view or reset them on demand
|
||||
- if a call fails increment a count, if it passes threshold immediately fast fail and stop making that call and start a timeout
|
||||
- After fail timeout then half open and try the call again if it passes then close the circuit breaker and go back to normal
|
||||
- If a half open fails again then start the fail timeout again
|
||||
- These are critical incidents to report
|
||||
- If circuit breaker is open then it should fast fail message back to it's caller indicating the fault
|
||||
- Popping a Circuit Breaker always indicates there is a serious problem. It should be visible to operations. It should be reported,recorded, trended, and correlated.
|
||||
- For a website using service-oriented architectures, “fast enough” is probably anything less than 250 milliseconds.
|
||||
- Protect against unbounded result sets (i.e. sql query suddenly returning millions of rows when only a few expected [USE LIMIT CLAUSE ALWAYS])
|
||||
- DO not allow unbounded result sets to be returned by our api, always enforce a built in limit per transaction with paging if no limit is specified
|
||||
- this way a user can't request unlimited data in one call
|
||||
- Also if due to something unexpected a ton of records are created in a table this will prevent a crash from sending all that data back
|
||||
- TESTING
|
||||
- REPLICATE PRODUCTION LOADS EARLY IN TESTING: an hour or two of development time spent creating a data generator will pay off many times over
|
||||
- MULTIPLE SERVERS: if a configuration requires multiple servers in production, be sure to test it that way.
|
||||
- using Virtual Machines if necessary.
|
||||
- If testing on one machine what would normally run on multiple it's easy to miss something vital
|
||||
- FIREWALLS: enable a full firewall on a testing machine and then darefully document any ports that need to be opened as this will be needed for production / installation
|
||||
- STARTUP AND SHUTDOWN
|
||||
- Build a clean startup sequence that verifies everything before flipping a switch to let users in (preflight check)
|
||||
- Don't accept connections until startup is complete
|
||||
- Don't just startup and then exit if PFC fails, it should be up and running to be interrogated by administrator
|
||||
- Clean shutdown: don't just hard shutdown, have a mechanism for each module to complete it's work but not accept new work until all transactions are completed
|
||||
- Timeout the shutdown so if something hangs it can't stop the whole thing from being shut down.
|
||||
- ADMINISTRATION
|
||||
- Ability to set entire API to read only mode both on demand (control panel) and in code (for backup process)
|
||||
- Simple html based admin is ok but command line is better because it can be automated / accessed over a remote shell easily.
|
||||
- Don't have a fancy native app gui admin because it will piss off administrators and be hard to use over remote access
|
||||
- Ideally a simple html for regular users and a command line one for power users.
|
||||
- Try to make every admin function scriptable from the command line
|
||||
- "Jumphost": a single machine, very tightly secured, that is allowed to connect via SSH to the production servers
|
||||
- The ability to restart components, instead of entire servers, is a key concept of recovery-oriented computing
|
||||
- OPS TRANSPARENCY / DASHBOARD
|
||||
- This is important and needs to be in there just as much as the rest
|
||||
- Think of a dashboard that can be seen at a glance or left up all day on a screen in a "command center"
|
||||
- Should show real time snapshot but also scheduled daily events, whether they succeeded or not, i.e. notifications being sent out etc
|
||||
- transparency: historical trending, predictive forecasting, present status, and instantaneous behavior
|
||||
- Log to "ops" database "OpsDB" See page 300 of Release IT for more guideance on this.
|
||||
- Client side api to feed data to ops db
|
||||
- This is important, see the Release It book page 271 for some guidance on what to track
|
||||
- For the most utility, the dashboard should be able to present different facets of the overall system to different users. An engineer in operations probably cares first about the component-level view. A developer is more likely to want an application-centric view, whereas a business sponsor probably wants a view rolled up to the feature or business process level.
|
||||
- COLOR CODING:
|
||||
- *Green* All of the following must be true:
|
||||
- All expected events have occurred.
|
||||
- No abnormal events have occurred.
|
||||
- All metrics are nominal.
|
||||
- All states are fully operational.
|
||||
- *Yellow* At least one of the following is true:
|
||||
- An expected event has not occurred.
|
||||
- At least one abnormal event, with a medium severity,
|
||||
has occurred.
|
||||
- One or more parameters is above or below nominal.
|
||||
- A noncritical state is not fully operational. (For example,
|
||||
a circuit breaker has cut off a noncritical feature.)
|
||||
- *Red* At least one of the following is true:
|
||||
- A required event has not occurred.
|
||||
- At least one abnormal event, with high severity, has
|
||||
occurred.
|
||||
- One or more parameters is far above or below nominal.
|
||||
- A critical state is not at its expected value. (For example,
|
||||
“accepting requests” is false when it should be true.)
|
||||
- LOGGING
|
||||
- Always allow OPS to set the location of the log file
|
||||
- Use a logging framework, don't roll one. (LOG4NET?)
|
||||
- Log files are human readable so they constitute a human computer interface and should be designed accordingly
|
||||
- Clear, accurate and actionable information
|
||||
- columnar space padded, can be read and scanned quickly by humans and also read by software:
|
||||
- [datetime] errornumber location/source severity message
|
||||
- Messages should include some kind of transaction id to trace the steps of a transaction if appropriate (user id, session id, arbitrary ID generated on first step of transaction etc)
|
||||
- Design with purging / pruning log files in mind up front
|
||||
- Don't log to a resource used by the production system (i.e. don't log in the same database as the app is using, don't log to the same disk or volume)
|
||||
- Always use a rolling log format, don't just keep appending.
|
||||
- Do NOT deploy with full debug logs enabled, it's too much noise to spot problems (see AyaNova current log for that)
|
||||
- Ensure a ERROR message is relevant to OPS, not just a business logic issue. It should be something that needs doing something about to be error level.
|
||||
- ** Use short message codes / code numbers so users can convey them easily instead of the long text message!!!
|
||||
- CATALOG OF MESSAGES build a catalog of all the messages that could appear in the log file is hepful to end users
|
||||
- MONITORING SYSTEMS
|
||||
- Logging of severe errors to OS application log can be used to integrate to automatic monitoring systems so it should be an option
|
||||
- Page 297 of Release It has some idea of what to expose and how to expose it.
|
||||
- ADAPTABILITY / CODING DESIGN DECISIONS / FUTUREPROOF
|
||||
- VERSIONING
|
||||
- Static assets should be in a version folder right off the bat, i.e. wwwRoot/css/v1/app.css, wwwRoot/js/lib/v1/jqueryxx.js or wwwRoot/js/templates/v1/
|
||||
- I think naming them similar to the api endpoint versioning is a good idea, i.e "v1" or "v2.1" etc.
|
||||
- this way they can still be served up to old clients without breaking new ones
|
||||
- Need the flexibility of having different version numbers at the backend and frontend. I.E. can refer to AyaNova backend v8.1 and front end v8.3 but keep it in the family of 8.x?
|
||||
- ?? Or maybe the backend is just an incrementing number like a schema update, could be 1000 for all it matters?
|
||||
- ?? Not sure how to handle the index page, maybe it needs to be version agnostic and in turn call another page or something,
|
||||
- maybe Index.html with menu to select indexV2.html or indexV2.3.html
|
||||
- "A new version is available, switch to version 8.5?" user selects and they book mark to that new version indexv8.5.html?
|
||||
- Database versioning (this one is trickiest of all, can't remove old objects until the api is unsupported, but they might need to change, will require creative solutions)
|
||||
- Select * is bad with reversioning, instead selecting exact columns is safer and MORE FUTUREPROOF
|
||||
- Can't drop old columns or set IS NOT NULL on some if they changed that way until after the new release is fully adopted and the old can be removed.
|
||||
- Refactoring
|
||||
- Constantly improving the design of existing code
|
||||
- Only possible with unit testing
|
||||
- Test driven development: write the test first then write the code to pass the test
|
||||
- Write just enough code to make the test pass and not one line more (YAGNI), once the test passes you can refactor all you want as long as the test passes
|
||||
- Mocks are good because they immediately cause the object under test to be "re-used", once in production and once in testing with a mock object, so reuse is tested as well.
|
||||
- Dependency injection
|
||||
- components should interact through interfaces and shouldn’t directly instantiate each other.
|
||||
- Instead, some other agency should “wire up” the application out of loosely coupled components
|
||||
- The container wires components together at runtime based on a configuration file or application definition
|
||||
- Encourages loose coupling
|
||||
- Helps with testing
|
||||
- Defining and using interfaces is the main key to successfully achieving flexibility with dependency injection
|
||||
- Objects collaborating through interfaces can have either endpoint swapped out without noticing.
|
||||
- That swap can replace the existing endpoint with new functionality, or the substitute can be a mock object used for unit testing.
|
||||
- Dependency injection using interfaces preserves your ability to make localized changes
|
||||
- https://joonasw.net/view/aspnet-core-di-deep-dive
|
||||
- https://docs.microsoft.com/en-us/aspnet/core/fundamentals/dependency-injection
|
||||
- http://deviq.com/strategy-design-pattern/
|
||||
- http://deviq.com/separation-of-concerns/
|
||||
|
||||
- SEPARATION OF CONCERNS
|
||||
- Presentation layer
|
||||
- The Presentation Layer should include all components and processes exclusively related to the visual display needs of an application, and should exclude all other components and processes
|
||||
- Service interface layer
|
||||
-
|
||||
- Business layer
|
||||
- The primary goal of the Business Layer is to encapsulate the core business concerns of an application exclusive of how data and behavior is exposed, or how data is specifically obtained. The Business Layer should include all components and processes exclusively related to the business domain of the application, and should exclude all other components and processes.
|
||||
- Object model
|
||||
- Business logic
|
||||
- Workflow
|
||||
- Resource access layer
|
||||
- The goal of the Resource Access Layer is to provide a layer of abstraction around the details specific to data access.
|
||||
- The Resource Access Layer should include all components and processes exclusively related to accessing data external to the system, and should exclude all other components and processes
|
||||
- FIPS
|
||||
- Don't use managed encryption if want to support FIPS
|
||||
|
||||
|
||||
TOOLING
|
||||
=-=-=-=
|
||||
NO PROPRIETARY OR COMMERCIAL COMPONENTS OR TOOLS WHEREVER POSSIBLE
|
||||
Need to automate the fuck out of anything that can be automated.
|
||||
Do this early on so time is saved right from the start.
|
||||
|
||||
|
||||
|
||||
NAMING
|
||||
=-=-=-
|
||||
|
||||
.net Namespace:
|
||||
COMPANY.PRODUCT.AREA (server)
|
||||
GZTW.AyaNova.whatever-whatever
|
||||
|
||||
|
||||
Files, routes, urls etc:
|
||||
Use lowercase entirely everywhere, do not use uppercase, this avoids future confusion all around.
|
||||
No spaces in names, this avoids having to use quotes in paths etc
|
||||
Use spinal (kebab) delimiter, i.e.: coding-standards.txt
|
||||
Here is some REST api guidelines to naming:
|
||||
https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md#16-naming-guidelines
|
||||
|
||||
CSS:
|
||||
BEM naming - http://getbem.com/
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
#TESTING
|
||||
- THINGS TO TEST
|
||||
- Concurrency exceptions with each db type as it could be an issue
|
||||
- Coding should go hand in hand with testing, don't write anything that can't be tested immediately
|
||||
- Write a data generator that goes hand in hand with testing, need large, realistic dataset generatable on demand to support testing
|
||||
- Unit tests where useful but a main focus on integration tests, need to be able to hit one button and be certain a build is passing
|
||||
- Going to need to test all architecture levels early and continuously. I.e. in a docker container, stand-alone, different DB types etc
|
||||
- Test should include exported data from v7 regularly.
|
||||
|
||||
|
||||
```A second, more subtle effect is produced through consistent unit testing.
|
||||
You should never call an object “reusable” until it has been reused.
|
||||
When an object is subjected to unit testing, it is immediately used in
|
||||
two contexts: the production code and the unit test itself. This forces
|
||||
the object under test to be more reusable. Testing the object means you
|
||||
will need to supply stubs or mocks in place of real objects. That means
|
||||
the object must expose its dependencies as properties, thereby making
|
||||
them available for dependency injection in the production code. When
|
||||
an object requires extensive configuration in its external context (like
|
||||
the previously mentioned Customer object), it becomes difficult to unit
|
||||
test. One common—and unfortunate—response is to stop unit testing
|
||||
such objects. A better response is to reduce the amount of external context required.
|
||||
In the example of the Customer domain object, extracting
|
||||
its persistence responsibilities reduces the amount of external context
|
||||
you have to supply. This makes it easier to unit test and also reduces
|
||||
the size of Customer’s crystal—thereby making Customer itself more malleable.
|
||||
The cumulative effect of many such small changes is profound.```
|
||||
|
||||
|
||||
DOCUMENTATION
|
||||
=-=-=-=-=-=-=
|
||||
All documentation will be primarily in Markdown format following the Commonmark spec http://commonmark.org/help/.
|
||||
See tooling doc for how to use commonmark markdown
|
||||
If other formats are required they will be generated *from* the markdown.
|
||||
The api should be self documenting so docs can be generated and api routes can provide information and examples
|
||||
i.e. while coding write the docs for each route / method etc.
|
||||
IF we want to do a web sequence diagram there is a handy tool:
|
||||
- https://www.websequencediagrams.com/
|
||||
|
||||
|
||||
|
||||
|
||||
ERROR MESSAGES
|
||||
The 4 H’s of Error Messages
|
||||
|
||||
Human
|
||||
Helpful
|
||||
Humorous
|
||||
Humble
|
||||
|
||||
|
||||
@@ -1,45 +0,0 @@
|
||||
# Style guide for markdown docs for AyaNova
|
||||
|
||||
## Title usage
|
||||
|
||||
Titles need to be used with navigation in mind as they appear in the index and to the right in the page toc.
|
||||
So put titles in that users would be looking for specifically
|
||||
|
||||
Usage
|
||||
# page title
|
||||
## Major section subtitle
|
||||
### major subsection (optional)
|
||||
this one is optional and used to subdivide a major section into parts
|
||||
#### Field or specific item titles
|
||||
These are very bold and should be used to draw attention to something similarly named in UI that user is looking for in docs
|
||||
|
||||
Titles should have a blank line under them then the text
|
||||
|
||||
|
||||
Every page title is a level one title with one # symbol
|
||||
|
||||
**DO NOT** use fifth and sixth level titles unless absolutely necessary as they appear pretty drab and hard to read in the docs style being used
|
||||
|
||||
|
||||
## Navigation link descriptions
|
||||
|
||||
should be in a code block like this:
|
||||
|
||||
Click on `Accounting` then `Service Rates` to access the service rates form
|
||||
|
||||
|
||||
|
||||
## Form / biz object related doc pages
|
||||
|
||||
form pages should follow identical format, the prototypical form is the acc-service-rates.md form, follow that guide
|
||||
|
||||
## Images
|
||||
use images sparingly and only when absolutely necessary to reduce docs size and save time in future updating outdated images
|
||||
Image should only be there when it's bringing value to what the user is looking at, for example when listing control types etc
|
||||
|
||||
it's not useful to put an image of every form since they are all almost identical, just snip out bits where they would add *greatly* to the xfer of knowledge or speed of uptake.
|
||||
|
||||
## Links
|
||||
|
||||
Be *very* liberal with the use of internal links, users will get far more out of the docs when they can just click around while reading them without having to consule the index or try to figure out where a doc would be.
|
||||
|
||||
@@ -1,228 +0,0 @@
|
||||
# RAVEN FEATURES / CHANGES FROM AYANOVA 7.x
|
||||
|
||||
* Items with an asterisk are completely new
|
||||
|
||||
## FOUNDATIONAL ITEMS / NFR
|
||||
( Things that need to exist right off the start)
|
||||
|
||||
### SECURITY / AUTHENTICATION
|
||||
|
||||
- SECURITY GROUPS / RIGHTS
|
||||
- https://rockfish.ayanova.com/default.htm#!/rfcaseEdit/1809
|
||||
- Moving to roles
|
||||
|
||||
|
||||
- AUTHENTICATION
|
||||
|
||||
### COMMON BUSINESS OBJECT PROPERTIES
|
||||
- *Tags
|
||||
- Regions
|
||||
- Attachments and docs
|
||||
- Wiki pages
|
||||
- Custom fields
|
||||
- Common actions quantified and identified
|
||||
- Event log (actions / events enum)
|
||||
- Notification (notifiable interface?)
|
||||
- Support log (feature usage, crashes, ui element used)
|
||||
- BIZ object switch / circuit breaker
|
||||
- ID number generator for PO's workorders, quotes, pms etc. Unique number for each type.
|
||||
|
||||
|
||||
### SHELL / MENU
|
||||
|
||||
|
||||
## FUNCTIONAL REQUIREMENTS
|
||||
|
||||
### FEATURES
|
||||
- MRU - shell
|
||||
- PLUGINS
|
||||
- WIKI PAGE
|
||||
- LOGOUT
|
||||
- SUBGRIDS
|
||||
- CLIENT GROUPS
|
||||
- DISPATCH ZONES
|
||||
- PART ASSEMBLIES
|
||||
- PART CATEGORIES
|
||||
- PARTS WAREHOUSES
|
||||
- PRIORITIES
|
||||
- RATES
|
||||
- TAX CODES
|
||||
- UNIT MODEL CATEGORIES
|
||||
- UNITS OF MEASURE
|
||||
- UNIT SERVICE TYPES
|
||||
- USER CERTIFICATIONS
|
||||
- USER SKILLS
|
||||
- WORKORDER CATEGORIES
|
||||
- WORKORDER ITEM TYPES
|
||||
- WORKORDER STATUSES - BIG NEW FEATURES FOR THIS ONE
|
||||
- QUICK OPEN WORKORDER / QUOTE / PM BY NUMBER
|
||||
- HELP
|
||||
- CONTENTS F1 (goes to manual online)
|
||||
- TECHNICAL SUPPORT (goes to the forum)
|
||||
- CHECK FOR UPDATES (popup dialog)
|
||||
- PURCHASE LICENSES (goes to license FAQ page, not purchase page)
|
||||
- ABOUT AYANOVA (shows some support info as well as version)
|
||||
- LICENSE (enter / view license)
|
||||
- EXIT (closes AyaNova, weird that it's there and help isn't last)
|
||||
- CUSTOMIZE TEXT (administrator only)
|
||||
|
||||
|
||||
### DASHBOARD
|
||||
|
||||
|
||||
### SERVICE WORKORDERS
|
||||
- SERVICE WORKORDER
|
||||
- SERVICE WORKORDER TEMPLATES
|
||||
|
||||
### QUOTES
|
||||
- QUOTE WORKORDER
|
||||
- QUOTE TEMPLATES
|
||||
|
||||
### PREVENTIVE MAINTENANCE
|
||||
- PM WORKORDER
|
||||
- PM TEMPLATES
|
||||
|
||||
|
||||
### SCHEDULE
|
||||
|
||||
|
||||
### INVENTORY
|
||||
- PARTS
|
||||
- PURCHASE ORDERS
|
||||
- PO ITEMS
|
||||
- PURCHASE ORDER RECEIPT
|
||||
- PO RECEIPT ITEMS
|
||||
- ADJUSTMENTS
|
||||
- ADJUSTMENT ITEMS
|
||||
- PART INVENTORY
|
||||
- PART REQUESTS
|
||||
|
||||
|
||||
### CLIENTS
|
||||
- CLIENTS
|
||||
- HEADOFFICE
|
||||
- CONTRACTS
|
||||
- PROJECTS
|
||||
- CUSTOMER SERVICE REQUESTS
|
||||
|
||||
|
||||
### UNITS
|
||||
- UNITS
|
||||
- UNIT MODELS
|
||||
- LOAN ITEMS
|
||||
|
||||
### VENDORS
|
||||
- VENDORS (only item, nothing else here, hmmmm.....)
|
||||
|
||||
|
||||
### USER PANE
|
||||
- MEMOS
|
||||
- NOTIFICATION SUBSCRIPTIONS
|
||||
- NOTIFICATION DELIVERIES (user or all if manager account)
|
||||
- WIKI PAGE
|
||||
|
||||
### SEARCH
|
||||
- has no sub items at all (will be deprecated and moved into every page at top)
|
||||
|
||||
### ADMINISTRATION
|
||||
|
||||
- *ONBOARDING / GUIDED SETUP
|
||||
|
||||
- GLOBAL SETTINGS
|
||||
- REGIONS
|
||||
- SECURITY GROUPS
|
||||
- USERS
|
||||
- CUSTOM FIELDS DESIGN
|
||||
- LOCALIZED TEXT DESIGN
|
||||
- NOTIFICATION DELIVERIES
|
||||
- REPORT TEMPLATES
|
||||
- FILES IN DATABASE
|
||||
- SCHEDULE MARKERS
|
||||
|
||||
|
||||
### PLUGINS / ADD-ONS
|
||||
- AyaScript
|
||||
- DUMP
|
||||
- ExportToExcel
|
||||
- ImportExportCSV
|
||||
- Merger
|
||||
- OutlookSchedule
|
||||
- PTI
|
||||
- QBI
|
||||
- QBOI
|
||||
- QuickNotification
|
||||
- XTools
|
||||
- OL
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Dec 29th 2017 new workorder structure:
|
||||
|
||||
Users will use templates heavily to get predefined workorder things pre-added so they can just enter what they need.
|
||||
Create new workorder, templates are offered with that option automatically and maybe some built in ones to get people going.
|
||||
|
||||
Instead of the todo and completed sections, each line has a completed or not status and it displays differently
|
||||
so can still see at a glance what is done or not done. Items group within category by completed status.
|
||||
|
||||
So items with quantities are not "completed" until they have an entry in their Quantity field. Suggested quantities only are incomplete.
|
||||
Items without Quantities have a "completed" or "serviced" check-box or some alternative that still gives equivalent to completed.
|
||||
|
||||
|
||||
Instead of Service and materials is the above features, however there could still be a similar view for certain roles.
|
||||
|
||||
Can select charge to customer in same record if completed (or added records with real quantities).
|
||||
By default charges to customer automatically, maybe a setting though?
|
||||
|
||||
Invoice and payments etc still to be determined
|
||||
_______________________________________
|
||||
[WO HEADER BLOCK]
|
||||
- header items
|
||||
[TODOS BLOCK]
|
||||
[TODO1 HEADER BLOCK]
|
||||
|
||||
TODO1 ITEMS
|
||||
- Scheduled techs [no completed status?, does have a checkin feature maybe checkin triggers reveal completed as checkout equivalent?]
|
||||
- Parts [suggested qty and real qty]
|
||||
- Parts requested / on order ["completed" when all received]
|
||||
- Unit(s) [serviced checkbox]
|
||||
- Tasks [already has completed checkbox]
|
||||
- Outside service shipping [suggested and real]
|
||||
- Outside service repairs [suggested and real]
|
||||
- Loan item [suggested qty and real qty]
|
||||
- Custom fields [does this need some kind of completed?]
|
||||
- Travel [suggested and real qty fields]
|
||||
- Labor [suggested and real qty fields]
|
||||
- Expenses [suggested and real qty fields]
|
||||
|
||||
|
||||
TODO2 HEADER
|
||||
TODO ITEMS
|
||||
DONE ITEMS
|
||||
|
||||
|
||||
.....
|
||||
|
||||
|
||||
INVOICE - this is a view that shows bill to customer items, same stuff different view
|
||||
PAYMENTS
|
||||
PROFIT AND LOSS
|
||||
_________________________________________
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
Binary file not shown.
@@ -1,770 +0,0 @@
|
||||
# Pricing licensing activation models
|
||||
|
||||
This is based on basic 6 dollar droplet if users need more then they pay for more, it costs us 4% for anything we charge for so we need to add that to any costs digitalocean charges us, plus a 2.95 transaction fee.
|
||||
|
||||
### SUBSCRIPTION
|
||||
|
||||
cost:
|
||||
Droplet
|
||||
$6 month 1gb / 1cpu/ 1tb xfer/ 25gb total (5GB is taken by installed apps on new setup, so 20gb is free here and available to users)
|
||||
$12/month 2gb/ 1cpu/ 2tb xfer/ 50gb total storage
|
||||
100gb for attachments / backups (NOT DB) $10.00 month
|
||||
250gb '' $25.00 / month
|
||||
|
||||
Fees and taxes:
|
||||
shareIt: MyCommerce ShareIt Model A: 4% + USD 2.95
|
||||
(SHAREIT charges 2.95 per transaction so monthly payments costs us $35.40 a year whereas yearly payments costs us 2.95 so $32.45 a year difference or in monthly terms it costs us 2.70 more per month to process)
|
||||
User though who pays monthly has to pay a transaction fee possibly to their bank or credit card so they have an incentive to buy yearly as well built in
|
||||
DigitalOcean: 7% PST not refundable (gst is refundable)
|
||||
|
||||
So a server costs us 6+7%=$6.42/month or $77.04 per year currently
|
||||
Each payment made costs us 4% + 2.95
|
||||
|
||||
So yearly fixed costs for any scenario or
|
||||
server rental 77.04
|
||||
Shareit flat fee (assuming monthly) 35.40
|
||||
so a customer costs us $112.44 per year plus 4% of sales
|
||||
|
||||
|
||||
|
||||
V8 SUBSCRIPTION
|
||||
(assumes monthly payments always)
|
||||
|
||||
$12 dollar per active logon user
|
||||
1 user= $12.00 month 30.84/yr net profit / charges 144/yr **NOTE** for a one user they should go on to a shared droplet to save money, we can easily double up people as needed to save on this cost or have a mega server for singles and put them all on it
|
||||
5 User = 578.76/year net profit per year | charges 720 yr
|
||||
10 user = $1269.96 / net profit for year | charges 1440 /yr
|
||||
15 user = $1961.16 / net profit for a year | charges 2160 yr
|
||||
20 user = $2652.36 / net per year | charges 2880 / yr
|
||||
50 user = charges 7200 / yr
|
||||
|
||||
Customer contact users
|
||||
Active customer contacts who can login consume licenses.
|
||||
250 are included at no charge.
|
||||
Blocks of 250 more can be added for the same price as a regular user login so 12 bucks a month / 144 yearly
|
||||
|
||||
### PERPETUAL
|
||||
|
||||
|
||||
NEW PERPETUAL V8 PRICING AND SYSTEM
|
||||
Subscription only, no different up front cost, you pay per year for a years worth of support and updates and can stop before the next year renewal and be fixed at that release version.
|
||||
$2/user per month or 24 per user per year, minimum 3 users
|
||||
|
||||
$24/year per **active login user** minimum 3 users for perpetual unlike subscription which has no minimum
|
||||
(Note that the minimum 3 is because a single at 24 bucks wouldn't be worth our time to deal with support and updates and administration and perpet are deliberately priced far cheaper per user so it's not a big jump for single people)
|
||||
1-3 **users** = $72.00 charge to customer / $66.17 net profit
|
||||
5 users = $120 charge / $112.25 net profit
|
||||
10 users = $240 charge / $227.45 net profit
|
||||
15 users = $360 charge / $342.65 net profit
|
||||
20 users = $480 charge / $457.85 net profit
|
||||
50 users = $1200.00 charge / $1122.50 net profit
|
||||
|
||||
|
||||
# NOTHING BELOW HERE IS CURRENT
|
||||
|
||||
---
|
||||
|
||||
###################### TODO: revisit subscription pricing, too high, set to much lower but minimum 100/month effectively by x minimum licenses to purchase
|
||||
|
||||
## NOT Actual OLD SHIT
|
||||
|
||||
Sample email outlining pricing until get on web page:
|
||||
|
||||
Good morning Rich, I have just been given the new pricing.
|
||||
|
||||
There is no web page to send you to yet, but I can just relay it below. Note that I'm typing this out from notes, it's not in official form but it will give you the pricing.
|
||||
|
||||
There are two options coming - "Perpetual" license where customer self installs on their own hardware and "Subscription" license where we host AyaNova for you as a subscription service.
|
||||
|
||||
All prices in US dollars.
|
||||
|
||||
# AYANOVA PERPETUAL LICENSE
|
||||
|
||||
AyaNova self-installed on own hardware / network
|
||||
|
||||
$135.00 per scheduled technician User
|
||||
$0.00 for any other Users that are not scheduled or booked on work orders or have their labor tracked etc (i.e. office staff, Inventory people, Sales, Accounting, Customer User logins etc)
|
||||
|
||||
Includes 30 days Maintenance plan (technical support and any updates released in that time period).
|
||||
|
||||
Yearly Maintenance plans for technical support and updates to the latest AyaNova release can be purchased for discounted price of $100 yearly per scheduled technician with an active unexpired maintenance plan or for $135 yearly per service technician without an active maintenance plan in place.
|
||||
|
||||
Includes at no extra cost our QBI QuickBooks (Desktop edition) integration (Online edition and other accounting platform integrations coming soon).
|
||||
|
||||
Backup data is compatible with Subscription version (below) if you want to switch and save the costs of supporting your own hardware, ISP and I.T. etc.
|
||||
|
||||
# AYANOVA SUBSCRIPTION LICENSE
|
||||
|
||||
AyaNova hosted by us on our servers in your choice of data center
|
||||
(US West, US East, Toronto Canada, Amsterdam Netherlands, Frankfurt Germany, Singapore, Bangalore India)
|
||||
|
||||
We maintain AyaNova for you, always the latest release version.
|
||||
|
||||
(These prices are based on 12 month purchased at a time, if month to month 12% higher to account for extra payment processing costs)
|
||||
|
||||
$50.00 per month per active User
|
||||
|
||||
Any User account who is set to Active in AyaNova, not by scheduled technician as in the Perpetual license.
|
||||
Customers can also be set to optionally login to AyaNova for the Customer self service features; 250 Customer Contact Users (set to active) are included and blocks of 250 can be added on for $12/mo
|
||||
|
||||
Can use the provided subdomain name or bring your own domain for no extra charge.
|
||||
(e.g. instead of using atlas.myayanova.com can be anything.atlasegllc.com)
|
||||
|
||||
Includes 25gb of storage for database and attachments which is a lot based on average AyaNova deployments for v7 more storage available as optional add-on.
|
||||
|
||||
Includes QuickBooks (Desktop edition) integration (Online edition and other accounting platform integrations coming soon) at no extra cost.
|
||||
|
||||
You have access to your own data to download backups any time that are compatible with Perpetual version if you want to switch (with purchase of a subscription license).
|
||||
|
||||
More details on optional add-on's for Subscriptions to come as it's getting finalized but that's the main price.
|
||||
|
||||
- John
|
||||
|
||||
www.ayanova.com
|
||||
|
||||
## ACTIVATION
|
||||
|
||||
The method by which a user starts using your product is called the activation model. i.e. evaluation, trialing etc
|
||||
|
||||
### Free trial
|
||||
|
||||
[helpful info](https://baremetrics.com/blog/saas-pricing-models#free-trial)
|
||||
|
||||
This is the method we use and will continue to use but needs tweaking.
|
||||
|
||||
### Lead quality
|
||||
|
||||
We must require something to improve lead quality, if it's too easy people will just fuck around for the fun of it and waste our time. Some require a credit card but that's a _very_ high barrier I think for just kicking the tires and right now how would we even use that with our payment processor since it's a zero dollar thing up front?
|
||||
|
||||
At the very least we should continue to require a valid email address to get started. Not sure of any better commitment that is simple and works for us so no change there I guess but they cannot download and try without an email address unlike v7 which just works from download automatically.
|
||||
|
||||
### trial period
|
||||
|
||||
Right now we have 45 day trial, that's way too long, it ties up resources and prevents any sense of urgency on the part of the customer.
|
||||
It needs to be as short as possible but still allow them to try it all out. In fact, there are two different types of trial periods now, the perpetual and the saas subscription.
|
||||
|
||||
For perpetual it takes much more time to install and set up to even get running and that's part of the testing process, however they can repeatedly request a trial license no problem but have to erase the data each time so I guess at the end of the day it's not necessary to have different length trial periods.
|
||||
|
||||
I think a 5 day trial period is sufficient. It creates hella urgency, it is really enough time to kick the tires and try everything out for real, if they are super serious but uncommitted yet they can move to renting for a month and really get into it.
|
||||
|
||||
"5 Day trial, if you need more time we suggest sign up for a month"
|
||||
|
||||
### Existing v7 users going SAAS
|
||||
|
||||
We offer the import of data ourselves so that they don't need to fuck around with that as part of the SAAS service?
|
||||
Hmm... a lot of it requires specific to them choices, maybe not.
|
||||
|
||||
## PRICING
|
||||
|
||||
(Joyce made two docs one for pricing as well as historical and projected license sales and a doc about payment processing providers both saved in raven project folder devdocs)
|
||||
|
||||
Note that we really need to consider SAAS right out of the gate because it's totally where things are going it seems and there are many arguments for it even if we are not hosting it yet we can offer it as a subscription they run on premise.
|
||||
See the [links below](#new-idea-perpetual-vs-subscription) and read through them take the time.
|
||||
|
||||
We're likely leaving a lot of money on the table by not having a subsription saas pricing model and we could potentially do both.
|
||||
Two models:
|
||||
|
||||
Perpetual on premise (most expensive up front no recurring revenue, charge for updates and support as required)
|
||||
Subscription hosted (We host they pay a flat fee per month / year to get access to latest version)
|
||||
|
||||
Eventually I'm going to want to cash out and sell the business and recurring revenue model is far easier to sell than a perpetual model.
|
||||
|
||||
### SINGLE LICENSE WILL CHANGE THINGS
|
||||
|
||||
The tiers are artificial for us because they stratified the sales, when we go to the new system of you pay for every tech / user that you need it will become unstratified and we'll get exactly the size each customer needs.
|
||||
some higher level ones may want to decrease because there's no 7 user for example, some may increase because they've been holding off not wanting to level jump.
|
||||
Although in the end I bet it affects new sales more than existing because it's fucking cheap for value right now.
|
||||
|
||||
### Positioning
|
||||
|
||||
Our price position is in the middle: the best value for dollar, not the lowest cost and not the most expensive fanciest one but best value.
|
||||
|
||||
### Value to Price ratio factors
|
||||
|
||||
Value to price ration of 10:1 is ideal, means customers feel like they are getting 10 times more than what they pay
|
||||
I've never heard anyone say AyaNova is too expensive
|
||||
|
||||
### License types and programs we will offer
|
||||
|
||||
TWO types makes the most sense after considering options:
|
||||
|
||||
#### Perpetual
|
||||
|
||||
- Most similar to current v7 but not exactly the same, subscription is broken out separately
|
||||
- One time fee, user can use indefinitely
|
||||
- self installed, hosted and maintained by customer
|
||||
- least profitable for us long term if they don't buy a maint. subscription
|
||||
- Without maintenance subscription, eligable for Minor updates only to fix bugs no new features so in other words they buy 8.0.17 they can upgrade to any 8.0.X version release, but not 8.1 as it will be new features added that don't break backward compatibility
|
||||
- one-time payment, along with the option of a yearly maintenance fee.
|
||||
- This is basically our current model but we allow upgrades for subscribers
|
||||
- **HAS CODE IMPLICATIONS** upgrades need to check if allowed based on version number if no maintenance subscription _not_ on date of build.
|
||||
- TBD - MAJOR RELEASES: not sure yet; if they have an active maintenance subscription can they can upgrade to any newer major releases??
|
||||
- If they lapse the subscription they pay a much higher premium but not quite as high as a completely new purchase to reward past loyalty (i.e. maybe 75% or some other % as appropriate of a new purchase or something?)
|
||||
|
||||
#### Subscription license
|
||||
|
||||
- SAAS, pay month to month to keep using it
|
||||
- We host, maintain and always upgrade they don't need to do a thing but use it
|
||||
- The subscription model involves recurring payments, typically monthly or yearly. The subscription model can be thought of as “renting” the product instead of “owning” it under the perpetual model.
|
||||
|
||||
#### SWITCHING
|
||||
|
||||
We need a formal declaration of how to switch from one to the other models.
|
||||
|
||||
##### Perpetual to subscription
|
||||
|
||||
they start with perpetual but go fuck it we don't want the hassle anymore so....?
|
||||
I'm guessing it's just switching to month to month plans and pricing, nothing special except maybe we offer to move their data for them
|
||||
|
||||
##### Subscription to perpetual
|
||||
|
||||
They must purchase a perpetual license as the SAAS license wont' work with perpetual but they can restore their database from the subscription.
|
||||
|
||||
### Pricing for v8
|
||||
|
||||
#### PERPETUAL
|
||||
|
||||
### IN PROGRESS price
|
||||
|
||||
**US$135.00 / tech up front perpetual license**
|
||||
No volume discounts - same price for any size company
|
||||
Gets you 30 days support and updates and that's it
|
||||
|
||||
**US$100/tech/year maintenance**
|
||||
Only $8.33 per month (must mention in marketing)
|
||||
Price is valid within 15 days of a prior license purchase or a yearly maintenance expiry otherwise it's 135 to start again
|
||||
No volume discounts - same price any size company
|
||||
Gets you one year of support and updates to any release
|
||||
|
||||
**UPDATE INFLATION IN TRUE TERMS CLOSE TO 25% so using that**
|
||||
|
||||
IDEA: figure out average license cost over all sizes of existing license sales, factor _that_ with the 25% true inflation and make that the average license price??
|
||||
|
||||
**update: This concept ok, numbers not exactly what we're going for though**
|
||||
For active subscribers the average price paid for licenses was 121.25 so with inflation of 19.4 that would be 144.78.
|
||||
Tech counts by level is single=30 $4,770.00 total sales, 5=85 $11,815.00 total sales, 10=110 $13,090.00 total sales, 15=15 $1650.00 total sales, 20=100 $9,900.00 total sales
|
||||
(more 10 level techs than any other level and single is kind of lame)
|
||||
So, if we flat price no volume discount and want the inflation increase, if we stuck with 189 for everyone using the single price that's actually a huge amount for the up to 20 crowd
|
||||
|
||||
The real revenue is in the subscription so a lower-ish license cost is where it's at
|
||||
But what if no one buys a subscription?? Maybe though, lower up front and no mandatory subscription which must drive some people away, means more sales when you have a sellable product like early days of AyaNova
|
||||
|
||||
This is all about the initial license purchase, not the subscription which I haven't got to yet. Anyway, we were talking about a flat price per license no matter how many you buy. I still like that idea and was doing some calculations to figure it out. If we went that route then the pricing would make more sense to be calculated on the _average_ price per license sold, not on the single user price which would end up being 90% higher for a 20 user site. I used our existing active subscribers as a basis to calculate the average price of each license sold. I totaled the amount we charged for all active licenses then divided by number of techs overall that the represent and came to $121.25 is the average price we charge per license. So with inflation using your calculation of 19.41% that's 144.78 flat rate price per tech.
|
||||
|
||||
Except the current v7 license comes with 1 year of support and updates and I'm thinking of 30 days initial support and updates so basically we're taking away 11 months worth of support and updates which is not nothing either, not sure if that needs to be factored in or not?
|
||||
The "value" of a support and updates subscription in v7 terms is 35% of initial license price so using the average that's $42.43 a year per tech or $3.40 / month per tech.
|
||||
So of that 121.25 we are saying that the tech / license portion is 78.82 and the support and updates portion is 42.43
|
||||
|
||||
**UPDATE CHANGE OF CALCS HERE, PRIOR WAS BASED ON SALES HERE ON OUT WE USE ACTUAL LISTED PRICES**
|
||||
|
||||
Revenue for current v7 users based on subscription only, not new sales and only AyaNova licenses:
|
||||
Single, 30 active @$55.65 per=$1669
|
||||
Up to 5, 17 active @$243=$4131
|
||||
Up to 10, 11 active @$416=$4576
|
||||
Up to 15, 1 active @$577=$577
|
||||
Up to 20, 5 active @$693=$3465
|
||||
QBI, 10 active @34.65=$346.00
|
||||
So currently $14,418 total revenue for tech subs alone, that needs to like triple just to be worthwhile
|
||||
|
||||
Actual we are going to use method of calculating average license price is to not use sold counts but actually just listed prices on the pricing page so:
|
||||
1=159.00 = 159 per user
|
||||
5=695.00=139 per user
|
||||
10=1190=119 per user
|
||||
15=1650=110 per user
|
||||
20=1980 =99 per user
|
||||
Average here = 125.00 per user so not much difference
|
||||
This means that the average v7 subscription charge per year is $32
|
||||
Which means that the average v7 true initial license charge is actually $93 (93 + 35%=125)
|
||||
And this also means that in v7 the subscription is worth $2.66 (avg) per month (32 / 12)
|
||||
o if v7 was using our new system it would mean we would charge $93 for a license plus $2.66 for the initial 30 days support for a total of $95 (rounded down), then if they purchase a sub it would (in v7 prices) be $32 for 12 months.
|
||||
|
||||
Meaning if use 25% inflation figure v8 would be 95+25% $118 for the license and $40 license for a years sub and updates.
|
||||
|
||||
##### How does it work out?
|
||||
|
||||
Gamed out new pricing based on above system
|
||||
|
||||
All license prices come with 30 days support and updates (maintenance)
|
||||
|
||||
After 30 days runs out they can NOT upgrade nor get support without a subscription.
|
||||
|
||||
**TODO** Some kind of system to prevent just not buying a sub until they need it like a discount to maintain one but a higher charge to purchase, i.e. it's like they are buying a new release in addition to the subscription
|
||||
|
||||
A yearly optional maintenance subscription can be bought which entitles to support and updates including major version releases, if it lapses there is some kind of extra high penalty to start up again but it's not full price so there is _something_ of value in being a prior customer (or is that being too nice?)
|
||||
|
||||
V7 PRICING FOR COMPARISON
|
||||
(price/maintenance WHICH FOR v7 is only in _SUBSEQUENT_ years, not first year)
|
||||
1 user $159/$55.65
|
||||
5 user $695/$243 (139/48.6 each)
|
||||
10 user $1190/$416 (119 each)
|
||||
15 user $1650/$577 (110 each)
|
||||
20 user $1980/$693 (99 each)
|
||||
50 user $3950/$1382 (79 each)
|
||||
QBI $99/$34.65
|
||||
|
||||
HYPOTHETICAL PRICING @ 35% maintenance
|
||||
1 user = $118, maint=$40 ($158 if bought together)
|
||||
5 user = $590, maint=$200 ($790 together)
|
||||
10 user = $1180, maint=$400 ($1580 together)
|
||||
15 user = $1770, maint=$600 ($2370 together)
|
||||
20 user = $2360, maint=$800 ($3160 together)
|
||||
50 user = $5900, maint=$2000 ($7900 together)
|
||||
|
||||
Ok, that's too low almost no one is paying more, I still like the flat license price for this though, it's easier than the fuckery out there in the world and these are really crazy value for money, like 100:1 or more so let's revamp, the cost of development is uber high so lets bump way up the subscriptions, instead of 35% let's make it 50% and see
|
||||
|
||||
HYPOTHETICAL PRICING @ 50% maintenance
|
||||
1 user = $118, maint=$59 ($177 if bought together) (minimum 2?? this is way less than a single hour bill out rate)
|
||||
5 user = $590, maint=$295 ($885 together)
|
||||
10 user = $1180, maint=$590 ($1770 together) (Here and down are our bread and butter and they're barely higher)
|
||||
15 user = $1770, maint=$885 ($2655 together)
|
||||
20 user = $2360, maint=$1180 ($3540 together) (70% increase in yearly maint)
|
||||
50 user = $5900, maint=$2950 ($8850 together)
|
||||
|
||||
SCENARIO: KEEP V7 LEVELS, INCREASE EACH LEVEL BY 25% INFLATION AND MAINT %50 INSTEAD OF 35%
|
||||
(price/maintenance)
|
||||
1 user $200/$100
|
||||
5 user $870/$435
|
||||
10 user $1485/$742
|
||||
15 user $2060/$1031
|
||||
20 user $2475/$1237
|
||||
50 user $4937/$2468
|
||||
QBI $125/$63
|
||||
|
||||
SCENARIO: with 30 days support only and optional yearl maint. A tech is worth on average 100 / hr so do maint at 100 and initial at 35% higher flat no discounts
|
||||
\*\*\* MARKET THIS AS $ per tech per month as it's fucking cheap when you look at it that way
|
||||
|
||||
POTENTIAL **UPDATE, NOT YET ACTUAL** NEW PRICING
|
||||
###################### TODO: revisit subscription pricing, too high, set to much lower but minimum 100/month effectively by x minimum licenses to purchase
|
||||
(UP FRONT PRICE / YEARLY SUPPORT AND UPDATES)
|
||||
1 user $135/$100
|
||||
5 user $675/$500
|
||||
10 user $1350/$1000
|
||||
15 user $2025/$1500
|
||||
20 user $2700/$2000
|
||||
50 user $6750/$5000
|
||||
QBI $135/$100
|
||||
|
||||
So hypothetical profit if using this system with 2022 subscription counts would be:
|
||||
340 licenses \* 100 dollars = 34,000 dollars
|
||||
QBI, 10 active @100=$1000 so 35,000 dollars per year
|
||||
|
||||
Newcomers would double that in the first year becuase they buy the license then the main or maybe not maint but we get more than the maint in year one anyway.
|
||||
|
||||
#### AVERAGE HOURLY BILILING RATES FOR SERVICE COMPANIES 2022
|
||||
|
||||
Plumber 75-150 average 112.50
|
||||
Electrician low average 75/hr
|
||||
General contractor 45
|
||||
Auto Mechanic 102
|
||||
HVAC 150
|
||||
96.8/hr average so let's say 100 / hr
|
||||
|
||||
#### SUBSCRIPTION / SAAS
|
||||
|
||||
##### Must be tied to active users
|
||||
|
||||
That means all users who login including customers
|
||||
|
||||
Customers would be low usage though you can imagine so they could be much cheaper or let's say you get xx customer logins and $xx for a block of a big number of additional
|
||||
Like 100 customer logins included, 20 bucks a month for additional blocks of 100 more
|
||||
|
||||
So it's clear looking over things that there's a cost for a droplet and adding x more users doesn't really add to that for us so if a $5 droplet works for a single user up to let's say at least 10 users, just speculation, we make way more money off the 10 user. The price for a single user must be increased to accomodate that or...we host more than one site on a single droplet to offset the cost, but charge enough to move them up to a higher level without needing to increase the charges to compensate.
|
||||
|
||||
so pricing should be the highest normal droplet we can use
|
||||
|
||||
The range is $64/month/user at the top end (minimum 2 users though) to around 12-15/month/user at the lower end which usually corresponds to 10+ user counts
|
||||
Single user is always most expensive for most sites and I can understand why as it's economy of scale
|
||||
|
||||
Current subs revenue per TECH license is 3.50 per month ($4.375 in 2022 dollars) and we have 340 technician licenses active right now. If they all paid monthly that's $1190 dollars a month in current pricing in support and updates subscriptions alone. In 2022 dollars with inflation that would be 1,487.00 which is only $17,850 yearly revenue, no wonder we're poor. This is unsustainable clearly.
|
||||
|
||||
So let's imagine a different scenario, let's say there are .75 users for every service tech in a business so 340 + 255 = 595 users if they all switched to SAAS
|
||||
|
||||
WAYS TO FIGURE
|
||||
|
||||
Assumption, average server cost will be 20/month per customer (hopefully more like 7 but in some cases 21 or worst case 68)
|
||||
Assumption / fact 73% of our existing customers are 5 and down and most of them would need more staff users on top of techs except the singles I guess
|
||||
Assumption 250 customer User included 20/mo for blocks of 250
|
||||
|
||||
WHAT IF we just charge double the perpetual maint rate?
|
||||
|
||||
Maybe double the perpetual maint price so 16.66 rounded up to 17 per month per user?
|
||||
|
||||
**WHAT IF triple maint** we just charge $35/mo (yearly 12.5% discount and the assumed price everyone would pay) $40/mo (monthly) about triple the maint price
|
||||
|
||||
so for one user our profit if they paid yearly would be assuming a 7 dollar server 35-7=336 dollars per year, maybe not worth it so minimum 2??
|
||||
two user 70/mo-7=63\*12=756/year, that should be less than 1 hour of my time average per month to be worthwhile, like seconds at most
|
||||
|
||||
5 user would be 175/mo-7=168\*12=2000/year
|
||||
|
||||
10 user would be 350/mo-7\*12=4116/year
|
||||
|
||||
**WHAT IF 50/user/mo** $50/mo per user based on yearly or 56.00/mo based on monthly
|
||||
|
||||
5 user would be 250/mo*12=*3000/yr
|
||||
|
||||
10 user would be 500/mo\*12=5000/yr
|
||||
|
||||
**WHAT If quadruple maint (TOO HIGH)?** I have to do a lot of coding to keep retaining so it needs to be worth our while so 4 times the maint rate? (66.66, round to 65) 75/mo
|
||||
1 user 65-7=58\*12=696/year
|
||||
5 user would be =3480, ulp! that seems high, good for us though!
|
||||
10 user $6960
|
||||
|
||||
##### UNKNOWNS TO FIGURE OUT
|
||||
|
||||
Domain work (pricing and practicalities)
|
||||
Email (pricing and practicalities, like do we do this under our domain or)
|
||||
Storage practicalities (pricing just a factor)
|
||||
Server sizing
|
||||
|
||||
###### Server costs
|
||||
|
||||
Once we're rolling with cash flow it would make sense to just rent a huge dedicated server and put multiple accounts on it as it would be very controlled we'd know who and what is using it not shared etc
|
||||
|
||||
Ideally we'd put users individually on the cheapest server available but in practice maybe what we want to do is rent a bigger dedicated server and split users on it (though they need to be in the same datacenter for that to work)
|
||||
|
||||
We'll allocate the $7/mo server to single users so that's 30 techs plus .75 staff so 52.5 users total
|
||||
BUT, let's count on the 14 a month server and worst case the 68/month server dedicated
|
||||
We can probably allocate the same 7/mo to all others and maybe incrementally go up a few before hitting the Absolute worst case scenario i.e. most expensive server ever likely required (not counting storage extra or email costs if we provide which maybe is an add-on??) would likely ever be is dedicated 8gb 2 cpu amnd 50gb storage at $68.00 per month so that would likely be the top end requirement for a pretty big user.
|
||||
|
||||
Maybe it's an idea to always use NAS block storage out of the gate for attachments and just expect it or add-on 10bucks for 100gb block storage is an option.
|
||||
What is scotts total storage again I forget I think it was 4gb or something??
|
||||
|
||||
So the cheapest license cost if we said 12 per user for 10 and up hypothetically would mean a worst case scenario of 120 bucks a month revenu for a 21 dollar a month outlay for server so profit of about 100 bucks a month on the 10 users SAAS versus current revenu of 35 dollars a month for those same 10 users hmm...
|
||||
|
||||
of course we would use the cheapest server set up monitoring and bump them up if we see it pegging out, going to take some time to figure this shit out
|
||||
|
||||
Maybe the way to look at this is a basic price with options that directly correspond to digitalocean add-on's so fixed to 25gb total storage for the droplet initially
|
||||
|
||||
##### Add-ons upgrades
|
||||
|
||||
- STORAGE: So we assume a cheap ass droplet and offer add-on's like more storage attachment space for XX / mo which is really just the digitalocean pricing plus a premium overhead for contingencies if they want it
|
||||
- ATTACHMENTS: we need an add-on for larger attachers, i.e. normal one is considered lite on attachments, no more than 10gb total or somethign as a rule of thumb, if they have greater needs then it's an add-on priced as per digitalocean with wiggle room on top and profit
|
||||
also needs to be their backup volume too, i.e. all file storage except db
|
||||
- Customer logins beyond 250 included, blocks of 250 for 20/mo
|
||||
- RAM / CPU: maybe we offer basic server but they can upgrade to levels for additional per month
|
||||
- BACKUP: self is free vs we do is whatever digitalocean charges plus a premium
|
||||
- Email, if they don't bring their own account we provide at a cost / sendgrid or whatever (I suspect people expect this to be included if turnkey from a phone or something)
|
||||
- Anything we get billed extra for, as it stands we don't care how powerful they need, ayanova supports it, but we don't pay for it, they do.
|
||||
- So, maybe the way to go is base everything off a tiny or next to tiny server and anything else they can pay for as an upgrade.
|
||||
- MIGRATION, we migrate from v7 for them for a flat fee, it's potentially hours of work 200 dollars?, or they can do it themselves
|
||||
- SERVER dedicated servers: premium dedicated servers, available starting at $70/mo
|
||||
|
||||
### Comparatives
|
||||
|
||||
(as of 2022-08-11)
|
||||
|
||||
#### Jobber
|
||||
|
||||
Jobber has good set of options comparable in many ways and has some more features for payment processing integrated etc, is an app based system but fewer strictly service management options no qb desktop integration but does qb online. I'd say it's better than AyaNova in terms of listed features but no idea for usability
|
||||
|
||||
1 user = 49/mo or 39/mo yearly
|
||||
up to 7 users = 149/mo or 119/mo yearly
|
||||
up to 30 users = 299/mo or 239/mo yearly prepaid This is where the majority of our customers would fall
|
||||
|
||||
They have a good license agreement terms that is very restrictive with wide open terminology giving user little to no rights and good terms for cancellations like NO REFUNDS etc saved a copy in xfer research folder
|
||||
good text around bandwidth "substantially higher htan average jobber users" throttle terminate etc
|
||||
|
||||
Yearly payment discount 20%
|
||||
|
||||
Bottom line Average per user price is $13.00/mo but not really broken out that way. Majority of our current users would fall into the $10/mo price range with them per user (up to 30)
|
||||
|
||||
#### AI Field management
|
||||
|
||||
This one is hella complex website and pricing, very confusing, my eyes glazed over a bit
|
||||
Essentially there are 4 tiers with a separate price per user per tier. It's very hard to compare as some of our features are only in their most expensive tier but many of their featuers we don't have and are esoteric like translation by ai of something, ai routing of service calls I think, integration with some things like qb desktop which we can add, what's app, several things we could likely add ourselves.
|
||||
At the very least I'd say the comparable is their "business" level which is 21.99 per user per month no apparent discounts for volume or payment over a year vs a month. The chepest is 9.99 and the most expensive ultimate level is 49.99 per user per month. so average would be 30. The level they push is the "advanced" at 38.49/mo
|
||||
|
||||
No yearly payment discount listed
|
||||
|
||||
bottom line $39 / monthly per user (at a guesstimate)
|
||||
|
||||
#### Housecall pro HVAC field service software
|
||||
|
||||
https://www.housecallpro.com/pricing/
|
||||
|
||||
Clean website pretty clear. Features are hella confusing though, the first listed feature is a credit card with low %, also a phone number, I can't figure out if this is service management or something else, weirdness
|
||||
|
||||
They take payments, a lot of these packages do, need to look into that it's common.
|
||||
They have a "local phone number" whatever the fuck that is weird things these companies offer, not strictly service
|
||||
Three tiers but only two have listed pricing.
|
||||
|
||||
quoting is an addon for 40 a month, recurring service 40 a month
|
||||
The one user is fucking wierd it says chat between users but only has one user so wtf?
|
||||
|
||||
I think the other tier is more comparable at 169/mo or 129/mo yearly 1 to 5 users qb integration, no quote +$40 or pm's + $40 each 40/mo so to compare to ayanova would be at least 249monthly, I don't know about the weird oddball features so I'll ignore them as they are missing a lot of what we do offer, I'm seeing a lot of qb integration included so I'm starting to think that's not an upsell but something to just include with SAAS
|
||||
|
||||
Bottom line $50.00/monthly per user
|
||||
|
||||
#### Kickserv
|
||||
|
||||
Weird one, they also sell credit cards oddly, so must be a kickback extra revenu thing, they all advertise the cashback benefits that scale with the level of license, fucking oddball shit.
|
||||
|
||||
They have 6 tiers with 3 lower ones with less features and user count and 3 larger ones with mroe features and bigger user count. problem with that is some smaller shops need the bigger features so I really think sticking with all features to all users without any bullshit is going to be easier for people to buy into and simpler to market with less fuckery.
|
||||
|
||||
Unlimited users is 299/mo which is 9/mo per user for a 30 count of users but could go unlimited. I guess we could offer an unlimited if we just threw in the price of a high end server and said fuck it do what you want.
|
||||
Their 20 user comparable is$199.00/mo or again 10 bucks a month with a 20% discount for yearly, Im' seeing this number a lot but only when it's a significant number of users
|
||||
10 users is 12 bucks per user per month
|
||||
5 users is 12 bucks per user per month, I really don't know what they are thinking
|
||||
up to 2 users is free but only if hyou sign up for their payment / credit card system which is fucking weird again so a kickback scheme of some kind tha tmust be pretty prefitable to be worth it
|
||||
|
||||
Discount 20% for yearly payment
|
||||
|
||||
Bottom line about 12/user/month kind of
|
||||
|
||||
#### Commusoft
|
||||
|
||||
https://www.commusoft.us/pricing/
|
||||
|
||||
They market as if they're huge, highly rated in the app finder site I am using which seems legit getapp.com
|
||||
|
||||
No user count tiers but feature tiers, this is lowest tier comparable to us:
|
||||
|
||||
$64.00 / mo per user, minimum 2 users!, yearly discount is 7% so not much there at all, no discount for higher user count, minimum 2 users so they swept all the 1 users off the board immediately, interesting and unusual, it all does make them seem better somehow as in we don't give a fuck, I don't know if they are better or not but it appears that way for certain.
|
||||
|
||||
Kind of the way I was thinking, you have 10 users you pay 64, you have 20 you pay 64, no discount. Hmmm... everyone else though has discounts and some are uber cheap.
|
||||
|
||||
You can get a contractor additional license for $5/day which is also interesting way to do it. No inventory no customer access but has a customer reminder for service sent via email.
|
||||
|
||||
10gb per user storage which is rarely mentioned but kind of makes sense as a way to do it I guess.
|
||||
|
||||
Bottom line $64.00 / user / month
|
||||
|
||||
#### Summary
|
||||
|
||||
So 20% discount for yearly billing instead of monthly seems pretty common
|
||||
|
||||
#### New idea perpetual vs subscription
|
||||
|
||||
There is something to be said for a subscription model even if we don't host it. In this system a "perpetual license" is a one time purchase and comes with no support or maybe a very short window they get to use it forever afterwards. The subscription is a rental service only aka a "term license", if they stop paying it stops working. Separate from hosted AyaNova.
|
||||
Businesses like having the option because one is a capital expenditure and one is a operating expense so depending on teh businesses age and status they may favor one over the other.
|
||||
|
||||
CUSTOMER FACTORS:
|
||||
|
||||
| Subscription | perpetual |
|
||||
| ------------------------------------------------ | ------------------------------------------------------------------ |
|
||||
| Charged as operating expenditure | Charged as capital expenditure |
|
||||
| Low up front cost | Large up front cost and cash outlay |
|
||||
| Small impact on P&L year 1 | Big impact in P&L year 1 |
|
||||
| Impact on P&L subsequent years | No impact on P&L subsequent years |
|
||||
| All charges in one fee | Software updates cost extra |
|
||||
| Automatic software updates | |
|
||||
| Shift budget to department rather than big whigs | Big expenditure means need the big shots to approve and is complex |
|
||||
| | |
|
||||
| | |
|
||||
| | |
|
||||
|
||||
OUR FACTORS:
|
||||
|
||||
| Subscription | perpetual |
|
||||
| --------------------------------------- | --------------------------------------------------------- |
|
||||
| Ongoing relationship with customer | Large up front revenu |
|
||||
| Opportunities for upsell and cross sell | Price negotiated once |
|
||||
| Investors value long term customers | Big impact in P&L year 1 |
|
||||
| revenue more than a single license | ongoing revenue from maintenance and prof svcs (reports?) |
|
||||
| so will benefit eventual cashout | (flat support update charges) |
|
||||
| Revenue predictability | |
|
||||
| NO need for legacy support | |
|
||||
| | |
|
||||
| | |
|
||||
| | |
|
||||
|
||||
Links to read with good ideas:
|
||||
This one lets you search actual product pricing for SAAS and has comments about pricing value etc https://www.getapp.com/it-management-software/a/service-now-com/pricing/
|
||||
https://baremetrics.com/blog/perpetual-license-vs-annual-license-vs-subscriptions
|
||||
https://baremetrics.com/blog/saas-pricing-models
|
||||
https://www.getapp.com/resources/software-pricing-models/
|
||||
https://www.pwc.com/mt/en/publications/assets/pwc-the-future-of-software-pricing-excellence-saas-pricing.pdf
|
||||
https://www.milnerltd.com/news/software-pricing-strategy-licence-or-perpetual/
|
||||
https://www.pricingsolutions.com/pricing-blog/subscription-based-software-pricing-how-to-migrate-customers-from-a-perpetual-to-a-subscription-model/
|
||||
https://www.linkedin.com/pulse/basic-differences-between-saas-subscription-perpetual-frederic-hanika
|
||||
|
||||
#### Self installed
|
||||
|
||||
- $189.00 per technician
|
||||
- inital purchase includes 90 days support and updates
|
||||
- No discounts for bulk, same price, there is a discount for bulk support and updates though
|
||||
- Existing users can purchase add-on techs as needed for this price, no discount since they already have the license via their existing support and updates
|
||||
|
||||
#### Hosted SAAS
|
||||
|
||||
Hosting is a later thing, concentrating on self installed for now but here are some initial thoughts on it
|
||||
|
||||
- $TBD, in general, price will be significantly higher than the self installed option to account for server rental costs for us and extra time to manage the servers, the rest of support and other factors costs us pretty much the same (monthly vs yearly a separate issue below)
|
||||
- Price will likely be a factor of average server cost to rent and whatever time will be taken to manage them but must be in line with competitors so may not even be worthwhile, need to determine that later
|
||||
- Code change required: license check internal change when in "Service" mode (already have service mode just not coded yet to count all active users instead of techs only)
|
||||
- will be priced by active user NOT by tech alone as it must account for extra work load on our rented servers we need to pay for
|
||||
- Must have monthly and yearly pricing that factors in the payment processor per-transaction charge (e.g. shareit 2.95 per transaction fee plus extra accounting hassle at our end)
|
||||
|
||||
##### Existing active subscriber users
|
||||
|
||||
For the software license part, there is no affect on active subscribers unless they need to add an addition license as we are giving them the v8 tech license at no extra cost with their subscription
|
||||
|
||||
##### Lapsed AyaNova users
|
||||
|
||||
They purchase as though brand new, the bonus for them is we will ensure they can migrate to v8 via whatever path necessary
|
||||
|
||||
### New license and sales scheme
|
||||
|
||||
PRICING AND PLANS THIS IS OFFICIAL HERE REPLACES ANYTHING WRITTEN ANYWHERE ELSE 2022-08-04 17:25:37
|
||||
|
||||
- PRICING, must figure that out sooner than later, spend some time and give it a think, read joyce's docs keep in mind new licensing scheme worked up with joyce
|
||||
Once I have an idea run it past Joyce for final confirmation then shareit codes and purchase pages etc for website
|
||||
|
||||
PERPETUAL = 5 days trial
|
||||
SUBSCRIPTION = 48 hours trial
|
||||
Flat price per license regardless of how many no discounts for bulk price to be xx.xx
|
||||
Includes 90 days support and updates after which they're on their own. In this way they don't feel coerced into a subscription which must be a turn off for a lot of people
|
||||
Separately they can purchase a support and updates subscription within 90days they get a discount of the ongoing price, after 90 days it's full price
|
||||
NO: this is changed to accomodate the UI - after expiration of subscription all users will get a popup dialog every login saying it's expired
|
||||
First year discounts to be determined then renewal is higher price and status that way unless we raise it.
|
||||
discount to account for 90 day free period that would normally get but can't change renewal date so pro-rate a discount I guess or some fucking thing to be determined, maybe this is about the ongoing renewal price
|
||||
Subscriptions are tiered for the price and there are three levels
|
||||
1 user paid xx.xx
|
||||
2 to 10 users pay xx.xx
|
||||
11 and above xx xx
|
||||
|
||||
Any add on has support and updates through AyaNova support and updates subscription so no separate support and updates for add ons
|
||||
|
||||
Automatically add support and updates if go from one tier to another? Ie they have a single and subscription and but 2 techs so how to automatically handle it?
|
||||
If purchase in AyaNova then it could calculate and offer the correct purchase price and links
|
||||
AyaNova purchase link sends DBID to our pricing.htm page where it will digest that and keep it for presenting tailored options (or they can manually enter their dbid)
|
||||
behind the scenes rockfish will provide options to ayanova.com pricing page for eligable purchases
|
||||
If a coupon is required then it can calculate the discount but will say click here to request your coupon at which time we (I) will make the coupon manually
|
||||
We need that ultimately prorated price for new subscription if moving tiers.
|
||||
|
||||
#### Summary of Joyce's pricing work
|
||||
|
||||
See source document
|
||||
Joyce did the work and figured out the inflation values etc.
|
||||
|
||||
##### HOSTED SAAS SERVICE
|
||||
|
||||
Competitors Hosted usually includes _all_ users, not just techs and I can see why since it affects traffic and usage considerably
|
||||
bills per month and we get dinged 4% plus a 2.95 fee each transaction so need to increase considerably the price over a yearly charge
|
||||
When it comes time to do this I will need to revamp the AyaNova license code to count all active users, not just service techs and it will need to be cheaper as we want to keep it simple, can view competitor pricing in her doc 20220112subscriptionoverview.odt to work that out
|
||||
|
||||
##### SELF INSTALLED
|
||||
|
||||
Basically Joyce's price for a single license if inflation factored in is 189.00 per license which sounds about right to me, in the past wew've had it as high as 199.00 per license so this is actually a discounted price
|
||||
|
||||
### Joyces email from jan 2022:
|
||||
|
||||
3 Inflation:
|
||||
|
||||
2016 to 2021 12.6% i.e. $159 in 2016 is up to $179 in 2021
|
||||
2021 to 2022 6.81% inflation, expected inflation between 2021 and 2022 is a further %6.81 for total of 19.41% between 2016 and 2022
|
||||
– price to offset inflation is $189 from $159.00
|
||||
|
||||
this is the government’s “inflation” – doesn’t really reflect actual costs or geographical locations but its a general start...
|
||||
|
||||
Example of what this would look like if existing AyaNova yearly subscriptions were increased by :
|
||||
Existing Single $159 first year, renewal 55.65 -> 13.25/month 1st year, 4.63/month renewal
|
||||
If increased 19-20%: Single $189 base, renewal of $66.15 -> 15.75/month first year, 5.51/month renewal
|
||||
|
||||
Existing Up to 5 $695 first year, renewal of $243.25 -> 57.92/month 1st year, 20.27/month renewal
|
||||
If increased 19-20%: Up to 5 $829 base, renewal of $290.15 -> 69.08/month 1st year(13.81 per tech per month 1st year), 24.18/month renewal (4.84/month per month per tech renewals)
|
||||
|
||||
Up to 10 $1190.00 first year, $416.50 renewal -> Up to 10 $1419.00 base, renewal of $496.65
|
||||
Up to 15 $1650 first year, $577.50 renewal -> Up to 15 $1969.00 base, renewal of 689.15
|
||||
Up to 20 $1980 first year, $693.00 renewal -> Up to 20 $2359.00 base, renewal of $825.65
|
||||
Up to 50 $3950 first year, $1382.50 renewal -> Up to 50 $4700 base, renewal of $1645
|
||||
|
||||
Having a different higher price for the first year rewards companies that STAY with AyaNova – this is a selling point and recommendation is to maintain this (i.e. initial purchase is higher, renewals are then lower)
|
||||
|
||||
Most/Some companies list their pricing PER MONTH but still require a year prepayment.
|
||||
|
||||
4. Examples of competitors pricing
|
||||
|
||||
Note that the smaller “cheaper” apps such as Jobber, WorkWiz, Fergus, Loc8 – are Saas (software as a service) with no additional hosting charge (price covers hosting and the app) AND charge per login users regardless if scheduled or non-scheduleable
|
||||
|
||||
“Hosted” now refers to when a customer purchases and owns software; each customer is treated separately, with individual instances of software, databases and servers. This model entails installing the software via a hosting center or internally on customer’s own servers, requires manual updating when convienent to the customer (is not pushed on them), etc. If customer stops paying for subscription, still can use the software just no updates/support.
|
||||
|
||||
Jobber:
|
||||
https://getjobber.com/pricing/
|
||||
Price is per user - A user is anyone who needs to log into Jobber at the office or in the field in order to view and/or manage the team’s schedule – in other words, scheduleable AND non-scheduleable both require licenses per login.
|
||||
CORE - Monthly Plan - $49/mo ON SALE $35/mo for 1 user
|
||||
CONNECT- Monthly Plan - $139/mo – ON SALE for $98/mo for Up to 7 users
|
||||
GROW - Monthly Plan- $279/mo ON SALE $196/mo Up to 30 users
|
||||
Additional Users $19/mo – for example if using the CONNECT and have 10 users price would be $155/month – approx $15.50 per month per user
|
||||
Each (CORE, CONNECT, GROW) has more features than the next
|
||||
Phone, Email and online chat support are ALL included at no additional charge
|
||||
|
||||
WorkWiz:
|
||||
https://www.workiz.com/pricing-plans/
|
||||
STARTER $65 / MO - Up to 2 Pro Users ($780 for the year)
|
||||
TEAM $169 / MO Up to 6 Pro Users / Phone, Chat and Email support ($2028 for the year)
|
||||
PROFESSIONAL $299 / MO Up to 15 Pro Users / Phone, Chat and Email support ($3588 for the year)
|
||||
All plans are committed to annually – but they list pricing per month - (each additional user is $30 a month - $360 a year)
|
||||
Users are anyone that logs in and/or is scheduled – so office AND techs count towards licensing
|
||||
|
||||
Fergus
|
||||
https://fergus.com/pricing/
|
||||
month to month pricing only – no year commitment. They prorate billing so ends being at the beginning of following months
|
||||
$27 Monthly per Full User (minimum 1 Required) / $10 for “Timesheet user” which is a tech with limited access to just the workorder info
|
||||
They have a Free plan with reduced features and max of 10 jobs (i.e. workorders) per month – a company can change their plan to Free and keep using (not sure how they recoup their hosting costs)
|
||||
|
||||
Loc8
|
||||
https://www.loc8.com/pricing/
|
||||
These are PER MONTH charges.
|
||||
$10 USD(1 user), $39 USD(Up to 4 users), $99 USD(Up to 12 users), $199 USD(Unlimited users)
|
||||
|
||||
FreshService:
|
||||
NOT comparable to AyaNova – used for online support, call centers
|
||||
Has three different teirs depending on what features – NOTE they charge by “Agent” as looks to be used by online support - i.e.
|
||||
$19/month , $49/month, $89/month
|
||||
|
||||
Salesforce:
|
||||
Has different products depending on the need – i.e. their callcenter program is different than there “field service mobile” – has different pricing depending on
|
||||
For “field service mobile” related – dispatcher is $150 A MONTH, tech is $150 A MONTH, contracter is $50 A MONTH – holy shit
|
||||
|
||||
ServiceTitan:
|
||||
Uses same pricing model as us – per technician.
|
||||
Unable to find pricing anywhere – you HAVE to contact them (they have over 1200 employees to service their customers) and provide details so they custom tailor the costs to you.
|
||||
Annual “contract” only – committed and reviews talk about expensive, and sucks when something that was upsold ended up not being useful is still under contract and have to pay for – i.e. can’t trial aspects for a month or two, have to commit up front
|
||||
|
||||
Skedulo:
|
||||
Also does NOT list pricing, and can’t find anywhere.
|
||||
Annual price only – does NOT do monthly.
|
||||
|
||||
SimPro:
|
||||
No where is pricing listed
|
||||
|
||||
ProBusinessTools:
|
||||
https://www.probusinesstools.com/pricing.aspx
|
||||
PBT Enterprise - Setup: $4,250 / $65/month per user - 5 User Minimum (min $325/month)
|
||||
Support-Unlimited, Training-Unlimited, Data Backups, File Backups, Security, Integration, Standard Features Email Notifications Custom Reports
|
||||
2,000,000 record storage, 50 Gigs file storage, customizations $125/hour
|
||||
PBT Premium - Setup: $2,250 / $45/monthperuser - 5 User Minimum (min $225/month)
|
||||
PBT Lite - Setup: $650 / $250/monthperuser - Up to 10 Users (min $2500/month)
|
||||
|
||||
5. Possible scenarios for AyaNova 8 onwards
|
||||
|
||||
I think existing customers will freak if jumped as high as Jobber (i.e. .$35 per month x 12 = $420 a year (versus our 1 user of $159 a year and then $56 renewals) if still requiring them to host themselves.
|
||||
The expectation is that EXISTING CUSTOMERS would continue to get their existing subscription pricing ...with notification that increase will be coming, retiring of some, etc
|
||||
Existing customers are needed until enough new orders come in – do not alientate.
|
||||
Fergus and Loc8 pricing would be more in line to AyaNova pricing BUT they also provide it as Saas (i.e. everything is looked after by them, companies don’t install to their own server)
|
||||
|
||||
Don’t want to price AyaNova out of the market, nor under-price it. Needs more research into what the market will bear, what will bring “past” users BACK to AyaNova (we have email addresses – we shoudl use - note to be careful about European email addresses due to strict privacy/spam issues etc but that is another discussion and not sent out until AyaNova 8 is “solid” and not dealing with existing customers moving up etc – i.e. don’t overwhelm AyaNova support)
|
||||
Ability to pro-rate (presently not possible with ShareIT – this and other issues are arggghhh )
|
||||
I have looked into other payment processing companies, have a whole spreadsheet with two narrowed down with one the forrunner)
|
||||
|
||||
suggestion once AyaNova 8 is fully out:
|
||||
|
||||
1. Increase/consolidate subscription pricing – AND FOR EXISTING customers, especially who have been with subscriptions since 2016, 2017 onwards, give them a “discount” – basically discount “down” to same price as they paying now, for the next xxx amount of time
|
||||
Example:
|
||||
AyaNova scheduleable user subscription per - $xx/year / $xx/month
|
||||
Renewals June of each year. Let them know that they are getting a DISCOUNT (so they pay same amount, but LOOKS to them they are getting preferential amounts – how it looks is important even if end result is same or slightly more...
|
||||
2. Don’t really have to faze out support for older version, as our support/updates have always said we “support the latest version” which “means” we are not obliged to support AyaNova 7.6 or older once 8 is stable
|
||||
|
||||
NOTE:
|
||||
Jan 18 2022 addition: ShareIT charges a minimum USD 2.95 + 4.00% of the product price for EACH transaction. So this means that IF we offer monthly subscription pricing as well as yearly, that the monthly HAS TO take into account the additional expenses: additional payment processing cost + hands-on to provide license, etc
|
||||
i.e.
|
||||
Single tech subscription if prepay for entire year:
|
||||
USD$185.00/year (costs us 2.95 + 7.40 = $10.35) 185 – 10.35 = 174.65 “profit”
|
||||
|
||||
Single tech subscription each month over 12 months if use same year price divided by 12:
|
||||
185/12= $15.42/month (costs us 2.95 + $0.62 =$3.57 x 12 = $42.84) 185 – 42.84 = 142.16 “profit”
|
||||
|
||||
So IF offer monthly subscription the monthly per price needs to be approx $40 HIGHER in cost $225/12=$18.75/month costs us $2.95 + 0.75=$3.70x 12 = $36.15 total for the year 225 – 36.15=$188.85 for year “profit” with 12 times the amount of accounting/licensing/etc
|
||||
|
||||
More to discuss but this is an overview
|
||||
@@ -1,37 +0,0 @@
|
||||
This case is for overall goals of what or how AyaNova 8 should be different / improved
|
||||
____________________________________________________________________________________________
|
||||
|
||||
- FIRST AND FOREMOST: has to be something I can sell and support alone with minimal effort
|
||||
if any part of the process requires me to spend time regularly on it then that needs to be eliminated or automated.
|
||||
- DIRECT PORT of AyaNova 7.x, try to keep as similar as possible but improving where necessary
|
||||
- It would be crazy to try to re-invent the wheel on this
|
||||
- Easier to upgrade for the customer - no hassle updates
|
||||
- Should be a black box that only relies on the db and the configuration to be updated.
|
||||
- SIMPLER FOR A USER TO UNDERSTAND
|
||||
- Simplify the structure, anything confusing or redundant eliminate
|
||||
- Things like TAGS which eliminate the need for a bunch of different separate objects
|
||||
- No need to learn about a separate "Dispatch Zone" object, just use a tag for that and so we can provide examples of how to tag and how to use tags without
|
||||
having to teach or support a bunch of disparate features.
|
||||
|
||||
- Modern technology as open source as possible (no proprietary code if possible)
|
||||
- More quickly add new features and not have to make huge monolithic updates but can do a quick feature add
|
||||
- Scale from standalone single user to containerized service capable of being hosted for thousands
|
||||
- Fully secure to modern standards that are appropriate
|
||||
- Cleaner interface, fewer separate objects, more use of tags instead of discrete categorization type objects
|
||||
- Easy to use modern API, self documented for users with example snippets
|
||||
- Easy to learn with guided training
|
||||
- Easier to support for us and the customer
|
||||
- Easier to install for the customer
|
||||
- Easier to sell and manage sales end of it
|
||||
- Easier to maintain for the customer (backups, upgrades etc)
|
||||
- Better looking, modern, clean more focused interface that is easier to enter data into quickly
|
||||
- Imports as much of AyaNova 7.x data as possible automatically
|
||||
- Easier to trial for test users
|
||||
- Something we can offer to host with as minimal hassle to us as possible
|
||||
- Operating system agnostic
|
||||
- Responsive interface for a variety of screen sizes (or at least wide and phone)
|
||||
- Automated build of api docs that can be accessed from the api itself
|
||||
- Automated or easier generation of manual / MARKDOWN
|
||||
- Support the latest browser and the one before it of every major browser like gitlab does:
|
||||
- Supported web browsers, We support the current and the previous major release of Firefox, Chrome/Chromium, Safari and Microsoft browsers (Microsoft Edge and Internet Explorer 11).
|
||||
- Each time a new browser version is released, we begin supporting that version and stop supporting the third most recent version.
|
||||
@@ -1,11 +1,12 @@
|
||||
# Research required
|
||||
“Do the simplest thing that will work.”
|
||||
TODO: consolidate, delete or retain and move these items into how-to's in rockfish or a new how-to.md doc here in devdocs
|
||||
|
||||
# Research required
|
||||
|
||||
# BACK END / ARCHITECTURE
|
||||
|
||||
|
||||
## DOCKER FINDINGS
|
||||
TODO: Clean up anything juseful here in a howto docs
|
||||
- Need a shared docker network between all containers, I was assuming could just redirect to localhost but didn't realize docker network is internal to docker
|
||||
- this helped https://stackoverflow.com/questions/39202964/how-to-reach-another-container-from-a-dockerised-nginx?rq=1
|
||||
- first created a defined external network sudo docker network create docker-network
|
||||
@@ -23,278 +24,3 @@
|
||||
- Where ayanova is the image name in the docker compose file for starting AyaNova server
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
## DEFAULT PORTS (unassigned) http://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.txt
|
||||
- Some available ports not specifically assigned that I like the look of:
|
||||
- 4048, 4144, 4194, 4195, 4196, 4198, 4317, 4318, 4319, 4332, 4337-4339 , 4363-4365, 4366, 4424, 4434-4440, 4748, 5076-5077, 5551-5552,5994-5998
|
||||
- 7575-7587, 8084-8085
|
||||
- 7575 (RAVEN IS USING THIS)
|
||||
- 5995?
|
||||
- 4424?
|
||||
- 8084?
|
||||
|
||||
## ?? LICENSING
|
||||
- ??how to functionally license RAVEN
|
||||
- ??how to protect the keys
|
||||
|
||||
## ?? How am I going to expose the api for developers
|
||||
- Only through the rest interface?
|
||||
- Will there be plugins at the backend code level in any of those layers?
|
||||
- OUR STUFF VS END USERS STUFF
|
||||
- What existing plugins did we make and what would they need from Raven to be replicated?
|
||||
- how will this affect api decisions?
|
||||
- What can end users be allowed to do and how and at what layer.
|
||||
|
||||
|
||||
## ?? FUNCTIONAL REQUIREMENTS /FEATURES
|
||||
|
||||
Look at AyaNova existing code,
|
||||
A) what worked well
|
||||
B) what was repetitious and should be automated
|
||||
C) what had ongoing problems
|
||||
|
||||
Will help greatly with design
|
||||
|
||||
## TAGS
|
||||
- Wait to choose implementation type until basic design is decided upon as it will affect method use internally
|
||||
- This is actually a big adn tricky topic, here are some resources found while researching:
|
||||
- http://tagging.pui.ch/post/37027745720/tags-database-schemas
|
||||
- https://stackoverflow.com/questions/172648/is-there-an-agreed-ideal-schema-for-tagging
|
||||
- https://dba.stackexchange.com/a/35795 <---this is what I'm leaning towards
|
||||
- Leaning towards a single tags table with word and id (and maybe other properties like color, last used etc)
|
||||
- Each taggable other table has a map of it's own to the tags, so i.e.[TAGS: id, text] [CUSTOMERTAGS: customerID, tagId], [WORKORDERTAGS: WOID, tagID]
|
||||
- This will require a bit of complexity to keep it pruned though, i.e. tags will get orphaned when no one is using them so a routine will periodically need to clean them out.
|
||||
- This may be a better way to handle full text indexing as well with a search table for each object table. Kind of balloons the table count though, but who cares really, does that matter?
|
||||
- An alternative is exactly like how I do full text search in AyaNova now with a generic foreign key, upside is cleaner db structure, but downside is ensuring cleanup and maint.
|
||||
- If parent object is deleted must go in and remove any linked tags as well.
|
||||
- Upside is it's easily searchable for all incidents of a specific tag over all taggable types, but is this really necessary? It can still be done with separate queries.
|
||||
|
||||
|
||||
** SEPARATE FOR *MVP* PRIORITY ONE IS MUST HAVE BEFORE RELEASE 8.0 / PRIORITY 2 OR LOWER IS NICE TO HAVE **
|
||||
- go over all rockfish AyaNova related cases and request for features, into the hopper.
|
||||
- Move stuff to v8 if going forward, otherwise drop it's priority to lowest in AyaNova 7.x and any related project cases
|
||||
- Move any items that just have to be done now for v7 into high priority AyaNova 7.x track.
|
||||
- ?? What are the commonalities of things required in the UI to come from the backend based on current AyaNova
|
||||
- Name ID lists?
|
||||
- list factories
|
||||
- report factories
|
||||
- fetch by name / id
|
||||
- Email sending and processing
|
||||
|
||||
|
||||
|
||||
|
||||
## ?? CONCURRENCY ISSUES
|
||||
- In the ef core book the author mentions getting around a concurrency issue by making it a non issue by not even updating the same order but instead appending status changes to another table
|
||||
- https://livebook.manning.com/#!/book/entity-framework-core-in-action/chapter-8/v-7/171
|
||||
- "This design approach meant that I never updated or deleted any order data, which means that concurrent conflicts could not happen. It did make handling a customer change to an order a bit more complicated, but it meant that orders were safe from concurrent conflict issues."
|
||||
- Microsoft tutorial: https://docs.microsoft.com/en-us/aspnet/core/data/ef-mvc/concurrency
|
||||
- See what will be critical concurrency in RAVEN (inventory likely), see if can code around it so no concurrency can happen.
|
||||
- Plan on what is concurrency prone and how to deal with it.
|
||||
- Maybe split out the concurrent sensitive bits of a workorder (parts) to a different screen, i.e. show read only in workorder adn to update that specific section have to go in and do it like a wizard or something?
|
||||
|
||||
## ?? BACKDOOR / LOST PASSWORD
|
||||
- How to handle this, current method is horribly susceptable to nefarious purpose
|
||||
- Maybe requires "physical" access to the server (put a file up or something?)
|
||||
|
||||
## ?? AUTOMATED BACKGROUND PROCESSOR "GENERATOR"
|
||||
- What will replace "Generator" in RAVEN?
|
||||
|
||||
|
||||
## FRONT END
|
||||
|
||||
- VISUAL DESIGN / UX
|
||||
- - https://www.ventureharbour.com/form-design-best-practices/
|
||||
- Make the form designs simple and beautiful, it will directly translate into sales
|
||||
- Field labels above fields, not beside them (https://research.googleblog.com/2014/07/simple-is-better-making-your-web-forms.html)
|
||||
- Single column vertical layout for complex forms is definitely best. In wide mode though what to do?
|
||||
- It's ok to have two inputs on a line together if they are directly related so that they have one single label above them and minimal space between them
|
||||
- i.e. date and time ([day] [month] [year] [hour][minute] etc)
|
||||
- But really don't if possible because it's never better than a single field that just "figures out" the parts of the input.
|
||||
- Always indicate required fields, don't just error if they are not filled out.
|
||||
- Break big forms into sections with shaded headers or emboldened headers with larger fonts but shaded background is good even with no text to break apart.
|
||||
- Use single fields for phone numbers or postal codes and process and interpret it through code rather than forcing them to use multiple fields as this causes confusion
|
||||
- Messages to users that are important and long and required to convey need to *really* stand out to even be read. In their own box with a different background or something alike.
|
||||
- Put validation errors to the right of the input field, not below it as users can see it better and it requires less cognitive load.
|
||||
- Multi page forms (like wizards) need to have progress indicators or people will get antsy and bail
|
||||
- Favor checkboxes or radio buttons over drop downs unless there are more than 6 or so options as they require less cognitive load
|
||||
- Use placeholders sparingly (light gray prompt inside input) only when there is ambiguity, don't use them for obvious stuff
|
||||
- Always use a predictive search / autocomplete for any field that requires a selection from a large number of options
|
||||
- Selectable images are the most compelling engaging selection type for users
|
||||
- I.E. like a row of radio buttons but a row of images to select from and the choice is the selection by clicking on the image.
|
||||
- People enjoy clicking on images.
|
||||
- Use this as much as possible wherever possible. I.E. for things like
|
||||
- A trial user picking the company type they would like to trial data for
|
||||
- Input fields should be sized to reflect the amount of data required to be entered in them
|
||||
- This helps the user understand what is required of them
|
||||
- ZIP code or house number should be much shorter than an address line for example
|
||||
- Do not rely on colour alone to communicate
|
||||
- 1 in 12 men have some degree of colour blindness
|
||||
- Ensure entire forms can be navigated using the tab key.
|
||||
- Test the form in low and bright light situations on a mobile device outdoors and desktop
|
||||
- Enable browser autofill with contextual tags
|
||||
- Not exactly sure what this means in practice but it sounds good
|
||||
- Use visual cues and icons, brains process visual cues way faster than text alone
|
||||
- Don't ask for a password twice, use a eyeball icon to reveal text instead like keepass does
|
||||
- Mobile should be at least 16px high text / desktop can be 14px
|
||||
|
||||
|
||||
- FRONT END FRAMEWORK
|
||||
- https://stackshare.io/stacks (interesting tool to see what other companies use in their stacks)
|
||||
- https://semantic-ui.com/
|
||||
- Vue.js https://vuejs.org/v2/guide/comparison.html
|
||||
- JS IN HTML via directives (kind of like Angular)
|
||||
- State management library if required: https://github.com/vuejs/vuex
|
||||
- Similar to redux but different
|
||||
- Module for VS Code!! https://vuejs.github.io/vetur/
|
||||
|
||||
- PROS:
|
||||
- GUIDE: https://vuejs.org/v2/guide/
|
||||
- Simpler to code than React "Vue has the most gentle learning curve of all js frameworks I have tried"
|
||||
- Single file components, all aspects of a component are in the same file (css, js, html)
|
||||
- UI LIBRARY: http://element.eleme.io/#/en-US
|
||||
- Everyone keeps claiming it's more productive
|
||||
- Comes with a databinding and MVC model built in
|
||||
- CLI project generator
|
||||
- Has official routing solution and state management solutions
|
||||
- They are starting to work on a native library like react native (not there yet though and maybe I don't care about that so much)
|
||||
- Getting things done over "purity"
|
||||
- http://pixeljets.com/blog/why-we-chose-vuejs-over-react/
|
||||
- Working with html forms is a breeze in Vue. This is where two-way binding shines.
|
||||
- Vue is much simpler than AngularJS, both in terms of API and design. Learning enough to build non-trivial applications typically takes less than a day, which is not true for AngularJS
|
||||
- CONS:
|
||||
- Less answers on stackoverflow than React (for example)
|
||||
- Vue on the other hand only supports IE9+ (not sure if this is a con or not)
|
||||
- Doesn't have a major corporation behind it like React or Angular
|
||||
- (2016)runtime errors in templates are still a weak point of Vue - exception stacktraces in a lot of times are not useful and are leading into Vue.js internal methods
|
||||
- React.js
|
||||
- HTML in JS
|
||||
- PROS:
|
||||
- Very widely used, tons of resources
|
||||
- Works with huge apps
|
||||
- Can be compiled to native apps (somehow, though Vue is working on it)
|
||||
- CONS:
|
||||
- Requires a good grasp of javascript
|
||||
- Harder to code
|
||||
- Requires a *TON* of add-on libraries as it only deals with the view part
|
||||
- "PURITY" over getting things DONE
|
||||
- Very nitpicky and fuckery prone just to do things the official way, slower to get business objectives accomplished
|
||||
- Ember
|
||||
- PROS:
|
||||
- Requires less knowledge of javascript
|
||||
- Comprehensive includes all bits
|
||||
- Suited to small teams
|
||||
- CONS:
|
||||
- Angular
|
||||
- PROS:
|
||||
- Google and Microsoft supported
|
||||
- Supposed to be good for someone coming from C# (typescript)
|
||||
- CONS:
|
||||
- Requires a *lot* of learning to use
|
||||
- Typescript
|
||||
- Angular directives and ways of doing things which are peculiar to it
|
||||
- Possibly slower than others to render
|
||||
|
||||
|
||||
- ARCHITECTURE / TECHNOLOGY STACK
|
||||
- Electron hosted desktop app like vs code or Slack:
|
||||
- What is the advantage of Electron hosted app vs just a plain html 5 app? (nothing)
|
||||
- https://slack.com/downloads/windows
|
||||
- https://blog.bridge.net/widgetoko-a-node-js-and-electron-application-written-in-c-1a2be480e4f9
|
||||
|
||||
|
||||
|
||||
- PERFORMANCE: Do not send one byte extra that is not needed at the client
|
||||
- Not even a single space,
|
||||
- especially not extra libraries or unminified code or cases
|
||||
- ICONS and webfonts should have only what is needed, nothing more.
|
||||
- ??USING A CDN??
|
||||
- VERSIONING STATIC RESOURCES
|
||||
- Use Gulp, process with hash *in filename* not as a query string (better supported by intermediate caching or proxy servers)
|
||||
- https://docs.microsoft.com/en-us/aspnet/core/client-side/using-gulp
|
||||
- https://code.visualstudio.com/docs/editor/tasks
|
||||
- https://hackernoon.com/how-to-automate-all-the-things-with-gulp-b21a3fc96885
|
||||
- https://github.com/sindresorhus/gulp-rev
|
||||
- https://github.com/jamesknelson/gulp-rev-replace
|
||||
- FORM VALIDATION:
|
||||
- https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Form_validation
|
||||
- ?? framework for complex UI required or plain old javascript? (imagine a workorder or PO)
|
||||
- Need a lot of shit on forms, maybe a framework is the way to go:
|
||||
- VALIDATION / DIRTY CHECK
|
||||
- AJAX FEEDBACK
|
||||
- ??
|
||||
|
||||
|
||||
- ?? Funky graphs
|
||||
- ?? Markdown
|
||||
- Generate html pages from Markdown docs: https://github.com/Knagis/CommonMark.NET
|
||||
- Markdown UI editor I haven't evaluated yet: https://github.com/nhnent/tui.editor
|
||||
|
||||
|
||||
- ?? TESTING
|
||||
- ??Automated UI testing in browser.
|
||||
- To catch browser changes that break functionality.
|
||||
- Get a quick tool overview.
|
||||
- Also can it use diff. browsers and devices?
|
||||
|
||||
|
||||
|
||||
DIGITAL OCEAN DROPLET REPORT RENDERING TESTING
|
||||
vbeta 8.0-b0.7 2021-12-28
|
||||
WHAT IS THE MAXIMUM wo can print at each gb before swapping occurs and how long does it take
|
||||
*** NOTE NO SWAP FILE FOR THESE TESTS AS DIDN'T KNOW IT WAS NOT SET UP ***
|
||||
|
||||
Basic - Premium AMD Shared CPU 1 vCPU 1 GB 25 GB 1 TB $6/mo
|
||||
250wo dispatch report, 33s <---this is it, the max without any swap file, 275 times out forever
|
||||
Basic - Premium AMD Shared CPU 1 vCPU 2 GB 25 GB 2 TB $12/mo
|
||||
275, 46s
|
||||
300, 50s
|
||||
400, 54s
|
||||
600, 1m 17s
|
||||
1000, 2m 26s (very briefly dipped into swap but only for fractions of a second about 5 times, kept freeing back up again, probably not enough to affect speed)
|
||||
1500, abandoned at 7m 16s (swap city, very slow swapping in an out a lot but no crashing)
|
||||
1250, abandoned at 5m (swap city later on but not at first during chrome render, no crash cancelled cleanly)
|
||||
1100, it stopped at 2m 53s with timeout dialog but was set to 15m?? WTF, brief swap, expected it to work
|
||||
1000, abandoned at 5m (swap city unlike earlier 1000 run, no idea why)
|
||||
800, 2m 6s no swap
|
||||
900, it stopped at 2m 9s with timeout dialog but set to 15m?? da fuck?
|
||||
weird error at server, put in server todo below to look into
|
||||
Basic - Premium AMD Shared CPU 2 vCPUs 2 GB 25 GB 3 TB $18/mo $0.027/hr
|
||||
(note only diff from above is more cpu, just a test to see if it's actually using them to speed up processing, and check limits)
|
||||
800,1m 51s swapped very briefly, cpu showed 130% for chrome process, so maybe chrome using more than one cpu??
|
||||
800, just ran again, swapped like made and abandoned at 4m WTF? Leak?
|
||||
trying 200 over and over as a leak test
|
||||
200, 34s, 314 pages
|
||||
'' same 785 free ram before
|
||||
'' 30s, 757 free ram before
|
||||
'' 36s, 314 pgs 780 free ram before
|
||||
Basic - Premium AMD Shared CPU 2 vCPUs 4 GB 25 GB 4 TB $24/mo $0.036/hr
|
||||
200, 39s, 314 pages
|
||||
200, 41s, 314 pages
|
||||
200, 33s, 314 pages
|
||||
1000, 2m 33s 1610 pages (easy peasy, no swap or even low)
|
||||
1000, 2m 28s 1610 pages
|
||||
1803, cancelled at 6m was swapping hard kswapd0 at 99% nothing happening
|
||||
1500, 3m 28s 2404 pages (no swap)
|
||||
Basic - Premium AMD Shared CPU 4 vCPUs 8 GB 25 GB 5 TB $48/mo
|
||||
1500, 3m 13s 2404 pages (no swap)
|
||||
1803, 3m 37s 2889 pages (holy shit that's a lot) FIRST run that could handle all without bombing
|
||||
200, 39s, 314 pages
|
||||
---------- WITH 4GB SWAP FILE ENABLED ------
|
||||
https://www.digitalocean.com/community/tutorials/how-to-add-swap-space-on-ubuntu-20-04
|
||||
Basic - Premium AMD Shared CPU 1 vCPU 1 GB 25 GB 1 TB $6/mo
|
||||
300, 1m 3s, 475 pages (FUCKING WORKS!!!!)
|
||||
1000, 3m 33s 1610 pages (FUCK YEAH!)
|
||||
1800 timed out at 15 min but no crash
|
||||
|
||||
Testing windev beta 0.8 after fixing double render due to style issue
|
||||
1000 debug run 4m 41s 1556 pages
|
||||
1000 release run 3m 26s 1556 pages
|
||||
|
||||
|
||||
################################################################
|
||||
@@ -1,15 +0,0 @@
|
||||
# Security checks and tools
|
||||
|
||||
|
||||
## NPM
|
||||
https://snyk.io/blog/ten-npm-security-best-practices/
|
||||
https://docs.npmjs.com/cli/v8/commands/npm-audit
|
||||
|
||||
npm doctor
|
||||
npm audit
|
||||
|
||||
## Nuget
|
||||
|
||||
https://docs.microsoft.com/en-us/nuget/concepts/security-best-practices
|
||||
dotnet list package --deprecated
|
||||
dotnet list package --vulnerable
|
||||
@@ -1,7 +1,9 @@
|
||||
TODO: consolidate, delete or retain and move these items into how-to's in rockfish or a new how-to.md doc here in devdocs
|
||||
|
||||
# Raven solutions
|
||||
*Solutions, tools and techniques to accomplish goals from research*
|
||||
|
||||
“Do the simplest thing that will work.”
|
||||
|
||||
|
||||
|
||||
## HOW TO SCREENSHOTS in manual pages
|
||||
@@ -9,249 +11,9 @@ use chrome, zoom in 150% if possible
|
||||
Take screenshots as narrow as possible.
|
||||
If form is too long just take multiple vertically scrolling with whitespace in between, in manual it just looks like a single image
|
||||
|
||||
|
||||
## Middleware docs
|
||||
- https://docs.microsoft.com/en-us/aspnet/core/fundamentals/middleware/?tabs=aspnetcore2x
|
||||
|
||||
## API FEATURES
|
||||
- Ability to set whole api to read only mode by administration or by code like backup routines
|
||||
|
||||
### Biz object TAGGER / MARKER INTERFACE or ATTRIBUTES (ITaggable, IAttachable etc etc)
|
||||
- Apparently should use attribute not interfaces: https://stackoverflow.com/questions/2086451/compelling-reasons-to-use-marker-interfaces-instead-of-attributes
|
||||
- https://docs.microsoft.com/en-us/dotnet/standard/attributes/writing-custom-attributes
|
||||
- But if I do use interfaces or need to work with them in future then:
|
||||
- Map all objects on boot: https://garywoodfine.com/get-c-classes-implementing-interface/
|
||||
- It's called a tagging interface: https://en.wikipedia.org/wiki/Marker_interface_pattern
|
||||
- https://stackoverflow.com/questions/15138924/c-sharp-how-to-determine-if-a-type-implements-a-given-interface
|
||||
|
||||
|
||||
|
||||
## AUTOMATIC JOB SCHEDULER / RUNNER
|
||||
- jobs in background required for auto backup, mailing, notifications
|
||||
- https://docs.microsoft.com/en-us/dotnet/standard/microservices-architecture/multi-container-microservice-net-applications/background-tasks-with-ihostedservice
|
||||
|
||||
- Probably don't need a full fledged scheduler because the above should work, but just in case here are some:
|
||||
- Fluent Scheduler looks simpler than hangfire, supports .net core
|
||||
- https://github.com/fluentscheduler/FluentScheduler
|
||||
- Chroniton looks super basic
|
||||
- https://github.com/leosperry/Chroniton/wiki/Example-ASP.NET-Core
|
||||
|
||||
|
||||
## VALIDATION / BUSINESS RULES (FRONT AND BACK)
|
||||
- To run in both places looks like JSON schema is the way to go, it can be stored independent and validated at both ends
|
||||
- It's a mature standard and is platform agnostic
|
||||
- Tutorial from AJV guy: https://code.tutsplus.com/tutorials/validating-data-with-json-schema-part-1--cms-25343
|
||||
- https://github.com/RSuter/NJsonSchema This generates and validates schema in .net world and is open source MIT license
|
||||
- https://github.com/epoberezkin/ajv This is seemingly the gold standard for javascript based
|
||||
- Lesser things looked at:
|
||||
- https://github.com/cachecontrol/json-rules-engine 128 stars might be adaptable
|
||||
- https://github.com/rsamec/business-rules-engine //this one is for javascript and kind of limited but gives some good ideas
|
||||
|
||||
|
||||
## RESOURCE ACCESS LAYER (DATABASE)
|
||||
- DATABASE
|
||||
- Support Postgresql only out of the box, consider other db's later
|
||||
- CONCURRENCY IS BUILT INTO EFCORE: https://docs.microsoft.com/en-us/ef/core/saving/concurrency
|
||||
- Transactions are also built in by default as the save changes is the only point that stuff actually gets written to the db in most cases
|
||||
- MUST TEST CONCURRENCY AND TRANSACTIONS FAIL
|
||||
- CONTAINERIZED DB's
|
||||
- For development, I don't think there's anything better for databases, it beats manual setup, vagrant boxes, and shared development servers by a long shot. I feel that educating everyone on your team in how to use it is well worth the investment. docker-compose makes setting up even a fairly complicated development environment a breeze.
|
||||
- BACKUP AND RESTORE
|
||||
- DISCOURSE METHOD
|
||||
- I like it because it handles various scenarios and results in a nice SQL command file that rebuilds the whole db, not some cryptic binary format
|
||||
- Can set all api to read only mode, then dumps the db using a db command, then zips it and offers it for download
|
||||
- Backup process
|
||||
- pause the sidekiq background process worker
|
||||
- Can optionally set the api to read only mode (interesting idea)
|
||||
- dumps the data to a file in sql command format for maximum compatibility (even with other db server types puportedly)
|
||||
- Archives it
|
||||
- presents it in the UI for download
|
||||
- unpause the background worker
|
||||
- Restore process
|
||||
- This one is interesting, PGSQL has a "schema" which is a way of partitioning a database to in effect have a separate set of tables in the same db
|
||||
- They move the "public" production "schema" to a "backup" schema (effectively moving it but keeping it in the db)
|
||||
- They restore to a separate interim "restore" "schema" then they move all the tables in the restore schema to the production "public" schema (one by one in a loop)
|
||||
- I guess this way it's reversible if there is an issue but I don't see code to handle any issues
|
||||
- https://github.com/discourse/discourse/tree/master/lib/backup_restore
|
||||
- Also seems to have some capacity to send it to an AWS bitbucket or some thing, maybe an online integration with dropbox or other would be nice
|
||||
MORE DOCKER AND DISCOURSE STUFF
|
||||
https://github.com/discourse/discourse_docker
|
||||
|
||||
|
||||
|
||||
## ARCHITECTURE / NFR
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
### Subdomains pointing to differetn droplets tutorial
|
||||
- https://www.digitalocean.com/community/tutorials/how-to-set-up-and-test-dns-subdomains-with-digitalocean-s-dns-panel
|
||||
|
||||
### Other stuff
|
||||
This section contains the architectural plans for all aspects of Raven driven by goals and research
|
||||
https://en.wikipedia.org/wiki/Non-functional_requirement
|
||||
|
||||
- ARchitecture reference resources:
|
||||
- https://stackoverflow.com/questions/5049363/difference-between-repository-and-service-layer
|
||||
|
||||
- ARCHITECTURE LAYERS
|
||||
- CLIENT
|
||||
- HTML 5 SPA
|
||||
- WEB API LAYER
|
||||
- REPOSITORY LAYER
|
||||
- BUSINESS LAYER (AKA DOMAIN LAYER)
|
||||
- The Business Layer is the place where all the business/domain logic, i.e. rules that are particular to the problem
|
||||
that the application has been built to handle, lives. This might be salary calculations, data analysis modelling,
|
||||
or workflow such as passing a order through different stages.
|
||||
- I'm using this: https://www.thereformedprogrammer.net/a-library-to-run-your-business-logic-when-using-entity-framework-core/
|
||||
- and this is the repo: https://github.com/JonPSmith/EfCore.GenericBizRunner
|
||||
|
||||
- DATA ACCESS LAYER (EF CORE)
|
||||
- EF CORE multiple database stuff
|
||||
- Migrations with different providers: https://stackoverflow.com/questions/42819371/ef-core-multiple-migration-sets
|
||||
- DATABASE
|
||||
|
||||
|
||||
|
||||
|
||||
- .NET CORE DEPLOYMENT
|
||||
- Basically just get the files on to the system in one case or need .net installed as a pre-requisite then drop the files on
|
||||
- https://docs.microsoft.com/en-us/dotnet/core/deploying/deploy-with-cli
|
||||
- https://docs.microsoft.com/en-us/dotnet/core/deploying/
|
||||
- KESTREL alone
|
||||
- Kestrel alone can be used but it won't work if need to share a port with something else and differentiate by host header
|
||||
- in case of host header issue can run NGinx in front or IIS
|
||||
- More to come here once we have a testable skeleton project to set up
|
||||
- STATIC FILE CACHING
|
||||
- https://andrewlock.net/adding-cache-control-headers-to-static-files-in-asp-net-core/
|
||||
|
||||
- Asp.net Core 2.0 application stack
|
||||
- .net core WEBAPI project
|
||||
- Swagger for documentation
|
||||
|
||||
- REST best practices
|
||||
- Excellent reference guide here: https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md
|
||||
- URLS: A good api url: https://api.ayanova.com/v1.0/customer/22
|
||||
- Keep length under 2000 characters for maximum client compatibility
|
||||
- concurrency (The ETag response-header field provides the current value of the entity tag for the requested variant. Used with If-Match, If-None-Match and If-Range to implement optimistic concurrency control.)
|
||||
- JSON property names SHOULD be camelCased.
|
||||
- There are specific Date, time, Duration, Interval formats that should be used (https://github.com/Microsoft/api-guidelines/blob/vNext/Guidelines.md#113-json-serialization-of-dates-and-times)
|
||||
- Error response: The error response MUST be a single JSON object. This object MUST have a name/value pair named "error." The value MUST be a JSON object.
|
||||
This object MUST contain name/value pairs with the names "code" and "message," and it MAY contain name/value pairs with the names "target," "details" and "innererror."
|
||||
eg: error:{code=1200,message="blah"} error:{code=1200,message="blah",target="eg property name", details="details for programmer", innererror:}
|
||||
- Versioning: this is an area I need to treat carefully, there are tools to make it easier:
|
||||
- I will use URL Path segment versioning, i.e. api/v1.0/customer/22
|
||||
- https://www.hanselman.com/blog/ASPNETCoreRESTfulWebAPIVersioningMadeEasy.aspx
|
||||
- https://github.com/Microsoft/aspnet-api-versioning/wiki
|
||||
- https://github.com/Microsoft/aspnet-api-versioning/tree/master/samples/aspnetcore/SwaggerSample
|
||||
- Push notifications (I.e. on a customer record being created or a workorder updated or...?)
|
||||
- If so there is a segment in the rest doc from microsoft that goes over it in detail
|
||||
- API THROTTLING / RATE LIMITING
|
||||
- https://github.com/stefanprodan/AspNetCoreRateLimit
|
||||
- ASYNC / BUSINESS LAYER
|
||||
- https://stackoverflow.com/questions/42276149/best-practice-for-using-async-await-in-webapi
|
||||
- https://stackoverflow.com/questions/41719661/asp-net-core-making-service-asynchronous
|
||||
- http://www.codemag.com/article/1701061 BUSINESS LAYER STUFF
|
||||
- https://github.com/RickStrahl/AlbumViewerVNext
|
||||
|
||||
## AUTOMAPPER
|
||||
- Sounds like a tool I might need, here is a good tutorial: https://dotnetcoretutorials.com/2017/09/23/using-automapper-asp-net-core/
|
||||
|
||||
|
||||
|
||||
## TESTING
|
||||
- TESTING performance / load / resiliency testing
|
||||
- https://docs.microsoft.com/en-us/aspnet/core/testing/
|
||||
- Spend the time to generate realistic production level data in large quantity for testing
|
||||
- Do not do any integration testing without realistic data
|
||||
- Data generation for testing could be re-used for trial data generation for customer evaluation purposes
|
||||
- Test with production sized data !!!! (did not do this properly when doing AyaNova originally)
|
||||
- TOOLS
|
||||
- xUnit https://xunit.github.io/
|
||||
- Mocking, different test runners here: http://asp.net-hacker.rocks/2017/03/31/unit-testing-with-dotnetcore.html
|
||||
- GENFU - tries to automatically fill objects which sounds dicey https://github.com/MisterJames/GenFu/
|
||||
- https://github.com/bchavez/Bogus This is a .net port of faker.js and as such probably a good choice
|
||||
- Testing with a docker container (old but interesting) https://devblog.xero.com/getting-started-with-running-unit-tests-in-net-core-with-xunit-and-docker-e92915e4075c
|
||||
## LOGGING
|
||||
- Watch out, logging can be a huge performance drain, test with logs on and off to see what and if necessary replace logging class with something faster.
|
||||
|
||||
|
||||
|
||||
|
||||
## REFERENCE RESOURCES
|
||||
|
||||
|
||||
- ASP.NET CORE FUNDAMENTALS DOCS
|
||||
- Everything to do with asp.net core fundamental coding aspects
|
||||
- https://docs.microsoft.com/en-us/aspnet/core/fundamentals/?tabs=aspnetcore2x
|
||||
|
||||
- AWESOME .NET CORE
|
||||
- Has a list of solutions for .net core project needs
|
||||
- https://github.com/thangchung/awesome-dotnet-core
|
||||
|
||||
|
||||
- THIS TYPE OF PROJECT REFERENCE CODE
|
||||
- NICE DIAGRAM OF OUR ARCHITECTURE FOR RAVEN: http://www.dotnetcurry.com/entityframework/1348/ef-core-web-api-crud-operations
|
||||
- https://github.com/RickStrahl/AlbumViewerVNext
|
||||
- This is a good one, it uses .net core, runs on multiple platforms, has an angular front end, is from a seasoned practical developer etc etc
|
||||
- https://github.com/dodyg/practical-aspnetcore
|
||||
- .net samples and tutorials on official docs page
|
||||
- https://docs.microsoft.com/en-us/dotnet/samples-and-tutorials/
|
||||
- https://samueleresca.net/2017/02/implementing-solid-data-access-layers-using-asp-net-core/
|
||||
- AUTOMAPPER: https://github.com/AutoMapper/AutoMapper/wiki/Getting-started
|
||||
- https://www.infragistics.com/community/blogs/dhananjay_kumar/archive/2016/03/07/how-to-implement-the-repository-pattern-in-asp-net-mvc-application.aspx
|
||||
|
||||
|
||||
- ORCHARD
|
||||
- Almost the perfect reference application, they are doing what I will be doing but for a CMS
|
||||
- https://github.com/OrchardCMS/OrchardCore
|
||||
- This samples link actually contains a lot of useful info as well like multi-tenanting stuff etc
|
||||
- https://github.com/OrchardCMS/OrchardCore.Samples
|
||||
|
||||
- DISCOURSE
|
||||
- this app is kind of what raven will become in many ways architecturally,
|
||||
- It's a message board that is modern uses Postgresql, digital ocean docker container, mobile and desktop browser UI
|
||||
- It's open source so plunder it's source code here:
|
||||
- https://github.com/discourse/discourse
|
||||
- https://github.com/discourse/discourse_docker/blob/master/samples/standalone.yml
|
||||
|
||||
|
||||
|
||||
- DOCKER CONTAINERIZED APP BUILD GUIDE
|
||||
- This guide has a *lot* of good info in it that is right up my alley:
|
||||
- https://www.red-gate.com/simple-talk/sysadmin/containerization/overcoming-challenges-microservices-docker-containerisation/?utm_source=simpletalk&utm_medium=pubemail&utm_content=20170926-slota5&utm_term=simpletalkmain
|
||||
|
||||
- FRONT END DASHBOARD
|
||||
|
||||
- Cool dashboard with graphs and shit: https://github.com/tabler/tabler?utm_source=DigitalOcean_Newsletter
|
||||
|
||||
## HELP AND DOCUMENTATION RESOURCES
|
||||
- ONLINE HELP FOR RAVEN CUSTOMERS
|
||||
- The Jenkins help page has a really good layout for help with Guided Tour, User Handbook, Resources and Recent Tutorials on left panel
|
||||
- https://jenkins.io/doc/pipeline/tour/hello-world/
|
||||
|
||||
|
||||
## GRAPHICS / ARTWORK UI FANCIFICATION RESOURCES
|
||||
- Free for use background image generator that looks really nice and soothing: https://coolbackgrounds.io/
|
||||
- Free for any use even without attribution stock photography: https://unsplash.com/
|
||||
|
||||
|
||||
## ASCII ART
|
||||
//http://www.patorjk.com/software/taag/#p=display&f=ANSI%20Shadow&t=PM
|
||||
|
||||
## Time zone stuff
|
||||
//play with any time zone with codes
|
||||
http://www.timezoneconverter.com/cgi-bin/zoneinfo
|
||||
|
||||
//list of time zone offsets
|
||||
https://en.wikipedia.org/wiki/List_of_UTC_time_offsets
|
||||
|
||||
Good test time zones:
|
||||
America/St_Johns - because it has a fractional hour difference
|
||||
America/New_York
|
||||
America/Los_Angeles
|
||||
|
||||
|
||||
## How to make a postgres portable from binaries
|
||||
download latest binaries: https://www.enterprisedb.com/download-postgresql-binaries
|
||||
|
||||
@@ -9,6 +9,8 @@ TODO: WEBSITE TASKs
|
||||
|
||||
|
||||
https://www.postgresql.org/about/news/postgresql-15-released-2526/
|
||||
even if not recommending it to users need to test against it as no doubt some will just install and also maybe hte script we link to in install
|
||||
autoamticaly installs this now?
|
||||
|
||||
- Subscribers need to know taht their server will be rebooted daily if and when security updates come in
|
||||
need a system to handle that or a day of the week to handle that, maybe a preferred time or ...?
|
||||
@@ -20,6 +22,10 @@ https://www.postgresql.org/about/news/postgresql-15-released-2526/
|
||||
#####################################################################
|
||||
TODO:Clean up this document from here down and re-organize / prioritize
|
||||
|
||||
todo: clean up solutions.txt and research.txt and move into a consolidated coding focused how-to.md doc
|
||||
|
||||
TODO: Move all items here into cases, basically clean out entirely this document so it's more like a current todo only
|
||||
|
||||
- subscription licensing and terms, I have some links somewhere to good examples
|
||||
CRITICAL! Needs to be in place with wording on reasonable use etc to protect us etc
|
||||
- subscription process info to request how to go about it, improvements to manual process
|
||||
@@ -111,6 +117,23 @@ todo: research stuff below, then website stuff and move on
|
||||
L8ER >>>>>>>>>>>>>>>>>>>>
|
||||
|
||||
|
||||
todo: Ongoing, document this as a process to regularly follow for back and front end, make a case then into howto I guess
|
||||
MUST be done before next major dependencies update
|
||||
# Security checks and tools
|
||||
|
||||
|
||||
## NPM
|
||||
https://snyk.io/blog/ten-npm-security-best-practices/
|
||||
https://docs.npmjs.com/cli/v8/commands/npm-audit
|
||||
|
||||
npm doctor
|
||||
npm audit
|
||||
|
||||
## Nuget
|
||||
|
||||
https://docs.microsoft.com/en-us/nuget/concepts/security-best-practices
|
||||
dotnet list package --deprecated
|
||||
dotnet list package --vulnerable
|
||||
|
||||
|
||||
|
||||
@@ -588,7 +611,10 @@ For example head office and many more.
|
||||
todo: Unit help page doesnt have a screenshot of the menu, maybe others are also missing this, it's important when supporting people
|
||||
todo: docs add view on map an image of a map to snazz it up.
|
||||
|
||||
todo: foucsed docs about common tasks like a getting started or how to section not just a ui help
|
||||
todo: "Guided tours" foucsed docs about common tasks like a getting started or how to section not just a ui help
|
||||
This should be a tour that leads a user through doing a task in the evaluation data and also it should include screenshots showing what they would see
|
||||
so they don't need to actually do it, they can just view it.
|
||||
|
||||
the old manual had guidance on inventory, how to use it how to start it etc
|
||||
go through old manual find candidates for how to's similar to how fastmail help has guidance on specific things that are FAQ's basically / tutorials
|
||||
or this might be the original idea of a guided tour feature that walks through stuff in the actual UI?
|
||||
@@ -601,6 +627,11 @@ todo: server metrics ops-metrics no screenshots??
|
||||
|
||||
todo: log level page https://ayanova.com/docs/ops-log/#log-level doesn't mention config.json like as even a thing like it does with other config settings pages
|
||||
|
||||
todo: Is th8is documented anywhere?:
|
||||
- Support the latest browser and the one before it of every major browser like gitlab does:
|
||||
- Supported web browsers, We support the current and the previous major release of Firefox, Chrome/Chromium, Safari and Microsoft browsers (Microsoft Edge and Internet Explorer 11).
|
||||
- Each time a new browser version is released, we begin supporting that version and stop supporting the third most recent version.
|
||||
|
||||
|
||||
|
||||
## MIGRATION ITEMS
|
||||
|
||||
@@ -1,3 +1,6 @@
|
||||
|
||||
TODO: consolidate, delete or retain and move these items into how-to's in rockfish or a new how-to.md doc here in devdocs
|
||||
|
||||
## FRONT END DEV TOOLS
|
||||
|
||||
LOCALIZATION = MICROSOFT RESOURCE
|
||||
|
||||
Reference in New Issue
Block a user