DEV Community: jzombie

Moving Away from Evernote: A Simpler Solution for Those with ADD

jzombie — Wed, 19 Jul 2023 02:12:04 +0000

As someone living with ADD, maintaining focus and productivity is crucial. Unfortunately, my experience with Evernote has been more of a hindrance than a help. The constant interruptions by paywalls not only disrupt my workflow but also make me forget why I was using the app in the first place. It's as if the app is more interested in monetizing than in providing a seamless user experience.

Maybe it's time to consider other options.

The Downfalls of Evernote

Poor Performance and Buggy App: Evernote has become slow and buggy over time, affecting my productivity and overall user experience. This could be due to outdated technology or lack of optimization, but either way, it's a significant drawback.
Syncing Issues: Note synchronization across different devices, a critical feature for a note-taking app, has become unreliable. This has significantly impacted my trust in the app and its reliability.
Restrictive Device Limitations: Evernote has imposed restrictions on the number of devices that can be used simultaneously on certain plans. This has been frustrating as I often need to access my notes across multiple devices.
Pricing and Monetization Strategy: Evernote's pricing strategy has changed over time, and not for the better. The value I get from the service no longer justifies the cost - and I'm not even paying for it.
Loss of Core Features: Evernote has removed or limited some of its core features, such as the ability to export notes and the inclusion of reminders without needing to connect to Google or Outlook.
Lack of Innovation: While competitors have introduced new features and integrations, Evernote seems to be stuck in time. The company doesn't appear to be innovating or updating its service to keep up with user expectations and market trends.
Leadership Changes: Frequent changes in leadership have led to inconsistency in vision and strategy, which may have contributed to some of the issues I've experienced with Evernote.

The Simplicity and Efficiency of Markdown

In light of these issues, I've decided to switch to a simpler, more efficient solution: a markdown format in a GitHub repo. Here's why:

Simplicity: Markdown is easy to learn and use. It's a straightforward way to format text, without the need for complex tools or software.
Flexibility: With markdown, I can create and edit notes on any device. There are no device limitations or syncing issues to worry about.
Control: Using a GitHub repo for my notes gives me complete control over my data. I can easily export my notes, and I don't have to worry about changes in pricing or features.
Collaboration: GitHub makes it easy to collaborate with others, whether it's sharing notes or working on a project together.
Version Control: With GitHub, every change is tracked. This means I can see the history of my notes and easily revert back to a previous version if needed.

In conclusion, while Evernote has its merits, the recent issues have made it clear that it's not the best solution for me. By switching to a markdown format in a GitHub repo, I'm hoping to simplify my note-taking process and improve my productivity. If you're also frustrated with Evernote, it might be worth considering a similar switch.

Understanding Open-Source Licenses: A Comparative Guide

jzombie — Sun, 09 Jul 2023 20:26:51 +0000

Preface
- Why Create Open-Source?
- Choosing an Appropriate License
MIT License
Apache License 2.0
GNU General Public License (GPL)
GNU Lesser General Public License (LGPL)
BSD Licenses
Mozilla Public License 2.0
Creative Commons Licenses
Summary
Additional Resources
Conclusion
Disclaimer
Stay Connected for More!

Preface

When you're unaware of the rules, it becomes impossible to knowingly break them.

Why Create Open-Source?

Open-source software provides valuable benefits for individuals and the software ecosystem. It fosters community-driven innovation, leveraging the collective intelligence and creativity of diverse developers. This collaborative approach leads to faster iterations, increased reliability, and the ability to solve complex challenges more effectively.

Contributing to open-source projects is a long-term investment. Your contributions have a lasting impact, benefiting the project and its users over time. Additionally, active participation in open-source projects helps you enhance your skills, gain practical experience, and build a strong reputation within the developer community.

Open-source software offers flexibility and adaptability. Access to the source code allows developers to customize and tailor the software to specific needs, empowering them to shape the technology according to requirements. The vibrant ecosystems surrounding open-source projects provide a wide range of complementary tools and resources, further expanding the software's potential.

Choosing an Appropriate License

Choosing the correct open-source license, however, can be a complex task. Different licenses have specific terms and conditions that govern how the software can be used, modified, and distributed. It's crucial to carefully evaluate and select the appropriate license that aligns with your project's goals and ensures the desired level of openness and collaboration.

