SINGAPORE — Could a four-day work week be the new norm? Nearly a third of Singapore workers (32 per cent) surveyed expect that to be the case in the next five years, a new poll has found.

1 in 3 S'pore workers expect 4-day work weeks to be a norm, but experts think there's still a long way to go - TODAY

&quot;Besides that, it’s getting WhatsApp messages at 11 pm, and emails at 3 am. Do people not sleep?!&quot; he wrote

Foreigner asks how Singaporean work culture came to be; very last minute, working overtime, unrealistic deadlines - Singapore News

BRUSSELS: Ukraine on Thursday (Apr 4) supported NATO chief Jens Stoltenberg&#x27;s idea of the alliance providing long-term support to Kyiv, but said the measure would have &quot;zero chance&quot; without obligatory contributions

Ukraine says NATO funding will only work if mandatory contributions - CNA

The latest Journal coverage on relationships, travel, cars, careers and the workplace.

The Big Work Lie: Being Indispensable Will Save Your Job

m-work

mwork

Deep Neural Network for Sea Surface Temperature Prediction: References

সমুদ্র পৃষ্ঠের তাপমাত্রা পূর্বাভাসের জন্য গভীর নিউরাল নেটওয়ার্ক: তথ্যসূত্র

Tiefes neuronales Netzwerk zur Vorhersage der Meeresoberflächentemperatur: Referenzen

Red neuronal profunda para la predicción de la temperatura de la superficie del mar: referencias

Réseau neuronal profond pour la prévision de la température de la surface de la mer : références

समुद्र सतह तापमान पूर्वानुमान के लिए डीप न्यूरल नेटवर्क: संदर्भ

海面温度予測のためのディープニューラルネットワーク: 参考文献

해수면 온도 예측을 위한 심층 신경망: 참고자료

Rede Neural Profunda para Previsão da Temperatura da Superfície do Mar: Referências

Глубокая нейронная сеть для прогнозирования температуры поверхности моря: ссылки

Deniz Yüzeyi Sıcaklığı Tahmini için Derin Sinir Ağı: Referanslar

Mạng lưới thần kinh sâu để dự đoán nhiệt độ bề mặt biển: Tài liệu tham khảo

用于海面温度预测的深度神经网络：参考文献

