Read this description in a different language:

Current language is: English (US) (translations may need to be corrected to fix English replacing the correct language)

Translations in languages other than English are machine translated and are not yet accurate. No errors have been fixed yet as of February 5th 2021. Please report translation errors here make sure to backup your correction with sources and guide me, as I don’t know languages other than English well (I plan on getting a translator eventually) please cite wiktionary and other sources in your report. Failing to do so will result in a rejection of the correction being published.

Note: due to limitations with GitHub’s interpretation of markdown (and pretty much every other web-based interpretation of markdown) clicking these links will redirect you to a separate file on a separate page that isn’t my GitHub profile page. You will be redirected to the seanpm2001/seanpm2001 repository, where the README is hosted.

Translations are done with Google Translate due to limited or no support for the languages I need in other translation services like DeepL and Bing Translate. For some reason, the formatting (links, dividers, bolding, italics, etc.) is messed up in various translations. It is tedious to fix, and I do not know how to fix these issues in languages with non-latin characters, and right to left languages (like Arabic) extra help is needed in fixing these issues

00.0 – Top

00.1 – Title

00.2 – Read this article in a different language

00.3 – Index

01.0 – Description

02.0 – About

03.0 – Wiki

04.0 – History

04.1 – Pre-history

04.2 – Alpha History

04.3 – Beta History

04.4 – Modern History

05.0 – Copying

06.0 – Credits

07.0 – Installation

08.0 – Version history

09.0 – Software status

10.0 – Sponsor info

11.0 – Contributers

12.0 – Issues

12.1 – Current issues

12.2 – Past issues

12.3 – Past pull requests

12.4 – Active pull requests

13.0 – Resources

14.0 – Contributing

15.0 – About README

16.0 – README Version history

17.0 – Footer

17.9 – End of file

The Programming language IDE submodule for SNU Programming Tools (2D Mode)

See above. This repository is the IDE for that comes with SNUs programming tool set.

Click/tap here to view this projects Wiki

If the project has been forked, the Wiki was likely removed. Luckily, I include an embedded version. You can view it here.

Write about this projects history here.

No pre-history to show for this project.

No Alpha history to show for this project.

No Beta history to show for this project.

No Modern history to show for this project.

View the copying license for this project here (if you haven’t built the project yet with the makefile, here is the original link: COPYINGL

Please note that you also have to follow the rules of the GNU General Public License v3 (GPL3) which you can view here

View the credits file for this project and see the people who got together to make this project by clicking/tapping here

View the installation instructions file for this project here

Requirements: Read the instructions for more info, and get the latest up-to-date instructions here

You can sponsor this project if you like, but please specify what you want to donate to. See the funds you can donate to here

You can view other sponsor info here

Try it out! The sponsor button is right up next to the watch/unwatch button.

Version history currently unavailable

No other versions listed

All of my works are free some restrictions. DRM (Digital Restrictions Management) is not present in any of my works.

This sticker is supported by the Free Software Foundation. I never intend to include DRM in my works.

I am ussing the abbreviation “Digital Restrictions Management” instead of the more known “Digital Rights Management” as the common way of addressing it is false, there are no rights with DRM. The spelling “Digital Restrictions Management” is more accurate, and is supported by Richard M. Stallman (RMS) and the Free Software Foundation (FSF)

This section is used to raise awareness for the problems with DRM, and also to protest it. DRM is defective by design and is a major threat to all computer users and software freedom.

Image credit: defectivebydesign.org/drm-free/…

Currently, I am the only contributer. Contributing is allowed, as long as you follow the rules of the CONTRIBUTING.md file.

• 1. seanpm2001 – x commits (As of 2021, date, at xx:xx pm)

• 2. No other contributers.

• None at the moment

• No other current issues

If the repository has been forked, issues likely have been removed. Luckily I keep an archive of certain images here

Read the privacy policy on issue archival here

TL;DR

I archive my own issues. Your issue won’t be archived unless you request it to be archived.

• None at the moment

• No other past issues

If the repository has been forked, issues likely have been removed. Luckily I keep an archive of certain images here

Read the privacy policy on issue archival here

TL;DR

I archive my own issues. Your issue won’t be archived unless you request it to be archived.

• None at the moment

• No other past pull requests

If the repository has been forked, issues likely have been removed. Luckily I keep an archive of certain images here

Read the privacy policy on issue archival here

TL;DR

I archive my own issues. Your issue won’t be archived unless you request it to be archived.

• None at the moment

• No other active pull requests

If the repository has been forked, issues likely have been removed. Luckily I keep an archive of certain images here

Read the privacy policy on issue archival here

TL;DR

I archive my own issues. Your issue won’t be archived unless you request it to be archived.

Here are some other resources for this project:

Project language file A)

