13
Jan
2017
How to tackle long term problems as if they were short term ones
History / Edit / PDF / EPUB / BIB / 1 min read (~54 words)- It's easy to do things such as checking your email or going on reddit as they are very short term tasks (can be started and completed in less than 10s).
- Long term tasks on the other hand requires you to save and restore your mental state every time you transition to and from them.
- Build a list of task/items
List everything that you want to get out of your head. The goal here is to make explicit as much as possible. - Deconstruct tasks into their pre-requisites and follow-up tasks
There are a couple of important things to consider when one wants to prioritize their task list. One is that even if a task is at the top of the list, it might not be possible to do it until its dependencies are fulfilled. This in turn means that all dependencies will have a superior priority to this task automatically.
However, it frequently happens that what we consider dependencies can in fact be delayed or temporarily replaced by another solution which takes less time to implement or costs less (or for whatever other reason can replace the original dependency). - Split tasks into 2 groups (and repeat this process)
The idea here is to quickly filter out as many tasks as possible. As you may have noticed, I have not specified the filtering predicate. It is up to you to filter out your tasks such that you will have the least amount to filter at once. Examples of predicates you could use are "will/will not do", "want/do not want", "need/do not need", "like/do not like" and so on. - Prioritize the tasks that will have to be done
After a certain number of iterations of the previous step, you should arrive at a point where the items you have all need to be done, but you do not know in which order you have to do them (or want to do them).
Urgent/Important
Not Urgent/Important
Urgent/Not Important
Not Urgent/Not Important
- What you feel like reading
- Reading dependencies
- ROI evaluation
- Karlsson, Joachim, Claes Wohlin, and Björn Regnell. "An evaluation of methods for prioritizing software requirements." Information and Software Technology 39.14 (1998): 939-947.
- Karlsson, Joachim, Stefan Olsson, and Kevin Ryan. "Improved practical support for large-scale requirements prioritising." Requirements Engineering 2.1 (1997): 51-60.
- Ahl, Viggo. "An experimental comparison of five prioritization methods: investigating ease of use, accuracy and scalability." (2005).
- Gill, Nasib Singh. "A Comparison among Various Techniques to Prioritize the Requirements." International Journal of Computer Science and Management Studies (IJCSMS) www. ijcsms. com 1.12: 601-607.
- http://www.gwern.net/Resorter
- Max magnification
- Lighting
- Megapixels
- https://www.amazon.ca/XCSOURCE-20X-800X-Microscope-Endoscope-Magnifier/dp/B00N4K22OA/
- https://www.amazon.ca/JZHY-Microscope-Magnification-Digital-Endoscope/dp/B01DIRJ6PQ/
- Max magnification
- Included digital camera
- Megapixels
- Comes with prepared slides
- https://www.amazon.ca/AmScope-B120B-E-Magnification-Illumination-Double-Layer/dp/B00A15CUMU/
- https://www.amazon.ca/AmScope-B120B-CM-PS100-Magnification-Illumination-Double-Layer/dp/B00A9ALEGK/
- https://www.amazon.ca/AmScope-B120B-10M-Magnification-Illumination-Double-Layer/dp/B009VUP2AI/
- https://cartalyst.com/
- 75$/3 months
- 25$/month
- Subscription-based model
- Some development must be done in order to protect the software against forbidden use (no subscription)
- May require a "call-to-home" (Internet connection) to verify the subscription is still valid
- Might be easily countered by firewalling the application
- We may allow it to go unchecked for 1-X days until we tell the user to connect, but that is bad user experience
- Might be easily countered by firewalling the application
- Similar to subscription based, but on a per use basis
- Code is freely available
- Makes it more difficult to live on producing the software
- ($X*0.2)/user/year in support fees
- Fee per request
- X$/user (one time fee)
- ($X*0.2)/user/year in support fees
- Tools are never shared with the outside world
- Develop tools to use on a per-project basis, where clients spent 5k$+ on a single pass
- Tools are never shared with the outside world
- Encapsulate the application within a .phar
- Use obfuscation (can only obfuscate variables inside function/methods as anything else must remain with the same name in order to allow for dynamically called methods (or simply do not support such code))
- Must not make it easy to extract the original source code
- Must checksum itself for modification
- Should prevent usage by sharing a single license (TBD?)
- Should not be possible to reuse a trial forever in a VM
- Relying on opcode (to act as a binary) probably implies you are dependent on the php version used. Furthermore, it also means that the extension must be available and enabled for the code to work
- Given the current implementation of opcache, the cache cannot be reused on other machines as it contains the system ID as part of an opcache file header
- OPCACHE
- System ID
-
Timestamp
- Checksum
-> zend_accel_load_script (persistent_script, from_memory)
- Replace classes methods with (generated) traits that contain one or many of the classes method
- Compression/optimization by creating variables
- Even with obfuscation, PSR0/4 based code is too easy to distinguish (no reason to obfuscate libraries)
- Find some way to transform the original source such that it is in symbiosis with a client identifier (and thus cannot be removed)
- See one-way function
- Replace variables within functions with obfuscated names
- Concatenate all files into a single file (or bundle of files)
- Pre-process require/include, or do not allow their use (as the files will not be available)
- Randomize file order
- Scramble method order
- Inject junk code
- Insert junk code with encrypted user identification
- Generate a differently scrambled version per download/user