The Ops Community ⚙️: Sally Acorn

The 2023 Call for Proposals: ILP-enabled Financial Services is now live and accepting applications.

Sally Acorn — Thu, 13 Jul 2023 23:26:23 +0000

The Interledger community is delighted to announce we are now accepting proposals for a new cohort of research and development grants for ILP-enabled Financial Services looking to become nodes in the Interledger network.

NGOs, educational institutions, government agencies, companies, and/or other documented collectives across the world with innovative Interledger Protocol (ILP)-enabled ideas and solutions for open payments and financial inclusion are encouraged to apply.

Expanding the Interledger Network

The Interledger Foundation (ILF) seeks to support ideas and people that use the Interledger Protocol (ILP) to contribute to building equity and inclusion within a global interoperable payments network. As an advocate of inclusive digital financial systems, ILF seeks to support the development of consumer-facing services that will activate as ILP nodes making sending money as simple and easy as sending an email. Its ultimate goal is to create an ecosystem that permits frictionless payments and micropayments across currencies and ledgers connecting everyone, regardless of identity, geography, or income.

On this basis, this Research and Development (Phase 1) grant opportunity seeks projects focused on building the following services:

Digital Wallet Service
Online Bank
ILP-enabled Software
Enabling an Innovative and Inclusive Open Payments Ecosystem

If you have a compelling concept for an innovative, open-source solution, you may submit your proposal by completing the Submittable application form for this grant opportunity. Applicants can request funding in the amount of up to $75,000 USD to assess, and evaluate the possibility of developing the proposed solution.

For this 2023 ILP-enabled Financial Services Call for Proposal, applicants can choose between two timeline options, to execute and complete their proposed project:

3 months: A fast-track option for entities already working on a financial service but require a financial boost to conduct research to enable its ability to move to prototype.
The firm already has a use case for and can demonstrate ongoing work in producing an ILP-enabled financial service and understanding of the financial requirements and policies governing the proposed service in the respective jurisprudence.

6 months: A slower approach that will give applicants the time to develop and conduct a full research project looking at many aspects of a potential solution.
The firm seeks to launch research to develop a compelling case to develop an ILP-enabled financial service. The focus of this opportunity will center around gathering information on the path forward on the financial regulatory policies and rules your service will exist in.

Eligibility & Proposal Requirements

Applicants must be a registered entity, collective, and/or organization. Interledger’s grant is a highly competitive opportunity with structured review processes. As such we encourage applicants to ensure their submissions are well-developed, showcasing an understanding of the problem faced by the underrepresented and underserved populace with connections to the proposed solution and how that enables financial access and inclusion.

All proposals will need to articulate how it intends to develop a dynamic business plan for becoming a node in the Interledger Network along with the following critical deliverables of Phase 1:

An understanding and path forward on the financial regulatory policies and rules the proposed solution will exist in
A technology plan on how your project will use the Interledger Protocol
A practical work plan for producing a prototype including key collaborators
A preliminary budget for the cost of a prototype phase
This Call for Proposal opportunity will be accepting applications until November 21, 2023, at 11:59 pm (EST); with three review periods based on submissions received. Successful applicants will receive funding and be onboarded to commence projects. Unsuccessful applicants will have the opportunity to revise submissions and resubmit for review in a subsequent review period.

We will hold several information sessions on a monthly basis, at varying time zones, where we will walk through the application, share useful tips for applying, and answer questions. You may attend any or all at your convenience. These sessions will be recorded and shared publicly once completed. For the month of June, we will convene an Info Session on Tuesday, June 27, 2023, at 2:00 pm (EST). You may sign up here to join us.

We will maintain a running schedule of Info Sessions and communicate the timeslots via various communications channels. Stay tuned for more details on the Interledger Foundation’s website and community forum for more information. All are welcome to the Interledger Slack and join the specific #cfp-financial-services channel or reach out to us at The Interledger Community if you have any questions about this grant opportunity.

The Interledger Community 🌱 Follow

Welcome to this wonderful place where you can explore and discover new experiences.

Or, You can email one of best company
gamersaids20@gmail.com

Discover the non-code features of GitHub. ~ Part 2 Markdown is plain text formatting

Sally Acorn — Tue, 11 Jul 2023 18:22:45 +0000

Post organized:

Discover the non-code features of GitHub. ~Intro

Sally Acorn ・ Jul 9

#github #devops

Discover the non-code features of GitHub. ~ Part 1 READMEs and Wikis

Sally Acorn ・ Jul 11

#github