Join the discussion on GitHub

No other resources at the moment.

Contributing is allowed for this project, as long as you follow the rules of the CONTRIBUTING.md file.

Click/tap here to view the contributing rules for this project

File type: Markdown document (*.md)

File version: 1 (date)

Line count: 0,415

Version 1 (Date)

Changes:

• Started the file

• Added the title section

• Added the index

• Added the about section

• Added the Wiki section

• Added the version history section

• Added the issues section.

• Added the past issues section

• Added the past pull requests section

• Added the active pull requests section

• Added the contributors section

• Added the contributing section

• Added the about README section

• Added the README version history section

• Added the resources section

• Added a software status section, with a DRM free sticker and message

• Added the sponsor info section

ITERATION 5

• Updated the title section

• Updated the index

• Added the history section

• Updated the file info section

• Updated the file history section

• Updated the footer

ITERATION 6

• Updated the title section

• Fixed and update template links

• Updated the index

• Added the copying section

• Added the credits section

• Added the installation section

• Updated the resources section

• Updated the contributors section

• Added the technical notes section

• Updated the footer

• Updated the file info section

• Updated the file history section

• No other changes in version 1

Version 2 (Coming soon)

Changes:

• Coming soon

• No other changes in version 2

( Back to top | Exit to GitHub | Exit to Bing | Exit to DuckDuckGo | Exit to Ecosia )

<Program/Library name> is a < program/library/collection of scripts > for < description of what it does and what problem it solves >.

• < Short compile/run instructions, without too much detail >

• The full documentation is available at: < Link to manual, wiki, full documentation, etc. >
• OR Detailed setup and use instructions are available in the companion knowledge base article, article_title .

• < Links to study website, related projects, etc. >

< 1-2 paragraphs about your department, core, lab, study team, class or project. This is your marketing space! >

Learn more at: < link to dept/lab/project website >

To get in touch, contact the individual developers in the check-in history.

If you need assistance identifying a contact person, email the project maintainers at: < dept/lab/mcommunity group email address >.

• Eisenberg Family Depression Center (@DepressionCenter)
• Gabriel Mongefranco (@gabrielmongefranco)
• Name [ @githubusername ]( link to github profile or website )

• None
• OR < Library or project name > – < link >

Copyright © 2024 The Regents of the University of Michigan

This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.

This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.

You should have received a copy of the GNU General Public License along with this program. If not, see https://www.gnu.org/licenses/gpl-3.0-standalone.html.

Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.3 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. You should have received a copy of the license included in the section entitled “GNU Free Documentation License”. If not, see https://www.gnu.org/licenses/fdl-1.3-standalone.html

If you find this repository, code or paper useful for your research, please cite it.

Copyright © 2024 The Regents of the University of Michigan

This is a project for us to learn about of bootstrap of News Week, making it responsive through mobile, tablet and desktop.

• Git
• Github
• VSCode
• HTML5
• CSS3
• Flexbox
• Grid
• Bootstrap
• Fontawesome
• Google Chrome Inspector
• Linters

Live Demo Link

For linters-checking purposes, run:

npm install

npx hint .

npx stylelint "**/*.{css,scss}"

To get a local copy up and running follow these simple example steps.

Owning a web broser 😀

Just clone the github repositori

Using a GitHub Descktop program or SSH protocol

Just run index.html on browser, or run in the command line, like this:

firefox index.html

or

google-chrome index.html

👤 Rolando

• GitHub: @Rolando
• Twitter: @rolando
• LinkedIn: Rolando

Contributions, issues, and feature requests are welcome!