Open source licenses are legal and binding contracts between the creator and the user of the software. They dictate how the software can be used, modified, and distributed. In this article, we'll explore the key differences between some of the most popular open source licenses.

MIT License

The MIT License is one of the most permissive open-source licenses. It allows users to do almost anything with the code, provided that the original license and copyright notice are included. This includes using, copying, modifying, merging, publishing, distributing, sublicensing, and/or selling copies of the software.

Example Scenario:

You're developing a library that you want others to use freely in their own projects, without any obligation to disclose their source code or to use the same license. For example, you've created a new data visualization library in JavaScript and you want it to be as accessible and reusable as possible.

Apache License 2.0

The Apache License 2.0 is similar to the MIT License, but it also includes an explicit grant of patent rights from contributors to users. It also has a more robust set of conditions, including a requirement to include a copy of the license and any notices in all copies of the software.

Example Scenario:

You're developing a software that may have patentable technology and you want to protect contributors and users from patent litigation. For instance, you're creating a new machine learning algorithm that could potentially be patented, but you want the open-source community to be able to use and contribute to it without fear of patent claims.

GNU General Public License (GPL)

The GPL is a copyleft license, meaning that any derivative work must be distributed under the same license terms. This ensures that any modifications or improvements made to the software are also made available to the community. There are different versions of the GPL, with the GPLv3 being the most recent and comprehensive.

Example Scenario:

You're developing a software and you want any derivative work to be open sourced under the same license. For example, you're creating a new operating system and you want to ensure that all modifications and improvements made by others are also made freely available to the community.

GNU Lesser General Public License (LGPL)

The LGPL is a more permissive version of the GPL. It allows you to link to an LGPL library in your software without having to release your software under the LGPL. This makes it a popular choice for libraries and other reusable components.

Example Scenario:

You're developing a library and you want others to use it in their own projects, even if they are not open-source, but any changes to your library itself must be open sourced. For instance, you're creating a new image processing library and you want it to be usable in both open-source and proprietary software, but any improvements to the library itself should be shared.

BSD Licenses

There are several versions of the BSD license, but they all have in common a high degree of permissiveness. The main difference between the BSD licenses and the MIT License is in the handling of advertising materials and endorsements.

Example Scenario:

You're developing a software that you want others to use freely with minimal restrictions, even in proprietary software, but they must retain your copyright notice. For example, you've created a new database management system and you want it to be as accessible as possible, but you want your contribution to be acknowledged.

Mozilla Public License 2.0

The Mozilla Public License 2.0 is a compromise between the permissive MIT License and the copyleft GPL. It allows you to freely use, modify, and distribute the software, but any modifications you make must be made available under the same license.

Example Scenario:

You're developing a software and you want to allow others to use, modify, and distribute the original or modified versions of the software under their own license, but they must disclose changes made to your code. For instance, you're creating a new web browser and you want to encourage both open-source and proprietary derivatives, but changes to your code must be shared.

Creative Commons Licenses

While not typically used for software, Creative Commons licenses are popular for other types of open content like documentation, images, and music. They offer a range of options from very permissive (CC BY) to more restrictive (CC BY-NC-ND).

Example Scenario:

You're creating content like documentation, images, or music that you want to share with the community under certain conditions. For example, you've written a comprehensive guide on using a particular software and you want others to be able to use, share, and build upon your guide, but they must give you credit and they can't use it for commercial purposes.

Summary

MIT License: Highly permissive, allows almost any action with the software, provided the original license and copyright notice are included.
Apache License 2.0: Similar to MIT but includes an explicit grant of patent rights and requires inclusion of the license and any notices in all copies of the software.
GNU General Public License (GPL): A copyleft license that requires any derivative work to be distributed under the same license terms.
GNU Lesser General Public License (LGPL): A more permissive version of the GPL, allows linking to an LGPL library in your software without having to release your software under the LGPL.
BSD Licenses: Highly permissive like MIT, but with different handling of advertising materials and endorsements.
Mozilla Public License 2.0: A compromise between the permissive MIT License and the copyleft GPL, requires modifications to be made available under the same license.
Creative Commons Licenses: Not typically used for software, but popular for other types of open content, offers a range of options from very permissive to more restrictive.

Additional Resources

Here are some resources that might help you navigate through open-source licensing:

Full Service Free and Open Source Software Counseling: This firm specializes in helping companies implement a long-term, customized open source compliance strategy.
Open-Source Licensing Lawyer - Kronenberger Rosenfeld, LLP: Their lawyers have an extensive technical background as open-source contributors, enabling them to provide personalized counsel for your matter.
Open Source Licensing - Losey PLLC: They offer services related to open source licensing, including use, copy, modify, and distribute software.
Open Source Software Licenses: Novel Case Explores Who Can ...: This article from Orrick discusses a case that may broaden open-source license enforcement and disclosure.
Developer's Guide to Open Source Licenses - Toptal: This guide from Toptal provides a comprehensive overview of some of the most popular open-source licenses, and several rules of thumb to follow when choosing a license.

Please note that the price, effectiveness, and quality of these services may vary, and it would be best to contact these organizations directly for more specific information.

Conclusion

Choosing the right open-source license for your project is a critical decision. It's important to understand the implications of each license and to consider your goals for the project. Do you want to encourage wide usage and adaptation, or do you want to ensure that all modifications are made freely available? The answer to this question will guide you towards the license that's right for you.

It's important to note that this list is not exhaustive and serves as a simplified overview of some available resources. It should not be interpreted as legal advice. For decisions related to software licensing, it's always recommended to consult with a legal professional.

Disclaimer: The information provided in this article is for informational purposes only and should not be considered legal advice. It is essential to conduct thorough research and review the appropriate licenses in their entirety before making any decisions regarding open-source licenses. I am not an attorney, and therefore, I cannot be held responsible for any errors, inaccuracies, or omissions in this article. Always consult with a qualified legal professional for specific legal advice related to open-source licensing matters.

Stay Connected for More!

Thanks for reading! If you enjoyed this article and want to see more of my work, be sure to check out my GitHub profile at github.com/zenosmosis. Don't forget to give it a ⭐️ if you find it helpful!

You can also find me on LinkedIn and Hacker News.

Happy coding!

Jasmine-based Ubiquitous Test Runner for Shared Codebases

jzombie — Sun, 06 Nov 2022 06:23:59 +0000

Sometimes you may need to write code which runs in a browser as well as Node.js, and most test runners do not support this functionality out of the box, in order to run unit tests across all environments without duplicating the tests per environment.

So I made a little project with the number one goal of being a "ubiquitous" test runner, running tests against real browsers as well as Node.js w/o modifying tests to run between environments.

https://github.com/zenOSmosis/karma-jasmine-typescript-boilerplate

Why not Playwright, Jest, or...?

Ubiquity: Test code in multiple environments without duplicating test cases or using multiple runners.

The goals of this project are to execute the testing code directly in the individual environments w/o using a web driver. This way, the same tests can execute across all major browsers as well as Node.js.

This use case might not be suitable for all projects but makes it better suited for code that is intended to run across all environments: i.e. algorithms, custom WebSocket implementations, etc.

So tests like the following can run regardless of which environment they are in, w/o needing to be eval-ed through a web driver message request.

import {fibonacci, isBrowser} from "../src/index";

describe("basic tests", () => {
  it("determines if running in browser", () => {
    expect(isBrowser()).toBe(typeof window !== undefined);
  });

  it("generates fibonacci", () => {
    expect(fibonacci(10)).toEqual([0, 1, 1, 2, 3, 5, 8, 13, 21, 34, 55]);
  });
});

Take a look at the included tests for more examples as well as the example CI pipeline.

More information is below regarding additional considerations for Jest.

Running Tests

Note, the default configuration runs the same tests across the environments you choose.

Browser and Node tests:

$ npm run test

Browser-only tests:

$ npm run test:browser

Node-only tests:

$ npm run test:node

Test Coverage Reporting

Code coverage is provided by Istanbul.

Default settings are as follows:

Browser code coverage is generated automatically and placed in {root}/coverage as HTML files
Node.js test coverage reports are placed in .nyc_output as JSON files

Some Credits

Portions of this were borrowed from:

https://github.com/piecioshka/boilerplate-jasmine-typescript (for Node.js configuration)
https://github.com/monounity/karma-typescript/tree/master/packages/karma-typescript (for Karma / browser configuration)
https://github.com/google/karma-webkit-launcher (for helping fix flaky Safari tests)
https://www.freecodecamp.org/news/jasmine-unit-testing-tutorial-4e757c2cbf42/ (for helping w/ Jasmine tests)

Misc