Authors:
(1) Vahid Majdinasab, Department of Computer and Software Engineering Polytechnique Montreal, Canada;
(2) Michael Joshua Bishop, School of Mathematical and Computational Sciences Massey University, New Zealand;
(3) Shawn Rasheed, Information & Communication Technology Group UCOL - Te Pukenga, New Zealand;
(4) Arghavan Moradidakhel, Department of Computer and Software Engineering Polytechnique Montreal, Canada;
(5) Amjed Tahir, School of Mathematical and Computational Sciences Massey University, New Zealand;
(6) Foutse Khomh, Department of Computer and Software Engineering Polytechnique Montreal, Canada. Table of Links Abstract and Introduction Original Study Replication Scope and Methodology Results Discussion Related Work Conclusion, Acknowledgments, and References VII. CONCLUSION This study aimed to replicate the work of Pearce et al. [14], which uncovered several security weaknesses in code suggestions generated by GitHub Copilot. The replication study focused on Python-generated code and used the same baseline of weaknesses (MITRE top CWEs) to create the code generation prompts (covering a variety of weaknesses and scenarios). Following the study of [14], GitHub announced an upgrade to Copilot aimed at filtering out solutions that include top CWEs. Despite the current improvements from Copilot, our results demonstrate that Copilot continues to propose vulnerable suggestions for various scenarios. Particularly, within four of the CWEs tested (CWE-78 (OS Command Injection), CWE-434 (Unrestricted File Upload), CWE-306 (Missing Authentication for Critical Function), and CWE-502 (Deserialization of Untrusted Data)), Copilot’s suggestions still exhibit vulnerabilities. Our results highlight the importance for developers to continuously check the security of the code generated by such models through the implementation of rigorous security code reviews and with the use of a security analysis tool. This has been the recommendation provided by Copilot explicitly: “You are responsible for ensuring the security and quality of your code. We recommend you take the same precautions when using code generated by GitHub Copilot that you would when using any code you didn’t write yourself.” [29]. The issues associated with the security of generated code, especially from LLMs, will continue to impact the quality of code generation tools and thus might reduce the trust of developers using such tools. It is important to continue investigating such issues as both the underlying code generation models and the nature of weaknesses evolve fast. While there is some work done on Copilot’s security, little is done in terms of other code-generation tools (especially those that utilize similar LLMs). We expect those tools to face similar security challenges, which will require further investigation. VIII. ACKNOWLEDGEMENTS This work is partially supported by Massey University SREF funding, the Fonds de Recherche du Quebec (FRQ), the Canadian Institute for Advanced Research (CIFAR), and the National Science and Engineering Research Council of Canada (NSERC). REFERENCES [1] M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P. d. O. Pinto, J. Kaplan, H. Edwards, Y. Burda, N. Joseph, G. Brockman, et al., “Evaluating large language models trained on code,” arXiv preprint arXiv:2107.03374, 2021. [2] T. Dohmke, “The economic impact of the AI-powered developer lifecycle and lessons from GitHub Copilot - The GitHub Blog.” https://gith ub.blog/2023-06-27-the-economic-impact-of-the-ai-powered-developer -lifecycle-and-lessons-from-github-copilot/?ref=blog.gitguardian.com, June 2023. (Accessed on 10/10/2023). [3] S. Lertbanjongngam, B. Chinthanet, T. Ishio, R. G. Kula, P. Leelaprute, B. Manaskasemsak, A. Rungsawang, and K. Matsumoto, “An Empirical Evaluation of Competitive Programming AI: A Case Study of AlphaCode,” in Proceedings of the 16th IEEE International Workshop on Software Clones (IWSC), pp. 10–15, IEEE, 2022. [4] D. Wong, A. Kothig, and P. Lam, “Exploring the Verifiability of Code Generated by GitHub Copilot,” arXiv preprint arXiv:2209.01766, 2022. [5] A. M. Dakhel, V. Majdinasab, A. Nikanjam, F. Khomh, M. C. Desmarais, and Z. M. J. Jiang, “Github copilot AI pair programmer: Asset or liability?,” Journal of Systems and Software, vol. 203, p. 111734, 2023. [6] R. Pudari and N. A. Ernst, “From Copilot to Pilot: Towards AI Supported Software Development,” arXiv preprint arXiv:2303.04142, 2023. [7] M. L. Siddiq and J. C. Santos, “SecurityEval dataset: mining vulnerability examples to evaluate machine learning-based code generation techniques,” in Proceedings of the 1st International Workshop on Mining Software Repositories Applications for Privacy and Security (MSR4P&S), pp. 29–33, ACM, 2022. [8] J. He and M. Vechev, “Controlling large language models to generate secure and vulnerable code,” arXiv preprint arXiv:2302.05319, 2023. [9] B. Yetis¸tiren, I. Ozsoy, M. Ayerdem, and E. T ¨ uz¨ un, “Evaluating the Code ¨ Quality of AI-Assisted Code Generation Tools: An Empirical Study on GitHub Copilot, Amazon CodeWhisperer, and ChatGPT,” arXiv preprint arXiv:2304.10778, 2023. [10] O. Asare, M. Nagappan, and N. Asokan, “Is GitHub’s Copilot as bad as humans at introducing vulnerabilities in code?,” Empirical Software Engineering, vol. 28, no. 6, pp. 1–24, 2023. [11] M. Verdi, A. Sami, J. Akhondali, F. Khomh, G. Uddin, and A. K. Motlagh, “An Empirical Study of C++ Vulnerabilities in Crowd-sourced Code Examples,” IEEE Transactions on Software Engineering, vol. 48, no. 5, pp. 1497–1514, 2020. [12] T. Brown, B. Mann, N. Ryder, M. Subbiah, J. D. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell, et al., “Language models are few-shot learners,” Advances in neural information processing systems, vol. 33, pp. 1877–1901, 2020. [13] M. O. F. Rokon, R. Islam, A. Darki, E. E. Papalexakis, and M. Faloutsos, “SourceFinder: Finding malware Source-Code from publicly available repositories in GitHub,” in 23rd International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2020), pp. 149–163, 2020. [14] H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt, and R. Karri, “Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions,” in 2022 IEEE Symposium on Security and Privacy (SP), pp. 754–768, 2022. [15] Y. Fu, P. Liang, A. Tahir, Z. Li, M. Shahin, and J. Yu, “Security Weaknesses of Copilot Generated Code in GitHub,” arXiv preprint arXiv:2310.02059, 2023. [16] Y. Huang, Y. Li, W. Wu, J. Zhang, and M. R. Lyu, “Do Not Give Away My Secrets: Uncovering the Privacy Issue of Neural Code Completion Tools,” arXiv preprint arXiv:2309.07639, 2023. [17] GitGuardian, “The State of Secrets Sprawl Report 2023.” https://www. gitguardian.com/files/the-state-of-secrets-sprawl-report-2023?ref=blog .gitguardian.com, 2023. [18] The MITRE Corporation (MITRE), “CWE List Version 4.12.” https: //cwe.mitre.org/data/index.html, 2023. [19] S. Zhao, “GitHub Copilot now has a better AI model and new capabilities - The GitHub Blog.” https://github.blog/2023-02-14-github-cop ilot-now-has-a-better-ai-model-and-new-capabilities/. (Accessed on 12/11/2023). [20] R. Khoury, A. R. Avila, J. Brunelle, and B. M. Camara, “How Secure is Code Generated by ChatGPT?,” arXiv preprint arXiv:2304.09655, 2023. [21] H. Hajipour, T. Holz, L. Schonherr, and M. Fritz, “Systematically Find- ¨ ing Security Vulnerabilities in Black-Box Code Generation Models,” arXiv preprint arXiv:2302.04012, 2023. [22] O. Asare, M. Nagappan, and N. Asokan, “Is GitHub’s Copilot as bad as humans at introducing vulnerabilities in code?,” arXiv preprint arXiv:2204.04741, 2022. [23] J. Shi, Y. Liu, P. Zhou, and L. Sun, “BadGPT: Exploring Security Vulnerabilities of ChatGPT via Backdoor Attacks to InstructGPT,” arXiv preprint arXiv:2304.12298, 2023. [24] E. Derner and K. Batistic, “Beyond the Safeguards: Exploring the ˇ Security Risks of ChatGPT,” arXiv preprint arXiv:2305.08005, 2023. [25] K. R. Go, S. Soundarapandian, A. Mitra, M. Vidoni, and N. E. D. Ferreyra, “Simple stupid insecure practices and GitHub’s code search: A looming threat?,” Journal of Systems and Software, vol. 202, p. 111698, 2023. [26] N. Perry, M. Srivastava, D. Kumar, and D. Boneh, “Do users write more insecure code with AI assistants?,” arXiv preprint arXiv:2211.03622, 2022. [27] X. Huang, W. Ruan, W. Huang, G. Jin, Y. Dong, C. Wu, S. Bensalem, R. Mu, Y. Qi, X. Zhao, et al., “A Survey of Safety and Trustworthiness of Large Language Models through the Lens of Verification and Validation,” arXiv preprint arXiv:2305.11391, 2023. [28] N. Nguyen and S. Nadi, “An Empirical Evaluation of GitHub Copilot’s Code Suggestions,” in Proceedings of the 19th International Conference on Mining Software Repositories, pp. 1–5, 2022. [29] GitHub, “GitHub Copilot for Individuals.” https://docs.github.com/en/c opilot/overview-of-github-copilot/about-github-copilot-for-individuals, 2023. (Accessed on 02/11/2023). This paper is available on arxiv under CC 4.0 license. Authors: (1) Vahid Majdinasab, Department of Computer and Software Engineering Polytechnique Montreal, Canada; (2) Michael Joshua Bishop, School of Mathematical and Computational Sciences Massey University, New Zealand; (3) Shawn Rasheed, Information & Communication Technology Group UCOL - Te Pukenga, New Zealand; (4) Arghavan Moradidakhel, Department of Computer and Software Engineering Polytechnique Montreal, Canada; (5) Amjed Tahir, School of Mathematical and Computational Sciences Massey University, New Zealand; (6) Foutse Khomh, Department of Computer and Software Engineering Polytechnique Montreal, Canada. Authors: Authors: (1) Vahid Majdinasab, Department of Computer and Software Engineering Polytechnique Montreal, Canada; (2) Michael Joshua Bishop, School of Mathematical and Computational Sciences Massey University, New Zealand; (3) Shawn Rasheed, Information & Communication Technology Group UCOL - Te Pukenga, New Zealand; (4) Arghavan Moradidakhel, Department of Computer and Software Engineering Polytechnique Montreal, Canada; (5) Amjed Tahir, School of Mathematical and Computational Sciences Massey University, New Zealand; (6) Foutse Khomh, Department of Computer and Software Engineering Polytechnique Montreal, Canada. Table of Links Abstract and Introduction Abstract and Introduction Original Study Original Study Replication Scope and Methodology Replication Scope and Methodology Results Results Discussion Discussion Related Work Related Work Conclusion, Acknowledgments, and References Conclusion, Acknowledgments, and References VII. CONCLUSION This study aimed to replicate the work of Pearce et al. [14], which uncovered several security weaknesses in code suggestions generated by GitHub Copilot. The replication study focused on Python-generated code and used the same baseline of weaknesses (MITRE top CWEs) to create the code generation prompts (covering a variety of weaknesses and scenarios). Following the study of [14], GitHub announced an upgrade to Copilot aimed at filtering out solutions that include top CWEs. Despite the current improvements from Copilot, our results demonstrate that Copilot continues to propose vulnerable suggestions for various scenarios. Particularly, within four of the CWEs tested (CWE-78 (OS Command Injection), CWE-434 (Unrestricted File Upload), CWE-306 (Missing Authentication for Critical Function), and CWE-502 (Deserialization of Untrusted Data)), Copilot’s suggestions still exhibit vulnerabilities. Our results highlight the importance for developers to continuously check the security of the code generated by such models through the implementation of rigorous security code reviews and with the use of a security analysis tool. This has been the recommendation provided by Copilot explicitly: “You are responsible for ensuring the security and quality of your code. We recommend you take the same precautions when using code generated by GitHub Copilot that you would when using any code you didn’t write yourself.” [29]. “You are responsible for ensuring the security and quality of your code. We recommend you take the same precautions when using code generated by GitHub Copilot that you would when using any code you didn’t write yourself.” [29]. The issues associated with the security of generated code, especially from LLMs, will continue to impact the quality of code generation tools and thus might reduce the trust of developers using such tools. It is important to continue investigating such issues as both the underlying code generation models and the nature of weaknesses evolve fast. While there is some work done on Copilot’s security, little is done in terms of other code-generation tools (especially those that utilize similar LLMs). We expect those tools to face similar security challenges, which will require further investigation. VIII. ACKNOWLEDGEMENTS This work is partially supported by Massey University SREF funding, the Fonds de Recherche du Quebec (FRQ), the Canadian Institute for Advanced Research (CIFAR), and the National Science and Engineering Research Council of Canada (NSERC). REFERENCES [1] M. Chen, J. Tworek, H. Jun, Q. Yuan, H. P. d. O. Pinto, J. Kaplan, H. Edwards, Y. Burda, N. Joseph, G. Brockman, et al., “Evaluating large language models trained on code,” arXiv preprint arXiv:2107.03374, 2021. [2] T. Dohmke, “The economic impact of the AI-powered developer lifecycle and lessons from GitHub Copilot - The GitHub Blog.” https://gith ub.blog/2023-06-27-the-economic-impact-of-the-ai-powered-developer -lifecycle-and-lessons-from-github-copilot/?ref=blog.gitguardian.com, June 2023. (Accessed on 10/10/2023). [3] S. Lertbanjongngam, B. Chinthanet, T. Ishio, R. G. Kula, P. Leelaprute, B. Manaskasemsak, A. Rungsawang, and K. Matsumoto, “An Empirical Evaluation of Competitive Programming AI: A Case Study of AlphaCode,” in Proceedings of the 16th IEEE International Workshop on Software Clones (IWSC), pp. 10–15, IEEE, 2022. [4] D. Wong, A. Kothig, and P. Lam, “Exploring the Verifiability of Code Generated by GitHub Copilot,” arXiv preprint arXiv:2209.01766, 2022. [5] A. M. Dakhel, V. Majdinasab, A. Nikanjam, F. Khomh, M. C. Desmarais, and Z. M. J. Jiang, “Github copilot AI pair programmer: Asset or liability?,” Journal of Systems and Software, vol. 203, p. 111734, 2023. [6] R. Pudari and N. A. Ernst, “From Copilot to Pilot: Towards AI Supported Software Development,” arXiv preprint arXiv:2303.04142, 2023. [7] M. L. Siddiq and J. C. Santos, “SecurityEval dataset: mining vulnerability examples to evaluate machine learning-based code generation techniques,” in Proceedings of the 1st International Workshop on Mining Software Repositories Applications for Privacy and Security (MSR4P&S), pp. 29–33, ACM, 2022. [8] J. He and M. Vechev, “Controlling large language models to generate secure and vulnerable code,” arXiv preprint arXiv:2302.05319, 2023. [9] B. Yetis¸tiren, I. Ozsoy, M. Ayerdem, and E. T ¨ uz¨ un, “Evaluating the Code ¨ Quality of AI-Assisted Code Generation Tools: An Empirical Study on GitHub Copilot, Amazon CodeWhisperer, and ChatGPT,” arXiv preprint arXiv:2304.10778, 2023. [10] O. Asare, M. Nagappan, and N. Asokan, “Is GitHub’s Copilot as bad as humans at introducing vulnerabilities in code?,” Empirical Software Engineering, vol. 28, no. 6, pp. 1–24, 2023. [11] M. Verdi, A. Sami, J. Akhondali, F. Khomh, G. Uddin, and A. K. Motlagh, “An Empirical Study of C++ Vulnerabilities in Crowd-sourced Code Examples,” IEEE Transactions on Software Engineering, vol. 48, no. 5, pp. 1497–1514, 2020. [12] T. Brown, B. Mann, N. Ryder, M. Subbiah, J. D. Kaplan, P. Dhariwal, A. Neelakantan, P. Shyam, G. Sastry, A. Askell, et al., “Language models are few-shot learners,” Advances in neural information processing systems, vol. 33, pp. 1877–1901, 2020. [13] M. O. F. Rokon, R. Islam, A. Darki, E. E. Papalexakis, and M. Faloutsos, “SourceFinder: Finding malware Source-Code from publicly available repositories in GitHub,” in 23rd International Symposium on Research in Attacks, Intrusions and Defenses (RAID 2020), pp. 149–163, 2020. [14] H. Pearce, B. Ahmad, B. Tan, B. Dolan-Gavitt, and R. Karri, “Asleep at the Keyboard? Assessing the Security of GitHub Copilot’s Code Contributions,” in 2022 IEEE Symposium on Security and Privacy (SP), pp. 754–768, 2022. [15] Y. Fu, P. Liang, A. Tahir, Z. Li, M. Shahin, and J. Yu, “Security Weaknesses of Copilot Generated Code in GitHub,” arXiv preprint arXiv:2310.02059, 2023. [16] Y. Huang, Y. Li, W. Wu, J. Zhang, and M. R. Lyu, “Do Not Give Away My Secrets: Uncovering the Privacy Issue of Neural Code Completion Tools,” arXiv preprint arXiv:2309.07639, 2023. [17] GitGuardian, “The State of Secrets Sprawl Report 2023.” https://www. gitguardian.com/files/the-state-of-secrets-sprawl-report-2023?ref=blog .gitguardian.com, 2023. [18] The MITRE Corporation (MITRE), “CWE List Version 4.12.” https: //cwe.mitre.org/data/index.html, 2023. [19] S. Zhao, “GitHub Copilot now has a better AI model and new capabilities - The GitHub Blog.” https://github.blog/2023-02-14-github-cop ilot-now-has-a-better-ai-model-and-new-capabilities/. (Accessed on 12/11/2023). [20] R. Khoury, A. R. Avila, J. Brunelle, and B. M. Camara, “How Secure is Code Generated by ChatGPT?,” arXiv preprint arXiv:2304.09655, 2023. [21] H. Hajipour, T. Holz, L. Schonherr, and M. Fritz, “Systematically Find- ¨ ing Security Vulnerabilities in Black-Box Code Generation Models,” arXiv preprint arXiv:2302.04012, 2023. [22] O. Asare, M. Nagappan, and N. Asokan, “Is GitHub’s Copilot as bad as humans at introducing vulnerabilities in code?,” arXiv preprint arXiv:2204.04741, 2022. [23] J. Shi, Y. Liu, P. Zhou, and L. Sun, “BadGPT: Exploring Security Vulnerabilities of ChatGPT via Backdoor Attacks to InstructGPT,” arXiv preprint arXiv:2304.12298, 2023. [24] E. Derner and K. Batistic, “Beyond the Safeguards: Exploring the ˇ Security Risks of ChatGPT,” arXiv preprint arXiv:2305.08005, 2023. [25] K. R. Go, S. Soundarapandian, A. Mitra, M. Vidoni, and N. E. D. Ferreyra, “Simple stupid insecure practices and GitHub’s code search: A looming threat?,” Journal of Systems and Software, vol. 202, p. 111698, 2023. [26] N. Perry, M. Srivastava, D. Kumar, and D. Boneh, “Do users write more insecure code with AI assistants?,” arXiv preprint arXiv:2211.03622, 2022. [27] X. Huang, W. Ruan, W. Huang, G. Jin, Y. Dong, C. Wu, S. Bensalem, R. Mu, Y. Qi, X. Zhao, et al., “A Survey of Safety and Trustworthiness of Large Language Models through the Lens of Verification and Validation,” arXiv preprint arXiv:2305.11391, 2023. [28] N. Nguyen and S. Nadi, “An Empirical Evaluation of GitHub Copilot’s Code Suggestions,” in Proceedings of the 19th International Conference on Mining Software Repositories, pp. 1–5, 2022. [29] GitHub, “GitHub Copilot for Individuals.” https://docs.github.com/en/c opilot/overview-of-github-copilot/about-github-copilot-for-individuals, 2023. (Accessed on 02/11/2023). This paper is available on arxiv under CC 4.0 license. This paper is available on arxiv under CC 4.0 license. available on arxiv