Feel free to check the issues page.

Give a ⭐️ if you like this project!

This project is Licensed under a Creative Commons Attribution 4.0 International License (CC BY).

If you liked this proyect, the original desigin https://www.behance.net/gallery/25563385/PatashuleKE

Declarative data loading for REST APIs: https://tonyhb.github.io/tectonic/

Great question! It:

• Queries data via your existing REST API with adaptable query drivers
• Stores state and data within Redux’ reducers automatically
• Respects and manages caching
• And, best of all, passes fetched data and loading state into your components

What does that mean?

Never define an action for loading data again. And also, never write a reducer again. Which means no normalization of data! And no writing reselect queries! It happens automatically for you.

First you need to define some models to hold and query data:

import { Model } from 'tectonic';

class User extends Model {
  // modelName is important; it's used to differentiate models
  static modelName = 'user';

  // fields are used to create an immutable.js record which holds data for an
  // instance of a model. All fields must be defined here with defaults
  static fields = {
    id: 0,
    email: '',
    name: '',
  }

  // idField defines which field is used as the model identifier. This defaults
  // to 'id' and should only be set if it's different.
  // Note that a model must always have an ID; this is how we look up data in
  // reducer.
  static idField = 'id';
}

Then you define your REST API as sources. It’s quick and easy, but let’s skip it to get to the juicy part. Which is declaratively asking for data!

Check it out (I’ll tell you what’s going on after):

import React, { Component, PropTypes } from 'react';
import load, { Status } from 'tectonic';
import { User, Post } from './models.js'; // your models
const { instanceOf, arrayOf, shape, string } = PropTypes;

@load((props) => ({
  user: User.getItem({ id: props.params.userId }),
  posts: Post.getList({ email: props.user.email })
}))
class UserInfo extends Component {
  static propTypes = {
    // btw, these are the same keys we passed to '@load'
    user: instanceOf(User),
    posts: arrayOf(instanceOf(User)),

    status: shape({
      user: instanceOf(Status), // Status is a predefined Tectonic class :)
      posts: instanceOf(Status),
    })
  }

  render() {
    const { status } = this.props;
    if (status.user.isPending()) {
      return <Loading />;
    }
    // ...
  }
}

Hella cool right?! Here’s what’s happening:

You say what props you want within the @load decorator. The @load decorator gets the component’s props, so you can use props in the router or from parents to load data.

Plus, it automatically handles what we call “dependent data loading”. Here, posts depends on the user’s email. We don’t get that until the user has loaded. Don’t worry; this is handled automatically behind the scenes.

Tectonic also adds loading statuses for each of the props to your component!

You can see whether it’s pending, successful, or errored using built in functions (the actual status is at .status, so this.props.status.user.status). Plus, if there’s errors, you get the error message at .error, so this.props.status.user.error. Same goes for the HTTP code.

And as a bonus all of the requests are automatically cached and stored according to the server’s cache headers. So if your server tells us to store something for an hour we’re not going to make a request for this data for, like, one hour and one minute!

Super, super basic interface, and super, super powerful stuff behind the scenes. I know, not as cool as GraphQL and relay. But still, if you gotta REST you gotta deal, baby.

Bonus: Guess what? If three components asked for the same data we’ll automatically dedupe requests for you. We’ll only ask the API once. So don’t worry. Spam @load like you’re obsessed!

That’s right. See, behind the scenes we need to figure out how to actually load your data. This is done by a “resolver”.

In order for us to figure that out you need to tell us where your endpoints are; what they return; and what required parameters they have.

Here’s an example:

import { Manager, BaseResolver } from 'tectonic';
import TectonicSuperagent from 'tectonic-superagent';

// Step 1: create your manager (which brings everything together)
const manager = new Manager({
  resolver: new BaseResolver(),
  drivers: {
    // Drivers are modular functions that request data for us.
    // This one uses the awesome superagent ajax library.
    // See packages/tectonic-superagent for more info :)
    fromSuperagent: new TectonicSuperagent(),
  },
  store, // Oh, the manager needs your redux store
});