Markdown is plain text formatting

GitHub uses markdown for text-based documents, which is a type of language that is super lightweight and uses plain text formatting. This makes it much easier to learn than something like HTML. Markdown consists of simplistic syntax to format text and GitHub has a special type of markdown called GitHub Flavoured Markdown that includes a few extra features and allows for assets such as images or video to be used. If you've never used markdown before, you can check out the GitHub Docs for a guide to markdown formatting. The syntax uses symbols to format the text, making it much easier to learn than most programming languages.

For example, this is how headings are formatted:

# The largest heading
## The second largest heading
###### The smallest heading

Some examples of lightweight styling include:

**[words in here will be bold]**
_[words in here will be italics]_

GitHub Flavored Markdown is utilized in markdown files (*.md), Issues, comments, and Discussions. For those interested in advancing their knowledge of Markdown, the complete formal specification for Markdown syntax is available for review.

Discover the non-code features of GitHub. ~ Part 1 READMEs and Wikis

Sally Acorn — Tue, 11 Jul 2023 18:16:31 +0000

Sally Acorn ・ Jul 9

#github #devops

READMEs and Wikis

Effective collaboration across teams is crucial for the success of any project. GitHub offers a range of tools for technical documentation, including the ability to host GitHub Pages, Wikis, and tutorials directly from the platform. In addition, GitHub's READMEs are a valuable resource for sharing non-technical information about your organization, project, or repository that can be easily understood by everyone. Profile READMEs for individuals and organizations can also be used to showcase yourself and your organization to the community.

Storing all the necessary information together with your code ensures that everyone involved in the project can easily access it. This means that your documentation will receive the same level of attention as your code and can be integrated into the same workflow.

introduce myself to the community

Sally Acorn — Mon, 10 Jul 2023 20:58:57 +0000

Hello and welcome to my profile! My name is Sally Acorn and I am an active member of The Ops Community, CodeNewbie, and DEV Community. If you're interested in staying updated with my latest activities, please feel free.

Thanks for entering me to here! 🌱

Don't be scared: here's how to get started and locate opt-in projects for Hacktoberfest.

Sally Acorn — Mon, 10 Jul 2023 04:47:13 +0000

Now that Hacktoberfest has begun, it's time to make an open source contribution! Fear not, it need not be terrifying. Let's go through the beginning steps. Once everything is set up and ready to go, you may read my following post for some project inspiration.

Sign up to Hacktoberfest
Firstly, you'll need to sign up to Hacktoberfest. You can't really participate without signing up to go 😉

Head to the Hacktoberfest website
This text is providing instructions on how to participate in Hacktoberfest, which is an annual event where people can contribute to open-source projects on GitHub and earn prizes.

Click "Start Hacking":
The first step is to sign up for Hacktoberfest on their website. This is necessary in order to participate. To sign up, go to the Hacktoberfest website and click on the "Start Hacking" button.

Go through the three step "Welcome" Process:

This text is providing an instruction to follow a three-step process called the "Welcome" process. The instruction does not provide any information about what the Welcome process involves or what it is for. Therefore, it is not possible to define any technical terms

When you've authenticated, you should be able to see your profile screen. If not, head back to the main homepage and click "Start Hacking" again. This will take you to your profile:

This text is providing instructions on how to access your profile screen after authenticating.

Authentication refers to the process of verifying the identity of a user or system. In this context, it likely means logging in with a username and password.

The main homepage refers to the starting page of the website or application being used.

"Start Hacking" is likely a button or link on the homepage that initiates the login process.

The profile screen is a page that displays information about the user, such as their name, profile picture, and any settings or preferences they have set.

If the user is not automatically taken to their profile screen after logging in, they are instructed to return to the main homepage and click "Start Hacking" again. This should redirect them to their profile page.

Wait for a next part of the post

How to write a good bug report

Sally Acorn — Sun, 09 Jul 2023 20:40:18 +0000

As a developer, I can see first hand the difference that a good bug report makes. A poorly written issue gets resolved much more slowly because of two factors:

I spend more time trying to understand it, and
I often leave them waiting until there are no better written issues left.
In this article, I’ll show you how to write a good, easy to understand bug report.

Target audience

Firstly, think about your target audience. It will be very likely pretty broad:

Developers: as the ones who need to understand the issue and provide the fix
Testers: so they can confirm the issue is gone after adding the fix
Managers: to assess the importance of the issue It would be perfect to have a description clear enough that even the newest team member can make sense of it.