GitHub Copilot's Security Challenges: Insights and Recommendations

This paper is available on arxiv under CC 4.0 license.
Authors:
(1) Falke B. Ø. Carlsen, Department of Computer Science, Aalborg University, Denmark & falkeboc@cs.aau.dk;
(2) Lars Bo P. Frydenskov, Department of Computer Science, Aalborg University, Denmark & larsbopark@gmail.com;
(3) Nicolaj Ø. Jensen, Department of Computer Science, Aalborg University, Denmark & noje@cs.aau.dk;
(4) Jener Rasmussen, jener@jener.dk;
(5) Mathias M. Sørensen, mathiasmehlsoerensen@gmail.com;
(6) Asger G. Weirsøe, asger@weircon.dk;
(7) Mathias C. Jensen, Department of Computer Science, Aalborg University, Denmark & mcje@cs.aau.dk;
(8) Kim G. Larsen, Department of Computer Science, Aalborg University, Denmark & kgl@cs.aau.dk. Table of Links Introduction Definitions Model Checking Tool Overview Evaluation Conclusion and References 6 Conclusion In this paper, we present CGAAL, our model checker of alternating-time temporal logic properties in concurrent games. CGAAL checks such properties by encoding the problem as an extended dependency graph and then computes the satisfaction relation using the distributed local on-the-fly CERTAINZERO algorithm by Dalsgaard et al. [4]. We provide multiple novel search strategies for the algorithm and allow concurrent games to be expressed in our language LCGS. Our experiments show that the local on the-fly algorithm outperforms the global algorithm in the majority of cases. We also find that CGAAL outperforms the state-of-the-art tool PRISM-games by being up to two orders of magnitude faster, especially in models where synchronisations affect the internal state of modules and whenever we are not required to compute the entire fixed point. However, this comparison is unfair, since our test only uses a fraction of PRISM-games feature set. CGAAL is still in early development and much work is needed before it competes with PRISM in terms of capabilities. However, dependency graphs have been used for encoding various model checking problems, and we intend to incorporate these techniques into CGAAL. References [1] Rajeev Alur, Thomas A. Henzinger & Orna Kupferman (2002): Alternating-Time Temporal Logic. J. ACM 49(5), p. 672–713, doi:10.1145/585265.585270. [2] Edmund M. Clarke & E. Allen Emerson (1982): Design and synthesis of synchronization skeletons using branching time temporal logic. In Dexter Kozen, editor: Logics of Programs, Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 52–71, doi:10.1007/BFb0025774. [3] Edmund M Clarke, Thomas A Henzinger, Helmut Veith, Roderick Bloem et al. (2018): Handbook of model checking. 10, Springer, doi:10.1007/978-3-319-10575-8. [4] Dalsgaard, Andreas E. and Enevoldsen, Søren and Fogh, Peter and Jensen, Lasse S. and Jepsen, Tobias S. and Kaufmann, Isabella and Larsen, Kim G. and Nielsen, Søren M. and Olesen, Mads Chr. and Pastva, Samuel and Srba, Jiˇrí (2017): Extended Dependency Graphs and Efficient Distributed Fixed-Point Computation. In Wil van der Aalst & Eike Best, editors: Application and Theory of Petri Nets and Concurrency, Springer International Publishing, Cham, pp. 139–158, doi:10.1007/978-3-319-57861-3_10. [5] Søren Enevoldsen, Mathias Claus Jensen, Kim Guldstrand Larsen, Anders Mariegaard & Jiˇrí Srba (2020): Verification of Multiplayer Stochastic Games via Abstract Dependency Graphs. LOPSTR2020, doi:10.1007/978-3-030-68446-4_13. [6] Søren Enevoldsen, Kim Guldstrand Larsen & Jirí Srba (2022): Extended abstract dependency graphs. Int. J. Softw. Tools Technol. Transf. 24(1), pp. 49–65, doi:10.1007/s10009-021-00638-8. [7] Glen Jeh & Jennifer Widom (2002): SimRank: a measure of structural-context similarity. In: Proceedings of the Eighth ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, July 23-26, 2002, Edmonton, Alberta, Canada, ACM, pp. 538–543, doi:10.1145/775047.775126. [8] Jonas F. Jensen, Thomas Nielsen, Lars K. Oestergaard & Jiˇrí Srba (2016): TAPAAL and Reachability Analysis of P/T Nets, pp. 307–318. Springer Berlin Heidelberg, Berlin, Heidelberg, doi:10.1007/978-3-662-53401-4_16. [9] Jonas Finnemann Jensen, Kim Guldstrand Larsen, Jiri Srba & Lars Kaerlund Østergaard (2016): Efficient model-checking of weighted CTL with upper-bound constraints. International Journal on Software Tools for Technology Transfer 18(4), pp. 409–426, doi:10.1007/s10009-014-0359-5. [10] Mathias Claus Jensen, Anders Mariegaard & Kim Guldstrand Larsen (2019): Symbolic model checking of weighted PCTL using dependency graphs. NASA Formal Methods Symposium, pp. 298–315, doi:10.1007/978-3-030-20652-9_20. [11] M. Kwiatkowska, G. Norman & D. Parker (2011): PRISM 4.0: Verification of Probabilistic Real-time Systems. In G. Gopalakrishnan & S. Qadeer, editors: Proc. 23rd International Conference on Computer Aided Verification (CAV’11), LNCS 6806, Springer, pp. 585–591, doi:10.1007/978-3-642-22110-1_47. [12] M. Kwiatkowska, G. Norman, D. Parker & G. Santos (2020): PRISM-games 3.0: Stochastic Game Verification with Concurrency, Equilibria and Time. In: Proc. 32nd International Conference on Computer Aided Verification (CAV’20), LNCS 12225, Springer, pp. 475–487, doi:10.1007/978-3-030-53291-8_25. [13] Sangkeun Lee, Minsuk Kahng & Sang goo Lee (2015): Constructing compact and effective graphs for recommender systems via node and edge aggregations. Expert Systems with Applications 42(7), pp. 3396–3409, doi:10.1016/j.eswa.2014.11.062. [14] Xinxin Liu & Scott A. Smolka (1998): Simple Linear-Time Algorithms for Minimal Fixed Points (Extended Abstract). In Kim Guldstrand Larsen, Sven Skyum & Glynn Winskel, editors: Automata, Languages and Programming, 25th International Colloquium, ICALP’98, Aalborg, Denmark, July 13-17, 1998, Proceedings, Lecture Notes in Computer Science 1443, Springer, pp. 53–66, doi:10.1007/BFb0055040. [15] Lawrence Page, Sergey Brin, Rajeev Motwani & Terry Winograd (1998): The PageRank Citation Ranking: Bringing Order to the Web. Technical Report, Stanford Digital Library Technologies Project. Available at http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.1768. This paper is available on Arxiv under CC 4.0 license. This paper is available on arxiv under CC 4.0 license. Authors: (1) Falke B. Ø. Carlsen, Department of Computer Science, Aalborg University, Denmark & falkeboc@cs.aau.dk; (2) Lars Bo P. Frydenskov, Department of Computer Science, Aalborg University, Denmark & larsbopark@gmail.com; (3) Nicolaj Ø. Jensen, Department of Computer Science, Aalborg University, Denmark & noje@cs.aau.dk; (4) Jener Rasmussen, jener@jener.dk; (5) Mathias M. Sørensen, mathiasmehlsoerensen@gmail.com; (6) Asger G. Weirsøe, asger@weircon.dk; (7) Mathias C. Jensen, Department of Computer Science, Aalborg University, Denmark & mcje@cs.aau.dk; (8) Kim G. Larsen, Department of Computer Science, Aalborg University, Denmark & kgl@cs.aau.dk. This paper is available on arxiv under CC 4.0 license. Authors: Authors: (1) Falke B. Ø. Carlsen, Department of Computer Science, Aalborg University, Denmark & falkeboc@cs.aau.dk; (2) Lars Bo P. Frydenskov, Department of Computer Science, Aalborg University, Denmark & larsbopark@gmail.com; (3) Nicolaj Ø. Jensen, Department of Computer Science, Aalborg University, Denmark & noje@cs.aau.dk; (4) Jener Rasmussen, jener@jener.dk; (5) Mathias M. Sørensen, mathiasmehlsoerensen@gmail.com; (6) Asger G. Weirsøe, asger@weircon.dk; (7) Mathias C. Jensen, Department of Computer Science, Aalborg University, Denmark & mcje@cs.aau.dk; (8) Kim G. Larsen, Department of Computer Science, Aalborg University, Denmark & kgl@cs.aau.dk. Table of Links Introduction Introduction Definitions Definitions Model Checking Model Checking Tool Overview Tool Overview Evaluation Evaluation Conclusion and References Conclusion and References 6 Conclusion In this paper, we present CGAAL, our model checker of alternating-time temporal logic properties in concurrent games. CGAAL checks such properties by encoding the problem as an extended dependency graph and then computes the satisfaction relation using the distributed local on-the-fly CERTAINZERO algorithm by Dalsgaard et al. [4]. We provide multiple novel search strategies for the algorithm and allow concurrent games to be expressed in our language LCGS. Our experiments show that the local on the-fly algorithm outperforms the global algorithm in the majority of cases. We also find that CGAAL outperforms the state-of-the-art tool PRISM-games by being up to two orders of magnitude faster, especially in models where synchronisations affect the internal state of modules and whenever we are not required to compute the entire fixed point. However, this comparison is unfair, since our test only uses a fraction of PRISM-games feature set. CGAAL is still in early development and much work is needed before it competes with PRISM in terms of capabilities. However, dependency graphs have been used for encoding various model checking problems, and we intend to incorporate these techniques into CGAAL. References [1] Rajeev Alur, Thomas A. Henzinger & Orna Kupferman (2002): Alternating-Time Temporal Logic. J. ACM 49(5), p. 672–713, doi:10.1145/585265.585270. [2] Edmund M. Clarke & E. Allen Emerson (1982): Design and synthesis of synchronization skeletons using branching time temporal logic. In Dexter Kozen, editor: Logics of Programs, Springer Berlin Heidelberg, Berlin, Heidelberg, pp. 52–71, doi:10.1007/BFb0025774. [3] Edmund M Clarke, Thomas A Henzinger, Helmut Veith, Roderick Bloem et al. (2018): Handbook of model checking. 10, Springer, doi:10.1007/978-3-319-10575-8. [4] Dalsgaard, Andreas E. and Enevoldsen, Søren and Fogh, Peter and Jensen, Lasse S. and Jepsen, Tobias S. and Kaufmann, Isabella and Larsen, Kim G. and Nielsen, Søren M. and Olesen, Mads Chr. and Pastva, Samuel and Srba, Jiˇrí (2017): Extended Dependency Graphs and Efficient Distributed Fixed-Point Computation. In Wil van der Aalst & Eike Best, editors: Application and Theory of Petri Nets and Concurrency, Springer International Publishing, Cham, pp. 139–158, doi:10.1007/978-3-319-57861-3_10. [5] Søren Enevoldsen, Mathias Claus Jensen, Kim Guldstrand Larsen, Anders Mariegaard & Jiˇrí Srba (2020): Verification of Multiplayer Stochastic Games via Abstract Dependency Graphs. LOPSTR2020, doi:10.1007/978-3-030-68446-4_13. [6] Søren Enevoldsen, Kim Guldstrand Larsen & Jirí Srba (2022): Extended abstract dependency graphs. Int. J. Softw. Tools Technol. Transf. 24(1), pp. 49–65, doi:10.1007/s10009-021-00638-8. [7] Glen Jeh & Jennifer Widom (2002): SimRank: a measure of structural-context similarity. In: Proceedings of the Eighth ACM SIGKDD International Conference on Knowledge Discovery and Data Mining, July 23-26, 2002, Edmonton, Alberta, Canada, ACM, pp. 538–543, doi:10.1145/775047.775126. [8] Jonas F. Jensen, Thomas Nielsen, Lars K. Oestergaard & Jiˇrí Srba (2016): TAPAAL and Reachability Analysis of P/T Nets, pp. 307–318. Springer Berlin Heidelberg, Berlin, Heidelberg, doi:10.1007/978-3-662-53401-4_16. [9] Jonas Finnemann Jensen, Kim Guldstrand Larsen, Jiri Srba & Lars Kaerlund Østergaard (2016): Efficient model-checking of weighted CTL with upper-bound constraints. International Journal on Software Tools for Technology Transfer 18(4), pp. 409–426, doi:10.1007/s10009-014-0359-5. [10] Mathias Claus Jensen, Anders Mariegaard & Kim Guldstrand Larsen (2019): Symbolic model checking of weighted PCTL using dependency graphs. NASA Formal Methods Symposium, pp. 298–315, doi:10.1007/978-3-030-20652-9_20. [11] M. Kwiatkowska, G. Norman & D. Parker (2011): PRISM 4.0: Verification of Probabilistic Real-time Systems. In G. Gopalakrishnan & S. Qadeer, editors: Proc. 23rd International Conference on Computer Aided Verification (CAV’11), LNCS 6806, Springer, pp. 585–591, doi:10.1007/978-3-642-22110-1_47. [12] M. Kwiatkowska, G. Norman, D. Parker & G. Santos (2020): PRISM-games 3.0: Stochastic Game Verification with Concurrency, Equilibria and Time. In: Proc. 32nd International Conference on Computer Aided Verification (CAV’20), LNCS 12225, Springer, pp. 475–487, doi:10.1007/978-3-030-53291-8_25. [13] Sangkeun Lee, Minsuk Kahng & Sang goo Lee (2015): Constructing compact and effective graphs for recommender systems via node and edge aggregations. Expert Systems with Applications 42(7), pp. 3396–3409, doi:10.1016/j.eswa.2014.11.062. [14] Xinxin Liu & Scott A. Smolka (1998): Simple Linear-Time Algorithms for Minimal Fixed Points (Extended Abstract). In Kim Guldstrand Larsen, Sven Skyum & Glynn Winskel, editors: Automata, Languages and Programming, 25th International Colloquium, ICALP’98, Aalborg, Denmark, July 13-17, 1998, Proceedings, Lecture Notes in Computer Science 1443, Springer, pp. 53–66, doi:10.1007/BFb0055040. [15] Lawrence Page, Sergey Brin, Rajeev Motwani & Terry Winograd (1998): The PageRank Citation Ranking: Bringing Order to the Web. Technical Report, Stanford Digital Library Technologies Project. Available at http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.31.1768. This paper is available on Arxiv under CC 4.0 license. Arxiv