// Step 2: Define some API endpoints as sources.
// Note that each driver becomes a function on `manager` - this
// is how we know which driver to use when requesting data.
manager.drivers.fromSuperagent([
  // Each driver takes an array of API endpoints
  {
    // LMK what the endpoint returns. In this case it's a single
    // user item.
    returns: User.item(),
    // To get a single user the API endpoint needs a user's ID
    params: ['id'],
    meta: {
      // meta is driver-specific. In this case the superagent driver
      // needs to know the URL of the API endpoint. It's going to
      // replace `:id` with the ID parameter when loading data.
      url: '/api/v1/users/:id',
    }
  },
  {
    // This returns a list of posts
    returns: Post.list(),
    // Each param item is the name of the param you pass into @load. EG:
    // @load({
    //    posts: Post.getList({ userId: 1 })
    //  })
    params: ['userId'],
    meta: {
      url: '/api/v1/users/:userId/posts',
    },
  },
]); 

A lot of concepts.

The manager makes everything tick. It passes “queries” from @load into the “resolver”, which then goes through your sources above to figure out which requests to make.

Once we’ve got data, the manager takes that and puts it into the cache, which is an abstraction over a Redux reducer in the store to manage caching.

We’ll throw an error which you can see in your console. Also, we use the debug npm package which you can enable via:

tdebug.enable('*');

Wrap your app with a component which passes context. We call it a “loader”:

import { Provider } from 'react-redux';
import { Loader } from 'tectonic';
import store from './store.js';
import manager from './manager.js'; // your manager with sources defined

const App = () => (
  <Provider store={ store }>
    <Loader manager={ manager }>
      {/* Your app goes here */}
    </Loader>
  </Provider>
);

export default App;

Hell yeah baby!

The @load decorator also adds a query function to your components:

@load() // just gimme these functions please!
class YourForm extends Component {
  static propTypes = {
    query: PropTypes.func,
  }

  // imagine onSubmit is called with an object containing model
  // data...
  onSubmit(data) {
    // Each function takes two arguments: an object of options and a
    // second callback for tracking the status of the request 
    this.props.query({
      model: User,
      body: data,
      queryType: 'CREATE', // tells us to use a source definition to CREATE a model
    }, this.afterSubmit);
  }
  
  afterSubmit = (err, result) => {
    if (err !== null) {
      // poo 💩
      return;
    }
  }
}

💥💥💥! This is automatically gonna populate the cache, too.

Sure thing, partner. Head here.

License: MIT.

The Linked Parallel Table of Authorities and Rules

A simple script to create a version of the Parallel Table of Authorities and Rules with links to the legal texts.

In my final semester of law school, I was sitting in an Administrative law class where we were learning about some of the resources used to practice administrative law. One was the PARALLEL TABLE OF AUTHORITIES AND RULES. The document links all of the regulatory rules in the United states with a citation to the US Code giving the agency the authority to make the rule.

While we were discussing how to use the document, the instructor mentioned that there wasn’t a linked version of the list. I found a text version of the list and began to write a script that would parse the text and link it to law.cornell.edu. It was a fun project, and by the time the class was over, I had most of the linked parallel table finished.

In the subsequent years, Cornell seems to have updated their site with their own version of a parallel table of authorities.

If you are using my linked parallel table, or would like to have it updated to a more recent year, feel free to reach out at lets talk AT cjkinni dot com.

• Important: Because of #1057 this tutorial is only runable on Linux machines. (native image agent is only available for Linux)
• Install GraalVM from here https://www.graalvm.org/ (Used version 20.0.0)
  • (For Mac OSX versions > Catalina: Remove quarantine from the bits, info)
    $ sudo xattr -r -d com.apple.quarantine path/to/graalvm/folder/
• Configure your env
  • Prepend the GraalVM bin directory to the PATH environment variable:
    $ export PATH=<path to GraalVM>/Contents/Home/bin:$PATH.
    To verify whether you are using GraalVM, run: $ which java
  • Set the JAVA_HOME environment variable to resolve to the GraalVM installation directory:
    $ export JAVA_HOME=<path to GraalVM>/Contents/Home
  • (Specify GraalVM as the JRE or JDK installation in your Java IDE)