This means that it’s better to err on the side of being too verbose and include some ‘common knowledge’ about your product in the ticket.

Troubleshooting

Some great help that a person who writes a ticket can provide for developers is a little bit of troubleshooting. You don’t have to find a root cause of the issue, but some effort can go a long way: both in helping your colleagues and helping your progress in your career.

Errors in console

I’ve seen managers who were truly impressed by the fact that service desk colleagues opened dev tools to see whether there were any errors in the console when the application failed. As a developer, those logs are often enough for me to pinpoint the issue in the code. In some cases, by just having the errors included in the ticket, as a text or a screenshot, I can immediately jump into resolving the issue. The logs are particularly helpful if I cannot reproduce the issue—in those cases, they can be the only information I have to find the error.

Backend requests

In my experience, many backend bugs are reported first on the frontend—because this is what users use and where they see things going off the rails. Something as simple as checking out the network tab can be enough to correctly assess where the issue originated—you can see the errors returned by the server, see what parameters were sent, etc. Even if this doesn’t clarify things for you, you can include request and response pairs in your ticket, and most likely, developers will get a lot of information from it.

Content checklist

Let’s take a look at what to include in your bug report.

Title that summarizes the issue

A clear title helps a lot. It should make it clear what is broken and where it’s broken at first glance. Clarity is important because not every developer will have enough business context to know what behavior is correct. So, for example, instead of “Bug: Cashback on discounted products”, you can write:

“Bug: Cashback missing from the discounted products”, or
“Bug: Cashback should not be applied on discounted products”.
The ‘where’ is important as well. If your team has many developers, then they will immediately know who worked on a given part of the application recently, and they will be able to auto-organize efficiently.

Exact steps to reproduce

A list of steps needed to see the issue happen in the application. Besides the most simple bugs, this is the key to resolving the issue and confirming that it’s really gone. Good reproduction steps contain all the relevant information, such that anybody from your audience could follow them and see the bug in action. This often includes:

the environment—the best is to have an example at the testing or staging environment, so the issue can be repeatedly observed without affecting customers’ data,
exact URL,
any clicks, typings, or other operations that are done in the app,
files and all the other inputs that were sent to the application,
any other thing that could be relevant to getting the issue.
Note that if you cannot reproduce the issue, then most likely, the developer will not be able to either. This doesn’t mean it shouldn’t be written and cannot be addressed—it just means that troubleshooting will be more time-consuming, and fixes will be done based on educated guesses, and they will be difficult to check for correctness.

Expected behavior

As with the title: what should happen instead is not always clear for people who work far from the business. Making the expectation explicit, from the very beginning, can save time in communication or proving a wrong fix.

Screenshot

Screenshots provide a lot of information and can be digested at once. Besides that, taking them and including them in the bug report takes only a few moments. There is no reason not to include them in the bug report—even a white screen of a failed app can contain interesting information in the address bar.

Versioning

If your team has some version identifier, it makes sense to include it in the bug report. Often, I’m able to save a lot of time by comparing the affected version with the repository history. For example, maybe the ticker was written with an older version, and the bug has been fixed since then. Or perhaps the retesting happened before the fix was delivered to the environment. In any case, chasing a bug that is not there is neither productive nor fun.

What next

If you are interested in learning more about testing or programming in general, you can sign up here to get an occasional email from me. Meanwhile, here are some related articles:

How to write better as a developer,
What is manual testing,
Software testing and how it can be used as a tech entry job,
How to display Git branches easily as a tree in CLI

Don't forget to leave a comment if you have any question, Put a heart or unicorn and fire if its amazing and thanks for CodeNewbie Community and DEV Community for supporting me to join this website (The Ops Community)

Discover the non-code features of GitHub. ~Intro

Sally Acorn — Sun, 09 Jul 2023 19:07:13 +0000

Introduction

GitHub is commonly associated with developers, but it is not limited to them. In fact, an increasing number of non-developers are discovering and utilizing the platform. GitHub offers a variety of tools that do not require coding knowledge, making it an accessible platform for everyone.

Collaboration is a key aspect of teamwork, and it is one of the four pillars of DevOps. In order for developers and non-developers to work together effectively, it is essential for them to use the same platform. By doing so, they can stay on the same page and comprehend what is happening.

GitHub provides a number of tools that both developers and non-developers can use to collaborate. Technical documentation is crucial for effective communication between teams, and GitHub offers excellent tools for this purpose. With GitHub Pages, Wikis, and tutorials, users can easily create and host documentation directly on the platform.

Wait for the second part of this post about GitHub