CGAAL: Wrapping It Up and What Comes Next

Today, I would like to share a management practice we developed at New Relic. It was one of the best things we did as an engineering organization. The practice is called “Mini-Ms”. I believe it’s . as important a practice for managers as code reviews are for engineers This post is first of a series: In this post, we look at how Mini-Ms work and what they are. Next, we learn how to implement Mini-Ms. Then, we discuss variations you may want to consider. Finally, we share a history of Mini-Ms, including where the name came from. What is a Mini-M? A Mini-M is a group of managers that meet weekly or biweekly. The meeting is a combination support group and working session. In each session, managers share challenges they face. The other participants offer support and help problem-solve. Why are Mini-Ms effective? What is the value in meeting with other managers and talking about your problems? It may not seem like it is worth the time. Yet, many managers claimed Mini-Ms helped them grow more than anything else. Mini-Ms help you develop skills There are a few reasons for that. describes three reasons: Elaine May “Learning to manage is very different from other types of learning (like engineering, for instance). . I’ve seen this trip up many engineering managers who read a book or attend a class and find the concepts trivial and therefore easy or not very important. Learning management is more of an apprenticeship versus an intellectual pursuit.” In management, the concepts are simple and the execution is not “In a Mini-M, . If you are only learning from a coach, manager, or mentor, their approach may not fit very well for you, but in a Mini-M, you are getting multiple perspectives.” you have many other people to learn from . When you share your experiences and ideas with other managers, you’re forced to articulate your own practice, and consider it in a critical way. Teaching clarifies your thinking I have a few more explanations: . You might be good at running meetings. I might be good at 1-1s. Another participant might be an effective project manager. During a Mini-M, we all share our experience with each other. Imagine having to fill in those skills some other way. You would have to study each of those topics. Or learn each of them the hard way. That would be much slower! The diversity of the group allows the group to grow faster. Skills are unevenly distributed . Most alternative methods of learning involve assumptions of where your current skills are. For example, a management course tries to teach you a certain set of concepts or practices. But Mini-Ms allow you to expand your skills from wherever they may be. If I am struggling with how to run a particular meeting, I can immediately add a little to my skills during a single Mini-M session. Mini-Ms meet you where your skills are This makes the M-team into a combination of a support group and training session for your management team. Mini-Ms are a source of valuable support Management is a difficult profession. As hierarchical creatures, being “higher” in the hierarchy separates you from your team members. And other managers are often busy and unavailable. Because Mini-Ms were largely modeled on support groups, your group can become part of your support network. Even outside of the meetings, you might turn to your fellow managers for help. Having a Mini-M helped me to build up a mental map of the skills of the managers around me. This was helpful, because I started to understand the skills that I needed to build. When I ran into problems running projects, I felt like I could go to the person I knew was good at it and ask for help. And because we had a relationship from our Mini-M, they were more likely to want to help. In addition, many companies are distributed nowadays. This can result in less accidental interaction with peers. And it can contribute to isolation. Mini-Ms can be a source of connection with other managers. Mini-Ms help retain and attract managers Because managers feel better supported by their peers, they are more likely to stay at the company. Or stay in management. I anticipated that benefit. What surprised me was that people outside the company seemed to keep hearing about these Mini-M groups. And they would bring it up during interviews and mention it was why they applied in the first place! Why were they so attracted by Mini-Ms? They demonstrated that we took management seriously as a role. They showed that we valued developing our people, which was a signal that their job as a manager would be better here. They showed we experimented with our organizational practices. And would welcome further innovation. Mini-Ms help build a management culture Along with a support group, the other inspiration for Mini-Ms was a conspiracy. The idea was to bring a few managers together, gripe about the problems in the organization, and come up with solutions. Mini-Ms naturally became the graph along which many management practices spread through the organization. In the , Lencioni talks about the importance of managers seeing their “first team” as the management team. Mini-Ms helped develop a community of managers that all were focused on improving their skills and their teams. And many of us felt empowered to address the problems we saw in the organization around us. Five Dysfunctions of a Team How does a Mini-M work? There have been a lot of variations to the way Mini-Ms have run over the years. What follows is a good way to start Mini-Ms. The Organizer of the Mini-Ms assigns each manager to a Mini-M. Each Mini-M has five to eight managers. The Organizer sets the expectation that managers attend. Each group has a Facilitator. They schedule and facilitate meetings. They usually start with a standard meeting format. Here’s an example format: Each person brings a topic: something that was challenging from last week, or something they are facing now. In an in-person meeting, the Facilitator would go around and ask everyone for their topics and put them on a whiteboard. In a distributed setting, all the participants would add their topics at the same time to a shared doc. Everyone gets three votes. They put them on the topics they would like to discuss. The group goes through the topics and discusses them in turn, ordered by the topics that have the most votes. The Facilitator checks in every five minutes to see if the group is finished with the current topic, or wants to continue the discussion. This is based on the . Lean Coffee meeting format The Facilitator sets the expectation that meetings are safe places. Participants discuss sensitive topics and there is an expectation of confidentiality. For example, a manager might talk about the challenges they were having with manager. their When to use Mini-Ms You should design your Mini-Ms based on the particulars of your company. The size and company culture are particularly important. One precondition to this being successful is that the environment be a supportive one. If the leaders value learning and growth, they are more likely to support Mini-Ms properly. A competitive culture may not be a good fit. I recommend Mini-Ms to companies with product-market fit. Early in the growth of a company, product-market fit is the most important factor in a company’s success. After you’ve found a good fit with the market, organizational effectiveness moves up in importance to become one of the most critical factors for your success. At that point, M-Teams begin to contribute more directly to the success of the company. While you can lay the groundwork for M-Teams earlier, I wouldn’t recommend them in most early stage companies. You can use Mini-Ms globally, across an organization, or within a smaller group. You can even implement a Mini-M informally, with a smaller group of managers. If you start informally, be sure to read the History section to see how they evolved at New Relic. How do I implement Mini-Ms? We get to that in our next post. That might also be the easiest way to get to future posts. Thank you Not a lot has been written about Mini-Ms, but there is currently on the New Relic blog, and another that has mysteriously . one post vanished authored some content that were inspirations for large parts of this article. He and I have worked together on helping other companies implement Mini-Ms, so if you’re interested in help. He also provided feedback and suggestions on drafts of this article. He encouraged me to explain the first team concept more fully, and to describe why pre-product market fit companies may not be a good match. And he suggested I split the content into separate articles. Darin Swanson contact me was one of the cofounders of Mini-Ms. He reviewed this post, offered feedback, and contributed to the history section and described some of the design goals for Mini-Ms. Nic Benders provided feedback, some of which was so good I just ended up quoting her. She was gracious enough to offer some talk to talk about her experiences setting up or participating in similar programs at other companies. And she talked about her experiences with me in New Relic’s Mini-Ms. Elaine introduced me to the Chatham House Rules, which I incorporated into the post. Elaine May was the grandfather of the Mini-M. He shared a lot of his thinking about the principles behind why Mini-Ms were successful and what they were aiming for. He advised me to break up this post into sections and make it easier to get to the implementation section. And shared overall feedback. Bjorn Freeman-Benson helped me improve the section on “when to use Mini-Ms” by pointing out some preconditions for success. He pointed out that the structure became less important after the Mini-M is established. Merlyn pointed out that we tried to keep people from being in the same Mini-M as their managers, or other people reporting to the same manager. He also shared the theory about VPs not being willing to be vulnerable as a possible explanation for why the Mini-Ms never took off in manager of manager groups to the same extent they did for frontline managers. Merlyn Albery-Speyer shared his experience as an Organizer of Mini-Ms. He pointed out a now mostly disappeared on Mini-Ms. He also suggested ways Facilitators could counter unproductive ranting. Jason Poole second post shared feedback based on his experience as an Organizer. He helped improve the advice for Organizers. And he pointed out that engineering adjacent departments participated. Marty Matheny pointed out that confidentiality was an issue with whiteboards. He noticed an error that would have been embarrassing. He pointed out the value of M-teams in distributed organizations to counter isolation among managers. He also added some advice for participants. Chris also helped with a point about the value of the first few meetings. Chris Hansen reviewed a draft of this post and pointed out some redundant assertions I was making. And she recommended I break this into multiple posts or edit for brevity. Teresa Martyny was another early Mini-M leader, and she reviewed a draft of the post and contributed to it. Natasha Litt Image by from J Garget Pixabay Also published . here