• GraalVM 20.0.0 was the latest version available to download. Newer releases should have fix for Bug oracle/graal#2198
• SpringBoot 2.3.x was needed for GraalVM native-image support

The application is very simple (just giving out “Hello World” at localhost:8080 but nevertheless the performance difference is significant:

The following steps are needed to compile the spring boot application to native code with GraalVm

mvn -DskipTests clean package
export MI=src/main/resources/META-INF
mkdir -p $MI 
java -agentlib:native-image-agent=config-output-dir=${MI}/native-image -jar target/<YOUR_APP_ARTIFACT>.jar

## Due to https://github.com/oracle/graal/issues/2198 you have to add a class to reflect-config.json. Maybe its fixed in GraalVM version > 20.0.0
{
 "name":"org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl",
 "allDeclaredConstructors":true,
 "allDeclaredMethods":true
},

## Check if the application is working correctly: http://localhost:8080
## then hit CTRL + C to stop the running application.

tree $MI
mvn -Pgraal clean package

After successfully compiling the application you can start the application with
./target/de.wandi34.graaldemo.graaldemoapplication

Application was built with following documentations:

• https://spring.io/blog/2020/04/16/spring-tips-the-graalvm-native-image-builder-feature
• https://repo.spring.io/milestone/org/springframework/experimental/spring-graal-native-docs/0.6.0.RELEASE/spring-graal-native-docs-0.6.0.RELEASE.zip!/reference/index.html
• oracle/graal#2198

• Important: Because of #1057 this tutorial is only runable on Linux machines. (native image agent is only available for Linux)
• Install GraalVM from here https://www.graalvm.org/ (Used version 20.0.0)
  • (For Mac OSX versions > Catalina: Remove quarantine from the bits, info)
    $ sudo xattr -r -d com.apple.quarantine path/to/graalvm/folder/
• Configure your env
  • Prepend the GraalVM bin directory to the PATH environment variable:
    $ export PATH=<path to GraalVM>/Contents/Home/bin:$PATH.
    To verify whether you are using GraalVM, run: $ which java
  • Set the JAVA_HOME environment variable to resolve to the GraalVM installation directory:
    $ export JAVA_HOME=<path to GraalVM>/Contents/Home
  • (Specify GraalVM as the JRE or JDK installation in your Java IDE)

• GraalVM 20.0.0 was the latest version available to download. Newer releases should have fix for Bug oracle/graal#2198
• SpringBoot 2.3.x was needed for GraalVM native-image support

The application is very simple (just giving out “Hello World” at localhost:8080 but nevertheless the performance difference is significant:

The following steps are needed to compile the spring boot application to native code with GraalVm

mvn -DskipTests clean package
export MI=src/main/resources/META-INF
mkdir -p $MI 
java -agentlib:native-image-agent=config-output-dir=${MI}/native-image -jar target/<YOUR_APP_ARTIFACT>.jar

## Due to https://github.com/oracle/graal/issues/2198 you have to add a class to reflect-config.json. Maybe its fixed in GraalVM version > 20.0.0
{
 "name":"org.apache.catalina.authenticator.jaspic.AuthConfigFactoryImpl",
 "allDeclaredConstructors":true,
 "allDeclaredMethods":true
},

## Check if the application is working correctly: http://localhost:8080
## then hit CTRL + C to stop the running application.

tree $MI
mvn -Pgraal clean package

After successfully compiling the application you can start the application with
./target/de.wandi34.graaldemo.graaldemoapplication

Application was built with following documentations:

• https://spring.io/blog/2020/04/16/spring-tips-the-graalvm-native-image-builder-feature
• https://repo.spring.io/milestone/org/springframework/experimental/spring-graal-native-docs/0.6.0.RELEASE/spring-graal-native-docs-0.6.0.RELEASE.zip!/reference/index.html
• oracle/graal#2198

raftlock is a fault-tolerant distributed lock service for coordinating distributed applications. It is written in Go and is designed to be a reliable and highly available solution for managing distributed locks.

In distributed systems, coordinating actions between different services or nodes can be a complex challenge. raftlock provides a simple and robust solution for this by offering a distributed locking mechanism. This ensures that only one process can access a particular resource at a time, preventing data corruption and ensuring consistency across your distributed application.

The project is built on top of the Raft consensus algorithm, which guarantees fault tolerance. This means that raftlock can withstand failures of some of its nodes without losing availability or data.

raftlock is useful for a variety of use cases in distributed systems, including:

• Leader Election: Electing a single leader from a group of nodes to perform a specific task.
• Distributed Cron Jobs: Ensuring that a scheduled task is executed by only one node in a cluster.
• Resource Locking: Preventing multiple processes from concurrently modifying a shared resource, such as a file or a database record.
• Distributed Semaphores: Limiting the number of concurrent processes that can access a pool of resources.

By providing a reliable and easy-to-use distributed lock service, raftlock simplifies the development of robust and scalable distributed applications.

RaftLock is composed of several key packages, each handling a specific aspect of the distributed lock service.

• server/: Implements the gRPC server that exposes the distributed locking API to clients. It handles request validation, leader redirection, and coordination with the underlying Raft consensus. For more details, see the Server Package README.
• raft/: Contains a custom-built implementation of the Raft consensus algorithm. This is the core engine for maintaining strong consistency and fault tolerance across the cluster. Dive deeper into its design in the Raft Consensus Module README.
• lock/: Provides the distributed lock manager, which acts as the application-level state machine for the Raft cluster. It manages lock states, expirations, and waiter queues. Learn more in the Distributed Lock Manager README.
• storage/: Offers a durable and crash-resilient persistence layer for Raft data, including persistent state, log entries, and snapshots. Details can be found in the RaftLock Storage Package README.
• client/: Provides the Go client library for applications to communicate with a RaftLock cluster, offering interfaces for standard lock operations, administration, and advanced features. For usage, refer to the Client Package README.
• proto/: Defines the Protocol Buffer messages and gRPC service for the RaftLock API, ensuring type-safe and efficient communication between clients and the server. See the RaftLock Protocol Buffers README.

You can run the raftlock server using either Docker or by building from the source.

This is the recommended way to run raftlock. We use docker-compose to easily manage a multi-node cluster.

1. Start the cluster: This command will build the Docker images and start a 3-node raftlock cluster in the background.

   docker-compose up --build -d

2. Check the logs: You can monitor the logs of each node to see the cluster formation and leader election process.

   docker-compose logs node1
   docker-compose logs node2
   docker-compose logs node3

3. Stop the cluster: To stop and remove the containers, networks, and volumes, run:

   docker-compose down -v

If you prefer to build from the source code:

1. Clone the repository:

   git clone https://github.com/jathurchan/raftlock.git
   cd raftlock

2. Build the binary:

   go build

3. Run a server node: You’ll need to run multiple instances on different ports to form a cluster. See the Configuration section for more details.

   ./raftlock --id node1 --api-addr ":8080" --raft-addr ":12379" --raft-bootstrap

To see raftlock in action, you can run the payment example located in the examples/payment directory. This example demonstrates how to use a distributed lock to ensure a payment process is handled by only one node at a time, preventing double spending.

Run the example with the following command:

go run examples/payment/main.go --payment-id payment456 --client-id client002 --servers localhost:8080

This will start a client that interacts with the raftlock server to acquire a lock before processing a mock payment. You will see output indicating whether the lock was acquired and the payment was processed.

You can interact with raftlock using its simple REST API. Here are some examples using curl.

To acquire a lock, send a POST request to the /lock endpoint with the resource you want to lock and a ttl (time-to-live) in seconds.

curl -X POST -H "Content-Type: application/json" -d '{
  "resource": "my-critical-resource",
  "ttl": 30
}' http://localhost:8080/lock

If successful, you will receive a lock_id.

To release a lock, send a POST request to the /unlock endpoint with the lock_id you received when acquiring the lock.

curl -X POST -H "Content-Type: application/json" -d '{
  "lock_id": "your-lock-id-here"
}' http://localhost:8080/unlock