As much as I'd like to try to get Jest to work instead (for running tests in a browser as well), here's a thread that indicates it may be a bit difficult to accomplish: https://github.com/facebook/jest/issues/139

This post shows some polyfills to sort of fake it: https://github.com/tom-sherman/blog/blob/main/posts/02-running-jest-tests-in-a-browser.md

Playwright was also added as a dependency to help locate the WebKit bin path on the host system (see: Headless Webkit with Playwright).

Roadmap

In the future I'd like to add configuration options for BrowserStack and potentially Sauce Labs.

"Most Useless Demo Ever" Deepgram Hackathon Submission

jzombie — Mon, 11 Apr 2022 12:49:00 +0000

Overview of My Submission

Utilizing Deepgram as a virtual speech input in a web desktop.

https://github.com/zenOSmosis/reshell

Submission Category:

Wacky Wildcards

Link to Code on GitHub

https://github.com/zenOSmosis/reshell

Additional Resources / Info

Video of the most useless demo ever: https://user-images.githubusercontent.com/1139657/162651792-32cb216c-2257-40f5-a75d-0b2062b65897.mov

Introduction

This is a project that I actually take great pride in, however, when trying to balance development time with my full-time job as well as spending time with my family, I wasn't able to complete the project to my satisfaction, so I called it, "The Most Useless Demo Ever."

My Deepgram Use-Case

For several years some buddies and I have been talking about using virtual speech inputs in some programs that we are writing. And we've done that with varying degrees of success.

I've personally had a strong desire to make a web desktop over the past 10 years or so which is inspired by many concepts in Unix-based operating systems.

So I'm presenting the largely incomplete ReShell desktop system which features mobile and desktop paradigm support.

There are several variants of this desktop, some of which are dedicated for peer-to-peer (P2P) calling.

In time, these multiple variants will converge into a single "portal" and become decentralized, where users can bring their own backends.

This Deepgram submission is basically my way of saying, "we support voice, are supporting multiple input interfaces, and we have a long road ahead."

Conclusion

In our UI, I've integrated Deepgram and Azure's speech recognition services, and they can be run concurrently. If wanting more feedback as to the pros / cons of each and what I have experienced, feel free to reach out to me.

You can find me on LinkedIn at: https://www.linkedin.com/in/jeremyharrisconsultant/

Taking Grammarly for a Test-Drive

jzombie — Tue, 29 Mar 2022 02:28:54 +0000

I signed up for Grammarly to improve my writing skills and am testing it on the Speaker.app verbiage, a project I have notoriously gone overboard with trying to describe.

Speaker.app is a batteries-included, quasi-decentralized, alternative free speech audio platform compatible with any device that supports a modern web browser.

A Virtual Server in your Browser

Speaker.app utilizes virtual server technology to route group calls and form virtual networks.

To host a call, one participant's device acts as the network host, to which all of the other callers connect directly.

Ephemeral Networks

Messages and other media will pass through this host participant's device. If the device goes offline, the network and its history are gone.

No User Accounts

No user accounts or passwords are required to join a public network. User identities are generated using Ethereum, with a randomized user profile, by default. Users can change their description to their liking, while their profile information is stored locally via local storage.

Inspiration to Create this Project

I was faced with building a WebRTC bridge between two third-party services in the virtual healthcare industry. After some initial experimentation, I discovered that using a headless Chrome server was the path of least resistance. Fewer bugs were present at the expense of it not being exceptionally efficient.

However, the idea was compelling enough for me to continue exploring and scale it out as efficiently as possible with limited resources. The idea to use the client browser as a virtual server was born.

Azure Trial Hackathon - Speech Controlled Web Desktop

jzombie — Tue, 08 Mar 2022 23:48:49 +0000

Overview of My Submission

A web-based desktop, called "ReShell", which responds to your voice.

ReShell is a web-based desktop & mobile user interface featuring individual "portals," or collections of apps.

ReShell extends Create React App with a window management system, multiple portal handling, some core applications and utilities, and utilizes Google's zx JavaScript Bash replacement utility to do some file system management.

Submission Category:

Wacky Wildcards

Link to Code on GitHub

zenOSmosis / reshell

ReShell is a web-based desktop & mobile user interface featuring individual "portals," or collections of apps, based on the PhantomCore library.

ReShell - Web Desktop and UI Service Engine

This is a work in progress, subject to many API updates and feature regressions in a short amount of time, as it is used for development and prototyping of several applications at once.