Upskill Your Managers With Mini-M Support Groups

The Count of Monte Cristo, Illustrated: Chapter 5 - The Marriage Feast

Many have written about classification and categorization of crypto assets. Security tokens, utility tokens, cryptocurrencies, exchanges, appcoins, and altcoins are all labels in an effort to organize a collection of similar crypto assets. Some people, like Tom Lee (whom I respect very much) of , break the collections into cohorts based on how they trade — more like sectors. For example, Lee breaks the sectors into commodities, platforms, privacy, exchanges and stablecoins. He does this because these cohorts trade similarly, and he can based on their collective attributes. Sector definition is important, but I think there’s one higher level of abstraction needed. That’s crypto asset classes. Commodities, platforms and stablecoins are of a different classification type than privacy coins and exchanges, and I would separate them as such. That way, we’ll have both asset classes and sectors like we do with traditional financial markets. Fundstrat Global Advisors model trading action Others, like the general partners at , break the collections into 3 major cohorts: currencies (stores of value); security tokens (tokens backed by real-world assets); and utility tokens (work tokens). They’ve settled on this configuration because they think each has a separate and distinct valuation model. They outline a for currencies and work tokens. You’ll notice that they don’t distinguish platform coins from cryptocurrencies as they believe platform coins will be held for their own specific store of value. Multicoin Capital valuation model Some labels have just come to us through nomenclature “inheritance” which I don’t think is very helpful. An example of this is the moniker “altcoins”. It can be confusing as to exactly what an altcoin is and whether it can mean every other coin that is not bitcoin or ether. That’s a large subset that really doesn’t do anyone much good. I think of the crypto asset class superset a little differently. I would classify the mutually-exclusive subsets based on logical groupings. I see and eight distinct crypto asset classes — reserve, currencies, platforms, utility tokens, security tokens, commodities, appcoins stablecoins. I use these crypto asset classes because members of the set have similar properties. They have similar functional goals and react to the market in a similar fashion. They have similar valuation models, compete with one another in some form or operate similarly within their set, have similar regulatory risk and generally define the highest subset under the umbrella crypto asset superset. Fundamentally, I’m coming at this as an investor. I want to have an asset allocation strategy, and then have multiple positions of the best coins I think will produce a return for that crypto asset class. I want to be able to manage target asset class percentages. I don’t want to commingle currencies, utility tokens, platforms and appcoins in the same asset class because it does not provide me with a satisfactory level of precision to allocate across the total market. The asset classes may have similar valuation models, but their stated goal and their functions are different. From an investor’s perspective, it makes sense to create 6–12 classes that are mutually exclusive while also being exhaustively comprehensive to classify members in the entire crypto asset superset. Reserve Assets The reserve crypto asset class contains just two coins — bitcoin and ether. I’m pulling Ethereum out of the platforms crypto asset class for now because it has special properties. Ultimately, investors need to convert their fiat currency into either bitcoin or ether to buy any other coin or token. These act as reserve crypto assets in the market. While bitcoin and ether are different in many ways, they both have a market quality similar to one another and not shared by any other crypto assets. They are both mined and have set monetary policies. Cogent arguments have been made that bitcoin is its own distinct crypto asset class because its deflationary cryptocurrency with limited supply. The Ethereum network is a platform with different supply/demand mechanics than Bitcoin. However, as long as these two crypto assets hold this special dynamic within the market, I’m going to consider them both reserve assets. Let’s take a page from the financial analog. The entire current global asset structure starts with gold. Gold is the first form of money because it is not issued or controlled by a central authority. Moreover, it does not have counter-party risk. We have agreed on its price, based on its scarcity, which has held for millennia. From gold, countries manage their fiat money supplies through their central banks. In the past, the amount of gold a country owned affected how much of its currency supply could be printed. From the formation of currency, a government creates bonds which include an interest rate. Moreover, commodities are priced and other fixed income (bonds) are created to produce a return on capital in the financial market. Equity can be created as a security, after pricing resources (commodities) and calculating interest rates and risk. While gold is classified as a commodity (for legal and other reasons), it’s treated as both a commodity and a currency. It has special properties which convince asset allocators and investors that gold is an asset class of its own. I agree. The same is true for the reserve crypto assets. decentralized Cryptocurrencies Cryptocurrencies’ core benefit to the market is to be a digital form of payment. The fundamental question to test whether or not a coin is a currency asks “Is the primary use as a medium of exchange and/or a store of value?” That is, does it digitally fulfill on a currency’s ability to be: a medium of exchange; a store of value; and, ultimately, a unit of account. While each cryptocurrency is at various stages of delivering on these, that is the primary goal or function. Cryptocurrencies collectively would have similar regulatory risk as a collection compared against other crypto asset classes, i.e., utility tokens, depending on how they came to market. Cryptocurrency has a similar valuation function as standard currency. As such, the Equation of Exchange, M x V= P x Q, is applicable here. The valuation model of cryptocurrency is fundamentally based on unit expenditure and, more importantly, on the velocity of money. As money is used faster throughout the system, the value of that monetary system increases. Cryptocurrencies are all trying to address the same issues with payment. Cryptocurrencies are grouped logically, and there is no superset between this asset class and the crypto asset umbrella superset. Therefore cryptocurrency is its own crypto asset class. Examples of cryptocurrencies are: Bitcoin, Bitcoin Cash, Monero and Dash. Platforms Platforms are going to be one of the most interesting cryptos because this is where smart contracts and programmatic money are going to exist. If a blockchain wants to implement smart contracts in some form, then it’s probably in the platform asset class. Programmatic enforcement of legal and financial contracts will transform the shape and velocity of what’s possible globally. We’re already seeing a fundamental change in what’s possible with the accumulation, transference and store of value. To understand what’s possible, let’s paint a picture of the future in 20 years. All corporations will effectively be smart contracts. Governance, voting, supply chain and contract enforcement will fundamentally change because we are going to be able to programmatically store and transfer value based on some previously agreed-upon logic. We will be able to see exactly where our food comes from and how its handled along the way. We will be able to trust digital voting has not been tampered with because of the immutability of a blockchain. Land title disputes will no longer exist. Value will be created globally just from the transparency and predictability of contract execution. Platforms will work to provide some of the fundamental building blocks of blockchain, like smart contracts, immutability and decentralization. However, they are distinct from cryptocurrency in their stated goal and function. They have different regulatory risk than other crypto asset classes, depending on how they were created (e.g. based on regulatory region and whether a public ICO or private pre-sale governed sale, etc.) Platforms are closer to legal contracts than money in the analog paradigm. Their valuation model is primarily based on , which is described by — the value of the network is proportional to n² users of the network. Whereas, cryptocurrencies are valued on the velocity of money and the equation of exchange. Platforms are distinct from all other crypto asset classes, and thus they are an asset class of their own. network effects Metcalfe’s Law Examples of Platforms are: EOS, NEO, Cardano & IOTA. Utility Tokens Utility tokens focus on a providing a service layer. They provide a function or a resource to address a specific need. They have partners and contributors who create applications on top of the protocol or create applications that use the utility token. Utility tokens valuation model is primarily based on network effects and are influenced by supply/demand. Utility tokens run on a platform blockchain they do not directly manage or control. Most utility tokens to date run on the Ethereum platform. Utility tokens are distinct from platforms in that they aren’t providing a lower level or horizontal functionality built on top of a blockchain like a protocol and they are distinct from appcoins because their stated functional goal is not limited to one application or service. Utility tokens may work on one blockchain for now, but in the future the utility tokens may operate on multiple networks to serve multiple appcoins. Examples of Utility Tokens are: BAT, Civic, OmiseGO and 0x. Photo by on Igor Ovsyannykov Unsplash Security Tokens Security tokens are different from utility tokens and platforms by their functional nature and goal as well as by their regulatory risk profile. They derive their value from being linked to an external asset and are likely subject to federal securities regulations here in the U.S. The valuation model of a security token directly relates to valuing the underlying asset linked to the token. These tokens will have a much bigger play and their growth stage in 2018 and beyond. I predict within the next 12 months there will be companies that want to have their equity trade as security tokens on a crypto exchange. We’ll also see real estate secured on a blockchain with a security token. Security tokens are distinct from all other crypto asset classes because of their link to an external, real-world asset. An example of a Security Tokens is: BCAP. Crypto Commodities Commodities aim to provide a direct consumable resource. This is distinct from the platform asset class in that it’s vertical/industry specific and it seeks to exchange based on a specific subset of resources. Those resources could include disk space, computing power or other consumable services. Commodities are distinct from utility tokens in that their valuation model is mostly influenced by the supply and demand of a given resource. Crypto-commodities run their own blockchain which is different than how utility tokens operate. This is one of the main mechanics to how supply and demand affect price. Price surges and other scarcity risks could occur more frequently with commodities than may affect other asset classes like utility tokens or appcoins. Though, they will have less regulatory risk because of the work or resource exchanged, assuming appropriate measures were followed in their pre-sale. Their valuation model is influenced by network effects but the valuation model is different than currencies which are mostly valued by the velocity of money and platforms which are valued mostly by network effects. Examples of crypto-commodities are: STORJ, FileCoin and Golem. Appcoins / dApps Appcoins work on one specific network to provide a specific vertical application service. They are distinct from commodities in that their supply is not constrained like a commodity or resource that is consumed. They are different from platforms because they are vertical and application-specific. They aren’t providing a platform or protocol for others to build upon. Their goal and utility is distinct in focusing on their own narrow ecosystem. They have a many-to-one relationship in their network model whereas utility tokens have a many-to-many relationship. Appcoins are the most narrow applications and therefore levered to a specific use case as being a “pure play” to a particular application or service. As a result, their valuation model will be distinct from commodities, currencies or platforms. Examples of Appcoins are: Steem, Binance and SALT. Stablecoins Stablecoins are present to provide a stable store of value. Currently, there is one major player within this crypto asset class. That is Tether. However, that will change in the future. Currently there are several projects pursuing various methods on how they will achieve a stable coin. I recommend this to learn more about stablecoins. This is a new and burgeoning asset class, and we will distinguish it on its own due to its stated goal and functional nature. article from Multicoin Capital Examples of Stablecoins: Tether, Maker, Basecoin & Digix Conclusion Hopefully, this makes a case for a good classification model of crypto asset classes. This could change as we’re in the very early stages of this new asset class. It’s possible appcoins could merge into utility tokens or crypto-commodities merge into platforms. My goal is to help investors build a portfolio with appropriate asset allocation to improve your risk-adjusted returns. To achieve that, we need a good framework for how to think about crypto asset classes. If Modern Portfolio Theory (MPT) suggests a return can be made only 3 ways — portfolio construction, asset selection and market timing — then we want a structure to help guide and enforce how we think about asset allocation. A comprehensive crypto asset class model will help in this effort. I’ll leave selection and market timing to other upcoming articles. Happy Hunting! Jake Disclaimer: The above references an opinion and is for information purposes only. It is not intended to be investment advice. Please do your own homework. Jake Ryan is the founder of Wealth Rituals and Tradecraft Capital, a startup advisor, an angel investor & writer on investing. If you enjoyed this article “clap” to help others find it! For more, join us on Facebook , Twitter . #crypto #cryptocurrency #bitcoin #investing #howto #blockchain