If you have any questions or encounter any issues while using raftlock, please feel free to open an issue on the GitHub repository. We will do our best to help you as soon as possible.

We welcome contributions from the community! If you are interested in contributing to raftlock, please follow these steps:

1. Fork the repository on GitHub.
2. Create a new branch for your feature or bug fix: git checkout -b my-new-feature.
3. Make your changes and commit them with clear, descriptive messages.
4. Run the tests to ensure everything is working: go test ./....
5. Push your branch to your fork: git push origin my-new-feature.
6. Submit a pull request to the main branch of the jathurchan/raftlock repository.

raftlock is maintained by a team of dedicated developers:

• Jathurchan Selvakumar
• Patrice Zhou
• Mathusan Selvakumar

We welcome contributions from the community! If you are interested in contributing to raftlock, please fork the repository and submit a pull request.

CMaNGOS Classic is an open-source project, known as Continued MaNGOS, with variants named Classic, TBC and WOTLK. This repository contains the Bazel build instructions for assembling container images that are capable of building the Classic variant of cmangos.

This repository is responsible for:

• The build-deps image – An image based on Ubuntu with all build dependencies installed
• The builder image – An image with the mangos-classic source (& other source-based deps) included
• The runtime image – An image based on Ubuntu with all runtime dependencies installed
• The database image – An image containing a dataset of SQL data files
• The extractor image – A ready-to-run image for extracting client data
• The release image – A ready-to-run image for running the emulator server

This repository is extracted from a mono-repo (large repository containing multiple projects), which is why this repository does not leverage GitHub Actions/GitLab Pipelines or any similar services offered by the Git hosting provider. Images are built from this repository & published into the registry.

Images built from this source code should be the same for released images.

To build these images, this requires a build environment that supports Bazel & docker. Builds can be executed by running the standard bazel build steps. All container images within the repository can be built at once using the command:

bazel build //...

Individual images can be built by running commands similar to bazel build //containers/builder:image.

Images can be experimented with locally by leveraging the load actions, which can be executed by bazel run as such:

bazel run //containers/builder:load

This will load the images into the docker daemon with the wip tag.

Aditi Bhatia

Harshrajsinh Rathod

Venkat Pushpak Gollamudi

Aravindhan Elayakumar

Akinfemi Akin-Aluko

-> Flask
-> Python3
-> Merkle Trees (tools)
-> HTML/CSS/Javascript/Bootstrap
-> Consensus algorithm
-> Replication
-> Proof of Work

FLASK_APP=server.py flask run --port=5001

FLASK_APP=server.py flask run --port=5002

Include all other nodes in the JSON file other than the node you’re already on. Uses proof of work and forges a new block.
For registering node 5002 on node 5001:

curl -i -X POST http://localhost:5001/nodes/register -d @register-node5001.json --header "Content-Type: application/json"

For registering node 5001 on node 5002:

curl -i -X POST http://localhost:5002/nodes/register -d @register-node5002.json --header "Content-Type: application/json"

curl -i -X POST http://localhost:5001/register -d @entry.json --header "Content-Type: application/json"

{
	"upc": "123",
	"product":"MEGNYA Leather Baby Moccasins",
	"link": "https://www.amazon.com/MEGNYA-Leather-Moccasins-Toddler-ZH0003-Brown-12-5/dp/B07BBVPSPW/ref=sr_1_1_sspa?ie=UTF8&qid=1525936891&sr=8-1-spons&keywords=baby+shoes&psc=1",
	"quantity": "90",
	"price":"18.99",
	"manufacturer": "MEGNYA"
}

To replicate all new changes (such as the ones made on 5001) on node 5002:

curl -i -X GET http://127.0.0.1:5002/nodes/resolve

To replicate all new changes (such as the ones made on 5002) on node 5001:

curl -i -X GET http://127.0.0.1:5001/nodes/resolve

Run on all nodes that have not been updated.

Checks to see that the original owner actually has the product or not. Also checks to see if a product exists with that ID.

curl -i -X GET http://127.0.0.1:5001/transfer

{
	"upc": 123123,
	"old_owner": "Aditi", 
	"new_owner": "Femi"
}

curl -i -X GET http://127.0.0.1:5001/chain

curl -i -X GET http://127.0.0.1:5001/transaction/<transaction_ID>

Returns an error statement if a product with that ID does not exist.

curl -i -X GET http://127.0.0.1:5001/product/<product_ID>