ReShell is a web-based desktop & mobile user interface featuring individual "portals," or collections of apps, based on the PhantomCore library.

Project Goals

Stable and efficient on desktop and mobile
Base portal UI should never require a backend to be present (specific portals may require one as necessary); should be easily distributable across multiple channels for a variety of frontend-related needs, from small to large projects
Try not to break Create React App nor get too clever
…

View on GitHub

Additional Resources / Info

Video demonstrating speech control -
https://user-images.githubusercontent.com/1139657/157443171-d35decb7-5fd2-460d-b95e-cae7d7b28a80.mov

Source Code

Demo

A WebRTC server in your browser (virtual server; private audio)

jzombie — Thu, 30 Sep 2021 15:10:07 +0000

Speaker.app / zenRTC / Phantom Server

Source Code available on GitHub

Speaker.app is a batteries-included, quasi-decentralized, alternative free speech audio platform that is compatible on any device that supports a modern web browser.

Rather than a centralized server providing proxying of streams from each participant to other participants (i.e. an MCU / SFU), one can choose to host a network (or "room") where others can connect to, either publicly or privately. The network hosting participant's web browser acts as the "server" for the other participants to connect to on the given network, and all proxying is done, including message storage and relaying, through that browser.

Public networks are visible in a "network discovery" view, which serves as the default homepage for the application.

No user accounts or passwords are required to join a public network, and user identities are generated using Ethereum, with a randomized user profile, by default. Users can change their user profile to their liking, while their profile information is stored locally via local storage.

To see it live, navigate to https://speaker.app.

Speaker.app / zenRTC / Phantom Server
- Table of Contents
- Browser Support Matrix
- What's in the Box
- Architecture Overview
- Conventional WebRTC Network Topologies
- Speaker.app Peer-Based Network Topology
- Inspiration to Create this Project
- Getting Started
- Dependencies / System Requirements
- Building and Running
- Public Network Discovery / Private Networks
- Testing
- Contributing / Forking
- Troubleshooting / Miscellaneous
- Invalid MongoDB Permissions (or some other missing environment variable)
- Invalid Elf header (farmhash)
- Error: ENOSPC: System limit for number of file watchers reached
- Linux check CPU speed
- Auto-Generate Markdown Table of Contents
- Motto
- Help Us Continue Writing Free Software
- License

Browser Support Matrix

	Chrome	Edge (Chromium)	Firefox	Safari	IE
Android	✓	✓	✓	N/A	N/A
iOS	[transcoder host only]	N/A	N/A	✓	N/A
Linux	✓	✓	✓	N/A	N/A
macOS	✓	✓	✓	✓	N/A
Windows	✓	✓	✓	N/A	N/A

Note, on every OS except iOS, Chrome is the recommended browser; On iOS, Safari should be used.

What's in the Box

Frontend: Built with create-react-app; state is managed with multiple Providers and accessible via useContext hooks.

Backend: Node.js app, using Socket.io and Express. Cluster module is utilized to utilize multiple CPUs and a Redis store is utilize to scale Socket.io across the CPUs.

Redis: Utilized with Socket.io's Redis adapter to provide scalability of Socket.io across a cluster of Node.js running in different processes or servers, so they can all communicate, broadcast, and emit events to and from one another. This is mostly used in conjunction with the signaling layer to initiate WebRTC sessions & media, and most private communication happens over WebRTC data channels.

MongoDB: Network details (name, host, number of participants) are stored in MongoDB. When in development mode, Mongo Express is available at http://localhost:8081, and provides a web-based administrative interface.

Let's Encrypt: Free SSL certificates are managed via the linuxserver.io/docker-swag Docker image.

dev-ssl-proxy: In development, a self-signed SSL proxy is utilized in replacement of Let's Encrypt, to enable local development with SSL turned on (cam / mic / other HTML5-related APIs which require SSL by default).

Coturn: A STUN / TURN server for WebRTC NAT traversal is included in the Docker Compose configuration, but is not enabled by default.

Included WebRTC Experiments: Within the source code are some previous real-time, shared experience experiments such as a drum looper, a sound sampler (play piano / electric guitar w/ keyboard), text-to-speech, TensorFlow-based skeletal tracker, and a game emulator.

These experiments are mostly dormant and commented-out, but have made for some interesting demos in the past and may be re-enabled in the future.