Crypto Asset Classes

seems to have a effect on people – either they love it or hate it. It’s true that rebasing opens up a whole range of new and exciting ways to screw yourself over. Even better than that it offers up a range of wonderful opportunities to screw over your team mates as well. Yet despite that I am most definitely in the pro-rebase camp. After all, all the most powerful tools will burn you if you don’t use them properly. Having developed a fairly extensive set of rebase scars over the years here are my handy tips for dodging the pitfalls and making the most of rebase. Git rebasing marmite This assume that you are already familiar with the basic operations of . If not the is probably a good place to start. git rebase git rebase documentation Always rebase interactively Git has two main forms of rebase – interactive and non-interactive. Essentially they do the same thing – take your branch and reapply the code changes on top of another branch. Interactive rebasing offers a bunch more options such as re-ordering and re-wording commits but for the safety-conscious rebaser, the main thing it offers is that it shows you a list of commits that will be re-applied before the rebase starts. In my experience, the vast majority of rebase disasters can be averted by simply reviewing this list and aborting the rebase before it even starts. If the list is not what you expect then run away, figure out why and then try again. Example interactive rebase commit list Be conscious of how you bring in upstream changes A corollary of always rebasing interactively is that you should never use . I would go a step further and say that the only version of git pull you should use is . This is because both the rebase and the default case may result in the code you are working on changing without you realising it. They will both attempt to transparently incorporate any changes made upstream without advising you what they are or letting you review them. A classic case of where this is undesirable is when you and a colleague both add the same method to a class but in a different place in the file. Git will quite happily combine these changes resulting in a duplicate method definition. Maybe you or your colleague will catch it in code review but it is better to avoid it in the first place by being mindful of when the code you are basing your changes on may have changed. git pull --rebase git pull --ff-only Go slow and keep it simple It’s very easy to get excited when you start an interactive rebase. But instead of just diving in and throwing commits here, there and everywhere, taking it easy and spreading the rebase over a few steps will save you a lot of pain and misery in the long run. The first thing I do is an interactive rebase without changing anything. This way you can review the commits and deal with any upstream conflicts up front without having to try and figure out whether the conflicts are a result of something that has changed in the branch you are rebasing onto or whether it is a problem you have created with all your commit juggling. Then as you proceed keep moving, squashing and editing commits in small chunks. That way if you do get any unexpected conflicts you can abort the rebase and figure out the problem without losing any other changes you may have made. Nothing’s worse than going through a marathon rebase to get within sight of the end and having to abort the whole thing because you’ve swapped the wrong two commits around and now one of them won’t apply. Don’t be afraid to run away Rebasing shouldn’t be hard. If it is there is probably an underlying problem with what you are trying to do. Perhaps something has changed upstream that you weren’t aware of. Perhaps you have files in a commit that you weren’t expecting to be there. Don’t be afraid to abort the rebase so that you can stop and rethink what you are trying to do without the pressure of being in rebase limbo. The best way to resolve conflicts is not to have any It is inevitable that you will sometimes run into conflicts caused by changes your colleagues have made. One way or another you will have to deal with them, whether it is via rebasing, when you merge or by shouting at your colleagues until they revert their changes so that you can merge first and thereby force them to deal with the conflicts. Conflicts caused by moving commits around within your own branch are more avoidable however. Keep your commits small and focused. The fewer files and changes in a commit, the less likely it is to conflict and so the easier it is to reorder. If you are TDDing then a good place to start is committing each time you add a test and get the associated code passing. That way you are only ever committing two files at a time and each file will contain a small change. Sometimes more is less The more here being the number of commits and the less being the amount of pain involved in rebasing. If you have ignored the previous suggestion of committing often then that doesn’t mean all is lost. Interactive rebasing allows you to edit a commit. If you have added too many files to a commit and so now can’t move it around, you can edit the commit, remove some of the changes from the commit and create a new commit for them. This sounds complicated but in fact is as simple as marking the commit for editing in the interactive rebase commit list. Then when the rebase pauses run git reset HEAD~ some/file/for/another/commitgit commit --amendgit add .git commit -m '- message for the separate commit'git rebase --continue This will leave all the changes to that file in a separate commit. Another variation on this is for when you have multiple changes to the same file that have accidentally ended up in the same commit. In this case is your friend. This will allow you to choose which of the changes to the file are merged back into your original commit and which stay unstaged ready to add to another commit. git add -p . Know how to fix it when it all goes wrong One of the beauties of git is that it is actually quite hard to completely lose anything once it has been committed. If you do get to the end of your rebase and realise you’ve made a pig’s ear of it, your previous commits still exist and you can easily revert back. First you need the SHA of the tip of your branch before the rebase. Assuming you don’t have this to hand, you can find it using . You will be able to see where your rebase started easily enough as the line will contain . You just need to find the SHA of the commit before this and reset to that commit with . git reflog rebase -i (start) git reset --hard SHA Force push if you have to, but make sure you really need to first One of the oft-cited reasons for avoiding rebasing is that in order to push your changes back upstream you will need to force push, with the potential to overwrite other user’s changes. This is of course completely possible and a great way to antagonise your colleagues. However just because you can screw things up by force pushing doesn’t mean you have to. First of all, you only use rebasing before you merge. Once you have merged something into one of your “main” branches (typically master but perhaps you have other special release branches) then it’s there for good. If you find a problem afterwards you have to live with it or add another commit. You can rebase other branches that you share with colleagues if you choose to. You simply need to communicate as to who is doing what. We do this on a daily basis without issue. It helps if people are responsive. So if one of my colleagues tells me that they have force pushed a branch we are sharing then I will update my local copy straight-away. It helps avoid conflicts and trying to figure out whether a force push should or shouldn’t be necessary. You should also know before you attempt to push whether you are expecting a force push to be necessary. If you get the classic force push error message (along the lines of ) when you weren’t expecting it then don’t just automatically force push. Stop and see what commits you have locally compared to the remote version and then it should become clear what you need to do to fix it. error: failed to push some refs... My personal rule of thumb around shared branches is that if a colleague and I are working on the same feature at the same time, I will create my own branch from the feature branch, work on that and then rebase and merge back into the shared feature branch. It is the safest option and since you both may be pushing frequently it saves constant back and forth. If we are working independently in more of a handover type scenario then we will probably both just work on the same branch as the chances of treading on each other’s toes is much smaller. The other approach, which is probably what we do most commonly, is save the rebase until the end. So we both just keep adding commits to the tip of the branch and then one or both of us will perform the rebase tidy up once we are happy that the feature is ready to go. Use the correct type of merge The aim of rebasing is not to avoid merge commits or maintain a linear history. Merge commits can be very helpful in identifying a set of commits that have some degree of cohesion. However at the other extreme where every single commit has a matching merge commit they are unhelpful and clutter up your log. The answer is simply to always merge with the correct flag set. If I am merging a single commit or if the branch contains multiple unrelated commits then I will do a . If not I will do a . Simple as that. git merge --ff-only git merge --no-ff You don’t have to wait til the end to rebase There are definite benefits to rebasing your code once you have completed all the tasks as discussed above and in . However sometimes you will add a commit just to fix a typo in an earlier commit or something equally trivial. It can be beneficial to just squash these changes straight into the correct commit immediately in order to reduce the number of commits you are working with in your final pre-PR rebase. The poetry of pull requests So there we have it, 10 handy tips for smooth and efficient rebasing. However knowing techniques for juggling commits is only part of the picture. You also need to know what kind of end result you are looking to achieve. For more on that, check out . The poetry of pull requests

How to rebase safely for profit and pleasure

Authors:
(1) Michal K. Grzeszczyk, Sano Centre for Computational Medicine, Cracow, Poland and Warsaw University of Technology, Warsaw, Poland;
(2) M.Sc.; Paulina Adamczyk, Sano Centre for Computational Medicine, Cracow, Poland and AGH University of Science and Technology, Cracow, Poland;
(3) B.Sc.; Sylwia Marek, Sano Centre for Computational Medicine, Cracow, Poland and AGH University of Science and Technology, Cracow, Poland;
(4) B.Sc.; Ryszard Pręcikowski, Sano Centre for Computational Medicine, Cracow, Poland and AGH University of Science and Technology, Cracow, Poland;
(5) B.Sc.; Maciej Kuś, Sano Centre for Computational Medicine, Cracow, Poland and AGH University of Science and Technology, Cracow, Poland;
(6) B.Sc.; M. Patrycja Lelujko, Sano Centre for Computational Medicine, Cracow, Poland;
(7) B.Sc.; Rosmary Blanco, Sano Centre for Computational Medicine, Cracow, Poland;
(8) M.Sc.; Tomasz Trzciński, Warsaw University of Technology, Warsaw, Poland, IDEAS NCBR, Warsaw, Poland andTooploox, Wroclaw, Poland;
(9) D.Sc.; Arkadiusz Sitek, Massachusetts General Hospital, Harvard Medical School, Boston, MA, USA;
(10) PhD; Maciej Malawski, Sano Centre for Computational Medicine, Cracow, Poland and AGH University of Science and Technology, Cracow, Poland;
(11) D.Sc.; Aneta Lisowska, Sano Centre for Computational Medicine, Cracow, Poland and Poznań University of Technology, Poznań, Poland;
(12) EngD. Table of Links Abstract and Introduction Related Work Methods Results and Discussion Limitations Conclusion, Acknowledgment, and References Related work Cognitive Load Detection. To obtain a good and unobtrusive cognitive load detector, which could facilitate both development of timely context-aware reminders and the evaluation of application use effort in the wild[8], researchers considered the utilization of wearable devices and machine learning. Morkova et al.[12] used a Shimmer[3] GSR+ device attached to the participant's two fingers and an ear lobe to capture galvanic skin responses (GSR), electrocardiograms (ECG) and PPG signal of individuals during cognitively demanding tasks and neutral condition (CLAS dataset). The authors trained a person-specific Support Vector Machine (SVM) model on features extracted from GSR either paired with features extracted from ECG or PPG recordings to predict subjects' concentration. They reported average classification performance of 78% (ECG+GSR) and 74% (PPG+GSR) and commented that these performance differences were not significant and do not justify the use of ECG. Consumer-grade wearables, employed in just-in-time interventions, due to high cost and low practicality rarely are equipped with ECG and GSR sensors commonly available in devices used in experimental conditions[15]. Therefore, we focus on developing a cognitive load detector that utilizes PPG signal only, that can be captured by smartwatches. Lisowska et al.[11] use a PPG signal from CLAS dataset[12] to detect cognitive load. The authors compared the performance of SVM with a different number of features vs. simple 1D Convolutional Neural Network (1D CNN). The latter performed better, however, the achieved average cognitive load classification accuracy reached only 60%. The authors tried to improve cognitive load detection through semi-supervised model training leveraging additional unlabeled signal, however, no notable performance gains were reached. We base our solution on this approach and first investigate the limitation of the simple 1D CNN and later suggest a potential change to the training approach. We consider between-task transfer learning. Our investigation is based on the following observations: Even though deep learning approaches have been shown to outperform traditional methods utilizing handcrafted features such as SVMs in a range of applications[14], including cognitive load detection from PPG signal[8], CNN-based models are known to be data hungry and in low data regimes, they tend to be pre-trained to offer better performance[20].


Cognitive load annotations are not easy to gather and there are few datasets utilizing physiological signals from wrist-worn devices designed to capture that state. On the other hand, stress classification is a commonly tackled problem and high-quality publicly available physiological signal datasets, such as WESAD[16] (Wearable Stress and Affect Detection), provide signal paired with labels convenient for ML training. Well-being Survey Gamification. Gamification refers to the use of game elements such as progress tracking, avatars, points, levels and challenges in a non-game context. Carlier et al.[2] conducted a comparative study of user experience with gamified and non-gamified surveys and reported that they found no difference between conditions in terms of data quality gathered but respondents of gamified surveys perceived the time taken to respond to questions as shorter than respondents of non-gamified surveys. We consider real time taken to answer the question and time spent in high cognitive load. In terms of game elements, Carlier et al. used progress tracking in gamified version and the remaining game elements were personalised to each individual. In our previous work, we investigated the personalisation of gamification design of mHealth surveys and found that the selected preferred game elements in that context do not vary strongly between individuals1 . Therefore in this work, we use a uniform version of gamified survey app across all participants selecting game elements associated with the Player archetype such as progress tracking, points, rewards and levels. This paper is available on arxiv under CC BY 4.0 DEED license. Authors: (1) Michal K. Grzeszczyk, Sano Centre for Computational Medicine, Cracow, Poland and Warsaw University of Technology, Warsaw, Poland; (2) M.Sc.; Paulina Adamczyk, Sano Centre for Computational Medicine, Cracow, Poland and AGH University of Science and Technology, Cracow, Poland; (3) B.Sc.; Sylwia Marek, Sano Centre for Computational Medicine, Cracow, Poland and AGH University of Science and Technology, Cracow, Poland; (4) B.Sc.; Ryszard Pręcikowski, Sano Centre for Computational Medicine, Cracow, Poland and AGH University of Science and Technology, Cracow, Poland; (5) B.Sc.; Maciej Kuś, Sano Centre for Computational Medicine, Cracow, Poland and AGH University of Science and Technology, Cracow, Poland; (6) B.Sc.; M. Patrycja Lelujko, Sano Centre for Computational Medicine, Cracow, Poland; (7) B.Sc.; Rosmary Blanco, Sano Centre for Computational Medicine, Cracow, Poland; (8) M.Sc.; Tomasz Trzciński, Warsaw University of Technology, Warsaw, Poland, IDEAS NCBR, Warsaw, Poland andTooploox, Wroclaw, Poland; (9) D.Sc.; Arkadiusz Sitek, Massachusetts General Hospital, Harvard Medical School, Boston, MA, USA; (10) PhD; Maciej Malawski, Sano Centre for Computational Medicine, Cracow, Poland and AGH University of Science and Technology, Cracow, Poland; (11) D.Sc.; Aneta Lisowska, Sano Centre for Computational Medicine, Cracow, Poland and Poznań University of Technology, Poznań, Poland; (12) EngD. Authors: Authors: (1) Michal K. Grzeszczyk, Sano Centre for Computational Medicine, Cracow, Poland and Warsaw University of Technology, Warsaw, Poland; (2) M.Sc.; Paulina Adamczyk, Sano Centre for Computational Medicine, Cracow, Poland and AGH University of Science and Technology, Cracow, Poland; (3) B.Sc.; Sylwia Marek, Sano Centre for Computational Medicine, Cracow, Poland and AGH University of Science and Technology, Cracow, Poland; (4) B.Sc.; Ryszard Pręcikowski, Sano Centre for Computational Medicine, Cracow, Poland and AGH University of Science and Technology, Cracow, Poland; (5) B.Sc.; Maciej Kuś, Sano Centre for Computational Medicine, Cracow, Poland and AGH University of Science and Technology, Cracow, Poland; (6) B.Sc.; M. Patrycja Lelujko, Sano Centre for Computational Medicine, Cracow, Poland; (7) B.Sc.; Rosmary Blanco, Sano Centre for Computational Medicine, Cracow, Poland; (8) M.Sc.; Tomasz Trzciński, Warsaw University of Technology, Warsaw, Poland, IDEAS NCBR, Warsaw, Poland andTooploox, Wroclaw, Poland; (9) D.Sc.; Arkadiusz Sitek, Massachusetts General Hospital, Harvard Medical School, Boston, MA, USA; (10) PhD; Maciej Malawski, Sano Centre for Computational Medicine, Cracow, Poland and AGH University of Science and Technology, Cracow, Poland; (11) D.Sc.; Aneta Lisowska, Sano Centre for Computational Medicine, Cracow, Poland and Poznań University of Technology, Poznań, Poland; (12) EngD. Table of Links Abstract and Introduction Abstract and Introduction Related Work Related Work Methods Methods Results and Discussion Results and Discussion Limitations Limitations Conclusion, Acknowledgment, and References Conclusion, Acknowledgment, and References Related work Cognitive Load Detection. To obtain a good and unobtrusive cognitive load detector, which could facilitate both development of timely context-aware reminders and the evaluation of application use effort in the wild[8], researchers considered the utilization of wearable devices and machine learning. Morkova et al.[12] used a Shimmer[3] GSR+ device attached to the participant's two fingers and an ear lobe to capture galvanic skin responses (GSR), electrocardiograms (ECG) and PPG signal of individuals during cognitively demanding tasks and neutral condition (CLAS dataset). The authors trained a person-specific Support Vector Machine (SVM) model on features extracted from GSR either paired with features extracted from ECG or PPG recordings to predict subjects' concentration. They reported average classification performance of 78% (ECG+GSR) and 74% (PPG+GSR) and commented that these performance differences were not significant and do not justify the use of ECG. Consumer-grade wearables, employed in just-in-time interventions, due to high cost and low practicality rarely are equipped with ECG and GSR sensors commonly available in devices used in experimental conditions[15]. Therefore, we focus on developing a cognitive load detector that utilizes PPG signal only, that can be captured by smartwatches. Lisowska et al.[11] use a PPG signal from CLAS dataset[12] to detect cognitive load. The authors compared the performance of SVM with a different number of features vs. simple 1D Convolutional Neural Network (1D CNN). The latter performed better, however, the achieved average cognitive load classification accuracy reached only 60%. The authors tried to improve cognitive load detection through semi-supervised model training leveraging additional unlabeled signal, however, no notable performance gains were reached. We base our solution on this approach and first investigate the limitation of the simple 1D CNN and later suggest a potential change to the training approach. We consider between-task transfer learning. Our investigation is based on the following observations: Even though deep learning approaches have been shown to outperform traditional methods utilizing handcrafted features such as SVMs in a range of applications[14], including cognitive load detection from PPG signal[8], CNN-based models are known to be data hungry and in low data regimes, they tend to be pre-trained to offer better performance[20]. Cognitive load annotations are not easy to gather and there are few datasets utilizing physiological signals from wrist-worn devices designed to capture that state. On the other hand, stress classification is a commonly tackled problem and high-quality publicly available physiological signal datasets, such as WESAD[16] (Wearable Stress and Affect Detection), provide signal paired with labels convenient for ML training. Even though deep learning approaches have been shown to outperform traditional methods utilizing handcrafted features such as SVMs in a range of applications[14], including cognitive load detection from PPG signal[8], CNN-based models are known to be data hungry and in low data regimes, they tend to be pre-trained to offer better performance[20]. Even though deep learning approaches have been shown to outperform traditional methods utilizing handcrafted features such as SVMs in a range of applications[14], including cognitive load detection from PPG signal[8], CNN-based models are known to be data hungry and in low data regimes, they tend to be pre-trained to offer better performance[20]. Cognitive load annotations are not easy to gather and there are few datasets utilizing physiological signals from wrist-worn devices designed to capture that state. On the other hand, stress classification is a commonly tackled problem and high-quality publicly available physiological signal datasets, such as WESAD[16] (Wearable Stress and Affect Detection), provide signal paired with labels convenient for ML training. Cognitive load annotations are not easy to gather and there are few datasets utilizing physiological signals from wrist-worn devices designed to capture that state. On the other hand, stress classification is a commonly tackled problem and high-quality publicly available physiological signal datasets, such as WESAD[16] (Wearable Stress and Affect Detection), provide signal paired with labels convenient for ML training. Well-being Survey Gamification. Gamification refers to the use of game elements such as progress tracking, avatars, points, levels and challenges in a non-game context. Carlier et al.[2] conducted a comparative study of user experience with gamified and non-gamified surveys and reported that they found no difference between conditions in terms of data quality gathered but respondents of gamified surveys perceived the time taken to respond to questions as shorter than respondents of non-gamified surveys. We consider real time taken to answer the question and time spent in high cognitive load. Well-being Survey Gamification. Well-being Survey Gamification. In terms of game elements, Carlier et al. used progress tracking in gamified version and the remaining game elements were personalised to each individual. In our previous work, we investigated the personalisation of gamification design of mHealth surveys and found that the selected preferred game elements in that context do not vary strongly between individuals1 . Therefore in this work, we use a uniform version of gamified survey app across all participants selecting game elements associated with the Player archetype such as progress tracking, points, rewards and levels. This paper is available on arxiv under CC BY 4.0 DEED license. This paper is available on arxiv under CC BY 4.0 DEED license. available on arxiv

Gamified Surveys and Cognitive Load Detection in mHealth: Related Work