Architecture Overview

Conventional WebRTC Network Topologies

Mesh network example. (Illustration borrowed from simple-peer)

Most group-based WebRTC calls, which don't have a centralized MCU / SFU rely on each peer to send out an extra stream to multiple peer. This is not very efficient as for every participant added, every device connected must send out additional streams.

Centralized MCU / SFU example.

More advanced calling platforms utilize a centralized MCU / SFU. While this is more efficient in terms of the network, additional considerations, and money, are needed in order to scale out the backend infrastructure.

Speaker.app Peer-Based Network Topology

Using a topology similar to the MCU / SFU example above, Speaker.app attempts to solve the scalability issue without throwing a lot of extra money into hosting fees, by enabling individual participants to host their own networks, on their own hardware, using their own bandwidth, while at the same time providing greater privacy and flexibility.

zenRTC (built with simple-peer) is based on WebRTC, adding additional functionality such as user-level network strength indication, events over data channels, and P2P-based shared state syncing.

Phantom Server is a network host which runs in your web browser, and acts as the host, shared state manager, proxy, and transcoder for all connected participants within a WebRTC network.

Every participant connects to the Phantom Server via a P2P connection and Phantom Server handles the stream negotiations / network programming with the other peers.

Speaker.app is able to provide a quasi-decentralized MCU / SFU by enabling clients to run them in their own browsers, as a virtual machine.

At the time of writing the Chrome on the Apple M1 processor is by far the most efficient for doing browser-based streaming transcoding, compared to a variety of Intel processors which have been tested on, though development has mostly been done on Intel processors / Linux. ARM is the future, it seems.

Network hosting has also been tested on non-optimal hardware (i.e. 2018 Samsung J2; Intel i3) with adequate results for streaming 4K video streams to 4 participants. Good hardware such as the new Apple M1 processor allows much greater yields, and better scalability.

Inspiration to Create this Project

TLDR; Experimentation.

I was faced with a task for building a WebRTC bridge between two third party services in the virtual healthcare industry and after trying some various approaches, discovered that using a headless Chrome instance on the server was the path of least effort and less bugs to squash, though not necessarily being greatly efficient on its own.

Running a headless Chrome instance on the server is very versatile, in being that you've got a really solid WebRTC implementation baked in, with the ability to mix audio and video streams using JavaScript and the real DOM.

Wanting to continue pursuing the effort of a script-able WebRTC bridge using a web browser, and thinking of ways to potentially scale such a system, I made the decision to allow client-side devices to host these sessions, now no longer utilizing the headless Chrome instances as the main method of hosting sessions.

Getting Started

NOTE: If you wish to host your own network (or room) you DO NOT HAVE TO DO this, and can instead go https://speaker.app/setup/network/create and create your own network!

The following is ONLY if you wish to host the entire infrastructure yourself.

Dependencies / System Requirements

All environments require

Bash (Unix shell) If running the included Bash build scripts
Docker
Docker Compose

Development environments require

Node.js 12+

Recommended system requirements

The following should get the system up and running, though additional resources may be required for higher traffic environments. Presumably, these minimum requirements should host at least several dozen people concurrently before needing to add more RAM.

2048 MB RAM (1048 MAY work if Coturn server is hosted separately)
Two CPU cores (one should work just fine for low traffic environments)

Building and Running

Some Bash scripts have been provided to help facilitate the starting and stopping of the respective environments. It is recommended to use these scripts instead of calling the Docker commands directly, as they will provide supplemental environment variables as well as any additional build instructions.

In development environments, most of the container volumes have a mount directly to the host so that the source code can be updated in the containers without rebuilding. See the respective docker.compose*.yml configurations and corresponding Dockerfile files for more details.

Set up the environment

Copy the sample environment.

$ cp .env.sample .env

Then populate .env with the configuration relevant to your environment.

Note that other environment variables are set within the docker-compose*.yml files and are intended to be considered static.

To build the Docker containers

Note that development environments may require additional dependencies to be installed.

IMPORTANT: If you are using a shell other than Bash, the following scripts should be proceeded with the "bash" command (i.e. "bash ./build.prod.sh").

$ ./build.prod.sh # Or ./build.dev.sh, depending on environment

To start the containers

$ ./start.prod.sh # Or ./start.dev.sh, depending on environment

To stop the containers

This stops the containers and tears down their temporary storage.