Bitcoin being the first blockchain network and cryptocurrency, has always been celebrated as the ultimate store of value. While its decentralized and immutable nature makes it ideal for this purpose, Bitcoin's original design limits its functionality beyond basic transactions. And here is Rootstock (RSK); a Bitcoin Layer 2 solution sidechain poised that unlocks limitless potential for the Bitcoin ecosystem. In this article, I will explain why Bitcoin needs a Layer 2, the pivotal role Rootstock plays in expanding Bitcoin utility, and how it is empowering decentralized finance (DeFi), smart contracts, and more, without compromising Bitcoin core principles. The Case for Bitcoin Layer 2 Bitcoin scalability challenges are no secret. With a block time of 10 minutes and limited throughput (approximately seven transactions per second), it was never designed for the high-speed, high-volume use cases we see in modern decentralized applications (dApps). While Bitcoin is unmatched as a digital gold standard, it lacks programmability and the ability to support complex logic like smart contracts, which are essential for use cases like DeFi, gaming, and tokenized assets. A Bitcoin Layer 2 is not just a technical upgrade, it is a philosophical evolution. Layer 2 solutions operate on top of the Bitcoin mainchain, inheriting its unmatched security while providing additional scalability, functionality, and flexibility. They allow developers and users to build a robust ecosystem around Bitcoin, expanding its utility far beyond simple payments. Rootstock: The Smart Contract Layer for Bitcoin Rootstock is a leading Layer 2 solution; a sidechain designed to merge Bitcoin security with Ethereum-like smart contract capabilities. Built as a sidechain to Bitcoin, Rootstock connects directly to the Bitcoin blockchain while adding a Turing-complete virtual machine (the Rootstock Virtual Machine, or RVM) that enables developers to write and deploy smart contracts. Here is why Rootstock stands out as a transformative force in the Bitcoin ecosystem: 1. Leverages Bitcoin Security Rootstock is anchored to the Bitcoin network through merged mining. Miners who secure the Bitcoin blockchain can simultaneously validate transactions on Rootstock, ensuring Rootstock inherits Bitcoin's unparalleled security while incentivizing miners with additional rewards. 2. Brings Smart Contracts to Bitcoin By integrating a version of the Ethereum Virtual Machine (EVM), Rootstock enables Bitcoin to support decentralized applications. This opens the door for use cases like DeFi, NFTs, gaming, and tokenized assets, all built on Bitcoin. 3. Seamless Two-Way Peg Rootstock's two-way peg system allows users to seamlessly transfer BTC to the Rootstock sidechain as RBTC, a 1:1 Bitcoin-backed token. This bridges Bitcoin liquidity to the Rootstock network, enabling the use of BTC in smart contract applications without leaving the ecosystem. 4. Scalability and Efficiency Rootstock significantly increases transaction throughput compared to Bitcoin’s base layer. Transactions on Rootstock are faster and cheaper, making it ideal for high-frequency applications like DeFi trading or microtransactions. Putting Bitcoin to Work: Real-World Applications of Rootstock Rootstock is not just theoretical; it is actively unlocking new use cases for Bitcoin, enabling the network to become a hub for innovation. Here is how: 1. Decentralized Finance (DeFi) DeFi has exploded in recent years, but most of its growth has occurred on Ethereum and other programmable chains. Rootstock brings this opportunity to Bitcoin. Platforms like Money on Chain (a stablecoin protocol) and Sovryn (a decentralized trading and lending platform) leverage Rootstock to create DeFi products secured by Bitcoin. This means Bitcoin holders can now earn yields, borrow, and lend without trusting centralized entities. 2. Tokenization Rootstock enables the creation of tokens backed by real-world assets, such as real estate or commodities, directly on the Bitcoin network. This expands Bitcoin’s utility as a base layer for a global financial ecosystem. 3. DAOs and Governance With Rootstock, Bitcoin can support Decentralized Autonomous Organizations (DAOs) that use smart contracts for governance and decision-making. Imagine a future where Bitcoin communities govern funds and projects democratically, all on-chain. 4. Identity and Reputation Systems Rootstock smart contracts can facilitate decentralized identity (DID) and reputation systems, laying the groundwork for trustless, self-sovereign identities anchored to Bitcoin. These systems could power use cases ranging from credit scoring to community-based voting. 5. Payment Channels While Bitcoin’s Lightning Network focuses on microtransactions, Rootstock complements this with programmable logic for payment channels. Businesses can automate recurring payments, escrow services, or conditional transfers directly on Rootstock. Why Rootstock Matters for The Future of Bitcoin Bitcoin's decentralized and censorship-resistant nature has made it the reserve asset of the crypto world, but this strength also limits its adaptability. Rootstock bridges this gap, allowing Bitcoin to participate in the programmable, DeFi-driven economy while remaining true to its ethos. By building on Bitcoin, Rootstock ensures that innovation in the ecosystem remains tied to the most secure and decentralized network in the world. This synergy creates a feedback loop: as more applications leverage Bitcoin liquidity and security through Rootstock, they attract new users and strengthen the network. The Road Ahead: Bitcoin Beyond a Store of Value Rootstock represents a paradigm shift for Bitcoin, transforming it from a passive store of value to an active participant in the broader blockchain ecosystem. As more developers, entrepreneurs, and users explore Rootstock capabilities, we are likely to see a wave of innovation that challenges the dominance of other smart contract platforms. For Bitcoin enthusiasts, Rootstock is an opportunity to see their favorite network evolve without compromising its core principles. For developers, it’s an invitation to build on the world's most secure blockchain. And for the crypto industry as a whole, it is proof that the Bitcoin story is far from over—it is just getting started. Bitcoin doesn’t need to be “fixed”; it needs to be unlocked. And Rootstock is the key. See You At $100,000 Bitcoin being the first blockchain network and cryptocurrency, has always been celebrated as the ultimate store of value. While its decentralized and immutable nature makes it ideal for this purpose, Bitcoin's original design limits its functionality beyond basic transactions. And here is Rootstock (RSK); a Bitcoin Layer 2 solution sidechain poised that unlocks limitless potential for the Bitcoin ecosystem. In this article, I will explain why Bitcoin needs a Layer 2, the pivotal role Rootstock plays in expanding Bitcoin utility, and how it is empowering decentralized finance (DeFi), smart contracts, and more, without compromising Bitcoin core principles. The Case for Bitcoin Layer 2 The Case for Bitcoin Layer 2 Bitcoin scalability challenges are no secret. With a block time of 10 minutes and limited throughput (approximately seven transactions per second), it was never designed for the high-speed, high-volume use cases we see in modern decentralized applications (dApps). While Bitcoin is unmatched as a digital gold standard, it lacks programmability and the ability to support complex logic like smart contracts, which are essential for use cases like DeFi, gaming, and tokenized assets. A Bitcoin Layer 2 is not just a technical upgrade, it is a philosophical evolution. Layer 2 solutions operate on top of the Bitcoin mainchain, inheriting its unmatched security while providing additional scalability, functionality, and flexibility. They allow developers and users to build a robust ecosystem around Bitcoin, expanding its utility far beyond simple payments. Rootstock: The Smart Contract Layer for Bitcoin Rootstock: The Smart Contract Layer for Bitcoin Rootstock is a leading Layer 2 solution; a sidechain designed to merge Bitcoin security with Ethereum-like smart contract capabilities. Built as a sidechain to Bitcoin, Rootstock connects directly to the Bitcoin blockchain while adding a Turing-complete virtual machine (the Rootstock Virtual Machine, or RVM) that enables developers to write and deploy smart contracts. Here is why Rootstock stands out as a transformative force in the Bitcoin ecosystem: Here is why Rootstock stands out as a transformative force in the Bitcoin ecosystem: 1. Leverages Bitcoin Security Leverages Bitcoin Security Rootstock is anchored to the Bitcoin network through merged mining. Miners who secure the Bitcoin blockchain can simultaneously validate transactions on Rootstock, ensuring Rootstock inherits Bitcoin's unparalleled security while incentivizing miners with additional rewards. 2. Brings Smart Contracts to Bitcoin Brings Smart Contracts to Bitcoin By integrating a version of the Ethereum Virtual Machine (EVM), Rootstock enables Bitcoin to support decentralized applications. This opens the door for use cases like DeFi, NFTs, gaming, and tokenized assets, all built on Bitcoin. 3. Seamless Two-Way Peg Seamless Two-Way Peg Rootstock's two-way peg system allows users to seamlessly transfer BTC to the Rootstock sidechain as RBTC, a 1:1 Bitcoin-backed token. This bridges Bitcoin liquidity to the Rootstock network, enabling the use of BTC in smart contract applications without leaving the ecosystem. 4. Scalability and Efficiency Scalability and Efficiency Rootstock significantly increases transaction throughput compared to Bitcoin’s base layer. Transactions on Rootstock are faster and cheaper, making it ideal for high-frequency applications like DeFi trading or microtransactions. Putting Bitcoin to Work: Real-World Applications of Rootstock Putting Bitcoin to Work: Real-World Applications of Rootstock Rootstock is not just theoretical; it is actively unlocking new use cases for Bitcoin, enabling the network to become a hub for innovation. Here is how: 1. Decentralized Finance (DeFi) 1. Decentralized Finance (DeFi) DeFi has exploded in recent years, but most of its growth has occurred on Ethereum and other programmable chains. Rootstock brings this opportunity to Bitcoin. Platforms like Money on Chain (a stablecoin protocol) and Sovryn (a decentralized trading and lending platform) leverage Rootstock to create DeFi products secured by Bitcoin. This means Bitcoin holders can now earn yields, borrow, and lend without trusting centralized entities. 2. Tokenization 2. Tokenization Rootstock enables the creation of tokens backed by real-world assets, such as real estate or commodities, directly on the Bitcoin network. This expands Bitcoin’s utility as a base layer for a global financial ecosystem. 3. DAOs and Governance 3. DAOs and Governance With Rootstock, Bitcoin can support Decentralized Autonomous Organizations (DAOs) that use smart contracts for governance and decision-making. Imagine a future where Bitcoin communities govern funds and projects democratically, all on-chain. 4. Identity and Reputation Systems 4. Identity and Reputation Systems Rootstock smart contracts can facilitate decentralized identity (DID) and reputation systems, laying the groundwork for trustless, self-sovereign identities anchored to Bitcoin. These systems could power use cases ranging from credit scoring to community-based voting. 5. Payment Channels 5. Payment Channels While Bitcoin’s Lightning Network focuses on microtransactions, Rootstock complements this with programmable logic for payment channels. Businesses can automate recurring payments, escrow services, or conditional transfers directly on Rootstock. Why Rootstock Matters for The Future of Bitcoin Why Rootstock Matters for The Future of Bitcoin Bitcoin's decentralized and censorship-resistant nature has made it the reserve asset of the crypto world, but this strength also limits its adaptability. Rootstock bridges this gap, allowing Bitcoin to participate in the programmable, DeFi-driven economy while remaining true to its ethos. By building on Bitcoin, Rootstock ensures that innovation in the ecosystem remains tied to the most secure and decentralized network in the world. This synergy creates a feedback loop: as more applications leverage Bitcoin liquidity and security through Rootstock, they attract new users and strengthen the network. The Road Ahead: Bitcoin Beyond a Store of Value The Road Ahead: Bitcoin Beyond a Store of Value Rootstock represents a paradigm shift for Bitcoin, transforming it from a passive store of value to an active participant in the broader blockchain ecosystem. As more developers, entrepreneurs, and users explore Rootstock capabilities, we are likely to see a wave of innovation that challenges the dominance of other smart contract platforms. For Bitcoin enthusiasts, Rootstock is an opportunity to see their favorite network evolve without compromising its core principles. For developers, it’s an invitation to build on the world's most secure blockchain. And for the crypto industry as a whole, it is proof that the Bitcoin story is far from over—it is just getting started. Bitcoin doesn’t need to be “fixed”; it needs to be unlocked. And Rootstock is the key. See You At $100,000 Bitcoin doesn’t need to be “fixed”; it needs to be unlocked. And Rootstock is the key. See You At $100,000

Stories, News & Mentions about MWORK

Mwork’s Stories on HackerNoon

Mwork's News & Mentions