$ ./stop.sh # Stops any environment

Public Network Discovery / Private Networks

Public networks can be discovered on the default home page. Private networks do not appear in the public network discovery but can be accessed via URL or QR code.

Testing

Testing can be performed by running:

$ ./test.sh

Note, development packages will be automatically installed locally when testing.

At this time, testing is not fully automated. Several internal utilities are tested using Jest (via the above command), while device-specific testing is performed manually using BrowserStack.

Contributing / Forking

Source-code contributions and forks are welcome!

Open an issue if you find something that needs to be addressed that you aren't going to address yourself.

For ideas of what to contribute, take a look at our open issues.

To contribute, fork the repository, create a new branch, add some code or documentation updates, then submit a PR.

Motto

To contribute, however slightly, to the commonwealth of all human innovation and experience.

Help Us Continue Writing Free Software

PayPal: https://www.paypal.com/paypalme/zenOSmosis

Buy Me a Coffee: https://www.buymeacoffee.com/Kg8VCULYI

License

GNU GENERAL PUBLIC LICENSE

Source Code

Source Code available on GitHub

Using Docker for a local HTTPS proxy

jzombie — Sat, 07 Aug 2021 17:58:24 +0000

Sometimes when you're developing locally, you might need to use HTTPS, and might not have that tooling available in your framework of choice.

So I created this small Docker container which essentially creates a self-signed SSL certificate and uses nginx as a reverse proxy to pipe your request to whatever address you want to.

To use:

clone the repo (https://github.com/zenOSmosis/docker-dev-ssl-proxy)

$ git clone https://github.com/zenOSmosis/docker-dev-ssl-proxy

enter the repo directory

$ cd docker-dev-ssl-proxy

run the following (replacing "http://localhost:8080" with your desired proxy-to address)

$ docker run --net=host -e PROXY_ADDRESS="http://localhost:8080" docker-dev-ssl-proxy

Then navigate to https://localhost in your browser

(The address you've defined in PROXY_ADDRESS will be proxied through to https://localhost.)

Note: For production usage, you might want to check out: https://github.com/linuxserver/docker-swag

DEV Community: jzombie

Moving Away from Evernote: A Simpler Solution for Those with ADD

The Downfalls of Evernote

The Simplicity and Efficiency of Markdown

Understanding Open-Source Licenses: A Comparative Guide

Preface

Why Create Open-Source?

Choosing an Appropriate License

MIT License

Example Scenario:

Apache License 2.0

Example Scenario:

GNU General Public License (GPL)

Example Scenario:

GNU Lesser General Public License (LGPL)

Example Scenario:

BSD Licenses

Example Scenario:

Mozilla Public License 2.0

Example Scenario:

Creative Commons Licenses

Example Scenario:

Summary

Additional Resources

Conclusion

Stay Connected for More!

Jasmine-based Ubiquitous Test Runner for Shared Codebases

Why not Playwright, Jest, or...?

Running Tests

Test Coverage Reporting

Some Credits

Misc

Roadmap

"Most Useless Demo Ever" Deepgram Hackathon Submission

Overview of My Submission

Utilizing Deepgram as a virtual speech input in a web desktop.

Submission Category:

Link to Code on GitHub

Additional Resources / Info

Introduction

My Deepgram Use-Case

Conclusion

Taking Grammarly for a Test-Drive

A Virtual Server in your Browser

Ephemeral Networks

No User Accounts

Inspiration to Create this Project

Azure Trial Hackathon - Speech Controlled Web Desktop

Overview of My Submission

Submission Category:

Link to Code on GitHub

zenOSmosis / reshell

ReShell is a web-based desktop & mobile user interface featuring individual "portals," or collections of apps, based on the PhantomCore library.

ReShell - Web Desktop and UI Service Engine

Project Goals

Additional Resources / Info

A WebRTC server in your browser (virtual server; private audio)

Speaker.app / zenRTC / Phantom Server

Table of Contents

Browser Support Matrix

What's in the Box

Architecture Overview

Conventional WebRTC Network Topologies

Speaker.app Peer-Based Network Topology

Inspiration to Create this Project

Getting Started

Dependencies / System Requirements

Building and Running

Public Network Discovery / Private Networks

Testing

Contributing / Forking

Motto

Help Us Continue Writing Free Software

License

Source Code

Using Docker for a local HTTPS proxy

To use: