text:
---
author: richard
date: 2012-04-10 20:00:59+00:00
title: The Eden Project
wordpress_id: 997
image: https://c7.staticflickr.com/8/7407/14166809126_f69f372dd9_q.jpg
locations:
- UK
- Cornwall
redirect_from:
  - /uk/cornwall/cornwall-2012/edenproject/
---

{% flickr_image<PHONE_NUMBER>5 alignright %}
For our first family holiday, we decided to take a different approach to normal and stay
relatively close to home. We have been threatening to visit the [Eden Project][ep] for at
least the last 4 years, so we headed to Cornwall for the week after Easter.  We started our
journey on Easter Monday, but to keep travel times short, we stayed with friends in
Wellington Monday night where we were kindly fed Chinese food :smile:. With George around,
there's rarely any danger of having a long lie in so we were back on the road again by 08:30
Tuesday morning on route to the Eden Project. Contrary to the forecast, the weather was
glorious so we were able to fully enjoy our drive down. On arrival, we were shepherded into
the top car park and directed onto a bus, the first bus George has ever been on! The bus
weaved down into the quarry where we got our first glimpse of the huge Biomes that house the
artificial habitats of the Eden Project.

{% flickr_image<PHONE_NUMBER>5 %}
We started our day in the Core, which is the latest addition to the Eden Project. It is
essentially an education centre with lots of hands on exhibits for learning about the
environment, wildlife and plant life etc. The building is of a sustainable construction,
highly insulated and very energy efficient. The roof has been build using the principle of
‘phyllotaxis’ which is the mathematical basis of how plants grow and looks amazing. It also
houses a large photovoltaic array to generate electricity for the site.

{% flickr_image<PHONE_NUMBER>4 alignright %}
The building is centred around Peter Randall-Page's seed sculpture which was created from a
single hunk of granite found at a local quarry. It is an incredible sculpture. It looks so
simple, but it is geometrically perfect (by natures standards) and quite beautiful to look
at.

{% flickr_image<PHONE_NUMBER>3 %}
Once we had finished up in the Core, we headed over to the rainforest biome to explore the
various tropical habitats located within. The temperature range was from 20-30°C at
approximately 90% humidity so within minutes of entering the biome we had to start stripping
off! George’s pram came in very handy for storing coats and layers, as well as George! The
winding path through the biome takes you on a journey through the various tropical climates
around the globe profiling the forms of plants and trees that grow there. In the middle there
was even a typical hut from Malaysia.

{% flickr_image<PHONE_NUMBER>6 alignright %}
We spent about an hour and a half in the rainforest biome before heading out into the cold
again, well comparatively cold anyway! Outside the lobby between the two covered biomes is
the outdoor seating area for the café, but George was getting hungry by this point so we
wandered through the gardens and took a seat on one of the walls for our lunch.

{% flickr_image<PHONE_NUMBER>8 %}
It really was a beautiful day to be out and about, but we only stayed out for lunch before
diving back into the mediterranean biome. This was much cooler than the tropical biome, and
a fair bit drier to try to simulate the climate of the various locales around the world.
This biome was definitely not as exciting and interesting as the tropical one. I think Rosie
and I have much more interest in the more exotic locations around the world so the olive and
citrus trees didn’t really do it for us. I feel that that observation is probably fairly
unique to us as the café within the biome was packed and there seemed to be a lot of people
in it generally.

{% flickr_image<PHONE_NUMBER>2 alignright %}
The Eden Project is built within an old quarry so the whole site has it’s own microclimate
and, as such, the outdoor growing areas have been dubbed the ‘outdoor biome’. The whole area
was alive with medicines, foods and common British plants & trees. There were people working
all over the place planting out the new seasons growth and harvesting things that were ready.
It was incredibly lively and really made me want to put more effort into our garden, but we
all know that’s never going to happen! Once we had seen all that we wanted to see, we
meandered our way back up to the start to be herded through the gift shop before leaving. I
picked up a little coffee plant (don’t want to get too excited with this gardening malarkey
:wink:).

 We left the Eden Project and decided to find our hotel for the night.
The directions took us around three sides of the Eden Project grounds, through a little lane
to a beautiful old house that had been converted into our hotel, [Boscundle Manor][bm]. It
looked like just the right place to spend the remainder of our second anniversary in style.
The place was amazing, and we were given a bungalow, including kitchen, as our room :smile:.
Apparently, when you book through Red Letter Days, if an upgrade is available at the time of
booking, you are automatically upgraded. Bargain! It was a great end to a fantastic day out
:smile:.

{: .aligncentre }
More photos can be found [here][gall]

[ep]: //www.edenproject.com/ "The Eden Project"
[bm]: //www.boscundlemanor.co.uk/ "Boscundle Manor"
[gall]: //photos.perry-online.me.uk/travel/cornwall-2012/2012/04/eden-project/ "The Eden Project Gallery"

branch_name: refs/heads/pages

gha_language: Ruby


text:
Ubuntu's Juju Now Supports systemd and Google Cloud Platform
================================================================================
> The Juju tool has been updated to version 1.23.3

**Udi Nachmany, Director of Ubuntu Certified Public Cloud at Canonical, announced the release of a new version of Juju, an open-source, solution-driven orchestration tool for Ubuntu Linux.**

According to the [announcement][1] and the official [release notes][2], Juju 1.23.3 is quite a major version that packs a lot of goodies for those of you who want to scale and manage environments on any cloud without too much hassle.

Prominent features of Juju 1.23.3 include support for Google Compute Engine (GCE), support for the systemd init system, support for Ubuntu 15.04 (Vivid Vervet), new charm actions, as well as better proxy support for for restrictive networks.

Additionally, the recently announced Juju release brings a new style restore, new messages, new blocks, and experimental support for Service Leader Elections, as well as addressable LXC containers and KVM instances on Ubuntu MAAS and AWS.

"On a related note, if you’re using Google Cloud Platform you’ve probably taken a look at the sleek Cloud Launcher Google have released recently. And if you looked closely, you also noticed that you can now spin up your Ubuntu VMs using this very friendly UI," says Udi Nachmany.

![](http://i1-news.softpedia-static.com/images/news2/Ubuntu-s-Juju-Now-Supports-systemd-and-Google-Cloud-Platform-483279-2.jpg)

--------------------------------------------------------------------------------

via: http://linux.softpedia.com/blog/Ubuntu-s-Juju-Now-Supports-systemd-and-Google-Cloud-Platform-483279.shtml

作者：[Marius Nestor][a]
译者：[译者ID](https://github.com/译者ID)
校对：[校对者ID](https://github.com/校对者ID)

本文由 [LCTT](https://github.com/LCTT/TranslateProject) 原创翻译，[Linux中国](https://linux.cn/) 荣誉推出

[a]:http://news.softpedia.com/editors/browse/marius-nestor
[1]:http://insights.ubuntu.com/2015/06/03/juju-support-for-google-cloud-platform/
[2]:https://jujucharms.com/docs/devel/reference-release-notes

url: https://raw.githubusercontent.com/getg8642/TranslateProject/969ca72ce4f00e263bc4411c21d6d2534431f7f8/sources/news/20150604 Ubuntu's Juju Now Supports systemd and Google Cloud Platform.md

branch_name: refs/heads/master

extension: md

license_type: permissive


text:
# Asteroids
Clone of the Atari game "Asteroids" based on the Processing graphics library.
This game was written as a code example for Java programming students at Digital Media Academy UBC, July 2017.

license: MIT

repository: CDFriend/Asteroids

repo_name: CDFriend/Asteroids


text:
---
layout: post
title: Bounded Context in DDD
bigimg: /img/image-header/yourself.jpeg
tags: [DDD]
---

## Table of contents
- [Given problem](#given-problem)
- [Solution with Bounded Contexts](#solution-with-bounded-contexts)
- [Some types of the Bounded Contexts' relationship](#some-types-of-the-bounded-contexts'-relationship)
- [Some common problems in Bounded Contexts](#some-common-problems-in-bounded-contexts)
- [Benefits and Drawbacks](#benefits-and-drawbacks)
- [Wrapping up](#wrapping-up)

## Given problem

## Solution with Bounded Contexts

1. Introduction to Bounded Context

    The term **bounded context** refers to the circumstances in which certain words of the ubiquitous language have certain meaning. Each context uses a particular dialect of the ubiquitous language, and each one is optimized to solve a specific problem.

    It means that the same business subject can be present under the different meanings in bounded contexts.

    For example:
    - Assuming that in the course registration application, at the moment, we only take care about two bounded contexts such as registration, and payment.

        In both bounded contexts, the same business object is a user/student.

        In registration bounded context, a user only need to provides a little bit of information to register a course, e.g, name of a user, age, sex, and the course.

        In payment bounded context, a user provides information to pay for this course such as the number of visa card, due date of card, the CVV number. This bounded context doesn't take care of other information, simply because of providing other information is redundancy.

    And a bounded context also means the solution space of the subdomain.

2. The relationship between Bounded Contexts and CAP Theorem

    Bounded contexts also offer benefits over enterprise data models in terms of the CAP theorem. An enterprise data model represents one tightly interconnected cluster of nodes in the distributed system where consistency is prioritized over availability. Any party that needs a consistent view of any part of the enterprise needs to make a connection to this one cluster. The more consumers that connect to it, the less available it becomes. The only way to combat this trend is to reduce the likehood of a network partition by spending more money on expensive hardware and network management.

    An enterprise model forces us to scale up rather than scaling out, but a bounded context represents a smaller cluster of nodes. It's decoupled from the other contexts. Because it has its own model, it's not reliant upon its connection to those other contexts. It can make decisions based only on the information that it has on hand. A bounded context could be written to favor availability over consistency. If the system of record is down, then the downstream system is unaffected. It already has a cache of the data that it needs organized and optimized for the problems that it is designed to solve. This isn't automatic. We have to conscientiously choose to build this kind of capability using CQRS, Event Sourcing, or any the other patterns and techniques, but this is a choice that we don't easily have if we use an enterprise data model.

3. Some examples about Bounded Contexts

    - Student Management System

        In this system, a student can register the online courses, pay for their courses, and then they will be tagged in these courses. Next, students and teachers will be annouced when a course starts.

        Based on their features, we have 4 bounded contexts:
        - Registration

            This is the first step to process the course registration of a student.

        - Payment

            This bounded context will be responsible for:
            - processing the course fee based on the information of a student's account bank.
            - take note the status of payment for their course.
            - pay money for teachers.

        - Scheduler

            After finishing the course's payment completely, the Scheduler bounded context will take action.
            - preventing the duplication or overlap times between courses.
            - check whether or not the teachers/courses are available.

        - Notification

    - Pharmacy application

        In the pharmacy network, we found that we had three bounded context. These were ```Rebates```, ```Sales```, and ```Performance```.

        - The Rebates bounded context captured all the rules of the rebate contracts. It was primarily the domain of the account manager. They would specify the measured product groups for each of the Rebates, their measurement methods, and the awarded tiers, and they would set up the roles of the contracts.

        - The Sales bounded context recorded the sales history of each member. Information from the e-commerce and fulfillment systems fed into the sales area.

        - The Performance bounded context calculated the performance of each member toward each of the rebates. It combined the rebated specifications with the sales data to perform its calculations. It presented the outcome of these calculation in the form of report cards for the members to view online.

        For example, in the Rebate context, we were primarily interested in providing the account manager with the capability of editing the roles of a rebate contract, but once a rebate enters the performance context, it needs to be optimized for a different purpose. In Performance context it needs to be optimized for rapid calculation. The data structures that we chose in each context were subtly different to satisfy each need.

        In the Rebate context, they tended to be more mutable and interactive so that the account managers could make changes, but in the Performance context, they tended toward immutable and pluggable strategies so that we could form them into a pipeline of calculations.

## Some types of the Bounded Contexts' relationship

1. Bounded Contexts's relationship

    In each bounded context, we will use ubiquitous language to model the business objects. There is no relationship between domain models of the other bounded contexts. The biggest benefits of this way is that it isolates the complexity of our business logic, and reduce the effects of the changes from the customer's requirements.

    But a question arises in our mind: **Do the bounded contexts have the relationship together?**. The answer is that absolutely they have, simply because to run completely the business logic, we need to combine bounded contexts together.

    Belows are some pattern groups that describe the relationships and integrations between bounded contexts.
    - Cooperation
    - Customer-Supplier
    - Seperate ways

2. Types of Bounded Contexts' relationship

    Supposed that in our project, each team will manage one bounded context. So, to understand about the relationship between bounded contexts, we need to be aware of the constraints between teams in a project.

    - Cooperation

        Cooperation patterns relate to the bounded contexts implemented by teams with well-established communication.

        Naturally, this requirement is fullfilled for bounded contexts that are implemented by the same team. It also applies to teams that have dependent goals, where the success of one team depends on the other's and vice versa. Again, the main criterion is the quality of the team's communication and collaboration.

        - Partnership

            In the partnership model, the integration between bounded contexts is coordinated in an ad hoc manner. A team can notify a second one about a change in the API, and the second team will cooperate and adapt. No drama or conflicts.

            ![](../../../img/Architecture-pattern/Domain-driven-design/bounded-contexts/partnership-in-cooperation.png)

            The coordination of integration is two-way. No one team dictates the language that is used for defining the contracts. The teams can work out the differences, and choose the most appropriate solution. Also, both sides cooperate in solving any integration issues that might come up. Neither team is interested in blocking the other one.

            Well-established collaboration practices, high levels of commitment, and frequent synchronizations between teams are all required for successful integration in this manner.

            Note that this pattern might not be a good fit for geographically distributed teams, since it may present synchronization and communication challenges.

        - Shared Kernel

            The shared kernel is a more formal way of defining a contract between multiple bounded contexts. Here, instead of ad hoc integrations, the contract is defined explicitly in a compiled library—the shared kernel. The library defines the integration methods and language used by both bounded contexts.

            ![](../../../img/Architecture-pattern/Domain-driven-design/bounded-contexts/shared-kernel-in-cooperations.png)

            The shared kernel is both referenced and owned by multiple bounded contexts. Each team is free to modify the compiled library that defines the integration contract. A change to the contract can break the other team's build, though; hence, as in the partnership case, this pattern requires high levels of commitment and synchronization between teams.

            A peculiar detail about the shared kernel pattern is that in a way, it contradicts a core principle of bounded contexts: that only one team can own a bounded context. Here we extract a shared part of multiple bounded contexts into its own bounded context. As a result, the shared bounded context is jointly owned by multiple teams.

            The key to implementing the shared kernel pattern is to keep the scope of the shared kernel small, and limited to the integration contract only.

        One team owning multiple bounded contexts
        - It's worth mentioning that a shared kernel is a natural fit for integrating bounded contexts that are owned and implemented by the same team. In such a case, an ad hoc integration of the bounded contexts can “wash out” the contexts’ boundaries over time. A shared kernel can be used for explicitly defining the integration contract.

            Moreover, in this scenario, the one team ownership principle is not broken—both bounded contexts are implemented by the same team.

    - Customer-Supplier

        The supplier bounded context provides a service for its customers. The service provider is **upstream**, and the customer or consumer is **downstream**.

        ![](../../../img/Architecture-pattern/Domain-driven-design/bounded-contexts/customer-supplier.png)

        Unlike in the cooperation case, both teams (upstream and downstream) can succeed independently. Hence, in most cases, we have an imbalance of power: either the upstream or the downstream team can dictate the integration contract.

        - Conformist

            In some cases the balance of power is in favor of the upstream team, which has no real motivation to support its clients’ needs. Instead, it just provides the integration contract, defined according to its own model—take it or leave it. Such power imbalances can be caused by integration with service providers that are external to the organization, or simply by organizational politics.

            If the downstream team can accept the upstream team’s model, the relationship between the bounded contexts is called conformist. The downstream team conforms to the upstream team’s model.

            ![](../../../img/Architecture-pattern/Domain-driven-design/bounded-contexts/conformist.png)

            The downstream team’s decision to give up some of its autonomy can be justified in multiple ways. For example, the contract exposed by the upstream team may be an industry-standard, well-established model, or it may just be good enough for the downstream team’s needs.

        - Anticorruption layer

            The anticorruption layer pattern addresses the case where a consumer is not willing to accept the supplier's model.

            As in the case of the conformist pattern, the balance of power in this relationship is still skewed toward the upstream service. However, in this case the downstream bounded context is not willing to conform. What it can do instead is translate the upstream bounded context’s model into a model tailored to its own needs via an anticorruption layer.

            ![](../../../img/Architecture-pattern/Domain-driven-design/bounded-contexts/anticorruption-layer.png)

            The anticorruption layer pattern addresses scenarios in which it is not desirable or worth the effort to conform to the supplier’s model, such as:
            - When the downstream bounded context contains a core subdomain. A core subdomain’s model requires extra attention, and adhering to the supplier’s model might impede the modeling of the problem domain.
            - When the upstream model is bad or inconvenient. If a bounded context conforms to a mess, it risks becoming a mess itself. This is often the case with integration with legacy systems.
            - When the supplier’s contract changes often, and the consumer wants to protect its model from such frequent changes. With an anticorruption layer, the changes in the supplier’s model only affect the translation mechanism.

            From the modeling perspective, the translation of the supplier’s model isolates the downstream consumer from foreign concepts that are not relevant to its bounded context. Hence, it simplifies the consumer’s ubiquitous language and model.

        - Open-Host service

            This pattern addresses the case where the power is skewed toward the consumers. The supplier is interested in protecting its consumers and providing the best service possible.

            To protect the consumers from changes in its implementation, the upstream supplier decouples its implementation model from the public interface. This decoupling allows the supplier to evolve its implementation and public models at different rates.

            ![](../img/../../Architecture-pattern/Domain-driven-design/bounded-contexts/open-host-service.png)

            The supplier’s public interface is not intended to conform to its ubiquitous language. Instead, it is intended to expose a protocol convenient for the consumers, expressed in an integration-oriented language. Hence, the public protocol is called the “published language.”

            In a sense, the open-host service pattern is a reversal of the anticorruption layer pattern: instead of the consumer, the supplier implements the translation of its internal model.

    - Seperate Ways

        This pattern can arise for different reasons, in cases where the teams are not willing or able to collaborate.

        - Communication Issues

            A common reason for avoiding collaboration is communication difficulties driven by the organization’s size or internal political issues. When teams have a hard time collaborating and agreeing, it may be more cost-effective for them to go their separate ways and duplicate functionality in multiple bounded contexts.

        - Generic Subdomains

            The nature of the duplicated subdomain can also be a reason for teams to go their separate ways. More specifically, when the subdomain in question is generic, if the generic solution is easy to integrate it may be more cost-effective to integrate it in each of the bounded contexts locally. An example is a logging framework; it would make little sense for one of the bounded contexts to expose it as a service, as the added complexity of integrating such a solution would outweigh the benefit of not duplicating the functionality in multiple contexts. Duplicating the functionality would be less expensive than collaboration.

        - Model Differences

            The difference in bounded contexts’ models can also be a reason to go separate ways. The models may be so different that a conformist relationship is not possible, and implementing an anticorruption layer would be more expensive than duplicating the functionality. In such a case, again, it’s more cost-effective for the teams to go their separate ways.

        The separate ways pattern should be avoided when integrating core subdomains. Duplicating the implementation of such subdomains would defy the company’s strategy to implement them in the most effective and optimized way.

3. Context Map

    To have an obviously background of a picture about the bounded context's relationship, we will plot them on a context map.

    The context map is a visual representation of the system’s bounded contexts and integrations between them. This visual notation gives valuable strategic insight on multiple levels:
    - High-level design

        A context map provides an overview of the system’s components and the models they implement.

    - Communication patterns

        A context map depicts the communication patterns between teams—for example, which teams are collaborating and which prefer “less intimate” integration patterns, such as the anticorruption layer and separate ways patterns.

    - Organization issues

        Finally, a context map can give an insight into organizational issues. For example, what does it mean if a certain upstream team’s downstream consumers all resort to implementing an anticorruption layer, or if all implementations of the separate ways pattern are concentrated around the same team?

## Some common problems in Bounded Contexts

1. The difference between Domain and Domain Model

    Domain represents the problem to solve.

    Domain Model is the model that implements the solution to the problem.

2. The difference between sub-domain and bounded context

    A subdomain is a segment of the Domain.

    A bounded context is a segment of the solution.

## Benefits and Drawbacks

1. Benefits

    - Understanding about bounded context helps us know more about the domain, and the problems that we will cope with. Then, providing the corresponding solution for them.

    - Each bounded context will be under a team's responsibility. So, we can develop in parallel, without affect to the other teams.

2. Drawbacks

    - Take a lot of time to be aware of our domain.

## Wrapping up

- Understanding about the meaning of the bounded contexts makes us reduce a lot of time when coding such as using a large enterprise data model through the whole of project, understanding quickly when communicating the requirements' changes.

Refer:

[Modelling Bounded Contexts with the Bounded Context Canvas: A Workshop Recipe](https://medium.com/nick-tune-tech-strategy-blog/modelling-bounded-contexts-with-the-bounded-context-design-canvas-a-workshop-recipe-1f123e592ab)

[DDD Strategic Patterns: How To Define Bounded Contexts](https://codeburst.io/ddd-strategic-patterns-how-to-define-bounded-contexts-2dc70927976e)

[BoundedContext](https://martinfowler.com/bliki/BoundedContext.html)

[Practical DDD: Bounded Contexts + Events => Microservices](https://www.infoq.com/presentations/microservices-ddd-bounded-contexts/)

[https://vngeeks.com/bounded-context/](https://vngeeks.com/bounded-context/)

[https://dzone.com/articles/implementing-a-bounded-context](https://dzone.com/articles/implementing-a-bounded-context)

[Defining Bounded Contexts — Eric Evans at DDD Europe](https://www.infoq.com/news/2019/06/bounded-context-eric-evans/)

[Discovering the Domain Architecture](https://www.microsoftpressstore.com/articles/article.aspx?p=2248811)

[https://www.oreilly.com/library/view/what-is-domain-driven/9781492057802/ch04.html](https://www.oreilly.com/library/view/what-is-domain-driven/9781492057802/ch04.html)

[https://robertbasic.com/blog/i-think-i-understand-bounded-contexts/](https://robertbasic.com/blog/i-think-i-understand-bounded-contexts/)


text:
# YNTDL Topology Printer
## Overview
The printer enables concise viewing and searching of a topology for easier debugging of topology files (and the parser itself).

## Usage
`./print_yntdl pathToTopologyFile [-a] [-n] [-l] [-i] [-p] [-h] [-m]`

`-a[app name]`: print only applications/[specified app]

`-n[node name]`: print only nodes/[specified node]

`-l[link name]`: print only links/[specified link]

`-i[interface name]`: prints only interfaces/[specified interface]

`-p[time]`: print positions/[at specific time]

`-h`: show this help text

`-m`: DOUBLE HELP, show the small manual

For each argument, if you want to search names that have spaces, wrap the string in quotes (e.g. -n"node name with spaces").

## How flags work
The app, node, link, and interface flags (a, n, l, i), when associated with a search will return all of the objects with a partial name match.

For example, in a topology with nodes: "node1", "node2", and "connect", if you ran the printer with `-nnode` it would return "node1" and "node2".

### Combining flags
If all those nodes had application "sl", `-nnode -al` would print all the application information for "sl" (it matched the 'l' in the name) on nodes 1 and 2. If there was no application containing the letter 'l', nothing would print.
Similarly "-ieth -n -l" would print all nodes and links with an interface containing "eth" in the name, and you could add additional criteria (such as a node search term) to narrow your results.

repository: OpenLabWorld/YNTDL

repo_name: OpenLabWorld/YNTDL


text:
# MicroGo
Experimenting with micro-services in GO.

MicroGo is an experimental project, definitely not a production server.

Architecture:

Product: Product microservice expose REST APIs to retrieve and edit products

Currency: Currency microservice exposes live currencies rate (retrieved from an online repo) using a gRPC client

Image: Image microservice is used to upload product images onto the server

repository: ancalabrese/MicroGo

branch_name: refs/heads/main

gha_license_id: MIT

repo_name: ancalabrese/MicroGo


text:
---
title: "Interaction between the microbiome and TP53 in human lung cancer"
authors:
- admin
- James R White
- Ashely J Vargas
- Valery V Bliskovsky
- Jessica A Beck
- Natalia von Muhlinen
- Eric C Polley
- Elise D Bowman
- Mohammed A Khan
- Ana I Robles
- Tomer Cooks
- Bríd M Ryan
- Robert Noah Padgett
- Amiran H Dzutsev
- Giorgio Trinchieri
- Marbin A Pineda
- Sven Bilke
- Paul S Meltzer
- Alexis N Hokenstad
- Tricia M Stickrod
- Marina R Walther-Antonio
- Joshua P Earl
- Joshua C Mell
- Jaroslaw E Krol
- Sergey V Balashov
- Archana S Bhat
- Garth D Ehrlich
- Alex Valm
- Clayton Deming
- Sean Conlan
- Julia Oh
- Julie A Segre
- Curtis C Harris
date: "2018-00-00"
doi: "10.1186/s13059-018-1501-6"

# Schedule page publish date (NOT publication's date).
publishDate: "2018-01-01T00:00:00Z"

# Publication type.
# Legend: 0 = Uncategorized; 1 = Conference paper; 2 = Journal article;
# 3 = Preprint / Working Paper; 4 = Report; 5 = Book; 6 = Book section;
# 7 = Thesis; 8 = Patent
publication_types: ["2"]

# Publication name and optional abbreviated publication name.
publication: "*Genome Biology, 19*(1)"
publication_short: ""

abstract:

# Summary. An optional shortened abstract.
summary:

tags:
- cancer
featured: false

# links:
# - name: ""
#   url: ""
url_pdf:
url_code: ''
url_dataset: ''
url_poster: ''
url_project: ''
url_slides: ''
url_source: ''
url_video: ''

# Featured image
# To use, add an image named `featured.jpg/png` to your page's folder.
# image:
#   caption: 'Image credit: [**Unsplash**](https://unsplash.com/photos/jdD8gXaTZsc)'
#   focal_point: ""
#   preview_only: false

# Associated Projects (optional).
#   Associate this publication with one or more of your projects.
#   Simply enter your project's folder or file name without extension.
#   E.g. `internal-project` references `content/project/internal-project/index.md`.
#   Otherwise, set `projects: []`.
projects: []

# Slides (optional).
#   Associate this publication with Markdown slides.
#   Simply enter your slide deck's filename without extension.
#   E.g. `slides: "example"` references `content/slides/example/index.md`.
#   Otherwise, set `slides: ""`.
slides: ""
---

gha_language: HTML


text:
# watcher-webpack-plugin

Webpack plugin to watch files with chokidar using glob. Runs webpack's subcompiler on file change if it is not already watched by webpack, runs callback on delete. This plugin is mainly used to enhance developer experience when generating typings on the fly when creating new files (*.module.css, *.graphql, ...) so you can use typings straight away when writing new TS files.

```
npm i @react-app/watcher-webpack-plugin
```

<br />
Example usage:

```
const WatcherWebpackPlugin = require('@react-app/watcher-webpack-plugin');

config.plugins = [
    ...
    new WatcherWebpackPlugin('src/**/*.(module.css|graphql)' ,{
        onRemove: (file) => Promise.all([
          unlinkIfExists(`${file}.d.ts`),
          unlinkIfExists(`${file}.types.ts`),
        ]),
    }),
];

```

repository: pristas-peter/react-app

gha_language: JavaScript

repo_name: pristas-peter/react-app


text:
# infra/gcp

Scripts and configuration files related to the management of the Kubernetes
project's GCP infrastructure

## layout

Loosely organized as follows:
- `bash/` to manage the bulk of our infrastructure (this came first)
- `static/` static files deployed directly to our infrastructure
- `terraform/` for managing the rest of our infrastructure

The bash came first, and the terraform is slowly growing as our comfort with it
grows. The decisions that led to some bash being in subdirectories were ad-hoc
or seemed like good ideas at the time; consider them undocumented and open to
reconsideration.

A more detailed listing thanks to `tree`, with some files manually elided:
```
.
├── bash
│   ├── ensure-{foo}.sh     # entrypoints for managing the set of foo infrastructure
│   ├── infra.yaml          # config for ensure-* scripts
│   ├── lib.sh              # included by all ensure-* scripts
│   ├── lib_{foo}.sh        # reusable bash functions for GCP service foo
│   ├── backup_tools        # TODO: bash related to prod artifact hosting
│   ├── cip-auditor         # TODO: bash related to prod artifact hosting
│   ├── namespaces          # bash to manage namespaces / rbac for cluster: aaa
│   ├── prow                # bash to manage k8s-infra-e2e* projects and prow secrets
│   └── roles               # bash and yaml to manage custom GCP IAM roles
├── static          # content related to prod artifact hosting
└── terraform
    ├── {foo}               # terraform managing resources in project foo
    │   └── {bar}/resources # k8s resources deployed to GKE cluster {bar}
    └── modules             # modules for re-use within this repo
```

## bash

### deploying changes

The bash in here needs to be manually run by humans. At the moment, this is
usually restricted to members of<EMAIL_ADDRESS>
### principles

- scope scripts appropriately
  - each `ensure-*.sh` script should manage a set of resources such that
    less-privileged-than-org-admin roles could run these scripts
  - each `lib_*.sh` script should contain functions that are generically
    reusable for a GCP service; consider these equivalent to terraform
    resources rather than richer terraform modules
  - only `ensure-*.sh` scripts should be executable, lib_*.sh
- use functions
  - use a `main` entrypoint at the bottom of the script to invoke functions
    defined above
  - easier to reuse other functions (vs. relying on order of definition)
- name functions consistently
  - use `ensure_[removed_]_{resource}` for creation of resources
  - older scripts use `empower_foo` for common/convenience IAM changes (e.g.
    multiple `ensure_foo_iam_binding` calls for a well-known group)
- define functions in the appropriate files
  - `ensure-*.sh` if they are domain-specific
  - `lib_foo.sh` if they are generic/reusable for GCP service Foo
  - `lib.sh` if they are domain-specific and need to be used by more than one
    ensure-*.sh script
- follow function arg conventions
  - write functions such that they can operate on a list of args, e.g.
    `enable_services foo bar baz`
  - use arrays more often, and pass those arrays as lists of args
    - arrays can support multi-line definitions of lists with comments, such
      as for complicated command line invocations
    - arrays can be dynamically modified or generated, e.g. dynamically adding
      a flag based on other configuration
- use constants or config instead of hardcodes
  - if the constant is domain-specific, keep it within the ensure-*.sh script
  - if the constant is needed across multiple ensure-*.sh scripts, put it in
    lib.sh, preferably sourced from infra.yaml
- keep output meaningful
  - when changing the configuration of an existing resource, output from the
    underlying tool is often unhelpful, like "changed foo"
  - prefer generating output that shows a diff of what changed, see the way
    IAM changes are displayed in lib_iam.sh for exampe
  - logging should generally happen at the ensure-*.sh script level instead
    of lower down in lib_*.sh functions
  - use the `foo 2>&1 | indent` pattern to indent all output from `foo`

## infra.yaml

To aid in transitioning away from bash, we are moving some of the config for
our infrastructure into a file (potentially a hierarchical set of files) called
`infra.yaml`.  At present it is only read by some bash, and its schema is an
unvalidated work in progress.

The schema is roughly as follows:
```yaml
infra:
  {project_type}: # ideally this ~= folder
    [managed_by:] # default script/file used to manage projects
    projects:
      {project_id}:
        [managed_by:] overrides default; script used to manage _this_ projec
```

Please refer to [`infra.yaml`](/infra/gcp/infra.yaml) to see which `ensure-*.sh`
scripts or terraform modules are responsible for which GCP projects

## terraform

See [infra/gcp/terraform/README.md](/infra/gcp/terraform/README.md)

gha_language: HCL


text:
[![Deploy to now](https://deploy.now.sh/static/button.svg)](https://deploy.now.sh/?repo=https://github.com/zeit/next.js/tree/master/examples/with-styled-components)

# Server‑rendered React 🏠⛺ Made by [Next.js](https://nextjs.org/) + [styled-components](https://github.com/styled-components/styled-components)
https://benivoncheni.space/

## How to use
Install it and run:

```bash
npm i
npm run dev
# or
yarn
yarn dev
```

repository: BeniCheni/next-fake-me

repo_name: BeniCheni/next-fake-me


text:
Kixx Server Errors
==================
Common use case ECMAScript error classes for Node.js. Includes stackable errors and error handling utilties for better error handling in asychronous situations.

Created by [Kris Walker](https://www.kriswalker.me) 2017 - 2023.

Inspired by [node-verror](https://github.com/TritonDataCenter/node-verror) and the corresponding [blog post](https://www.tritondatacenter.com/node-js/production/design/errors).

## Table of Contents

1. [Design Goals](#design-goals)
2. [Ethos](#ethos)
2. [Examples](#examples)
3. [API Reference](#api-reference)
5. [Copyright and License](#copyright-and-license)

## Design Goals
There are 3 main design goals of kixx-server-errors:

1. __Make it easy to construct clear, complete error messages intended for people.__ Clear error messages greatly improve both user experience and debuggability.
2. __Make it easy to construct objects with programmatically-accessible metadata__ (which we call informational properties). Instead of just saying "connection refused while connecting to <IP_ADDRESS>:80", you can add properties like "ip": "<IP_ADDRESS>" and "tcpPort": 80. This can be used for feeding into monitoring systems, analyzing large numbers of Errors (as from a log file), or localizing error messages.
3. __It also needs to be easy to compose Errors:__ higher-level code should be able to augment the Errors reported by lower-level code to provide a more complete description of what happened. Instead of saying "connection refused", you can say "operation X failed: connection refused".

## Ethos
The KIXX Server Errors ethos is provided by excerpts from this great blog post on [error handling in Node.js](https://www.tritondatacenter.com/node-js/production/design/errors). Reprinted here for posterity:

## Operational errors vs. programmer errors
It’s helpful to divide all errors into two broad categories:

__Operational errors__ represent run-time problems experienced by correctly-written programs. These are not bugs in the program. In fact, these are usually problems with something else: the system itself (e.g., out of memory or too many open files), the system’s configuration (e.g., no route to a remote host), the network (e.g., socket hang-up), or a remote service (e.g., a 500 error, failure to connect, or the like):

- failed to connect to server
- failed to resolve hostname
- invalid user input
- request timeout
- server returned a 500 response
- socket hang-up
- system is out of memory

__Programmer errors__ are bugs in the program. These are things that can always be avoided by changing the code. They can never be handled properly (since by definition the code in question is broken).

- tried to read property of “undefined”
- called an asynchronous function without a callback
- passed a “string” where an object was expected
- passed an object where an IP address string was expected

Operational errors are error conditions that all correct programs must deal with, and as long as they’re dealt with, they don’t necessarily indicate a bug or even a serious problem. “File not found” is an operational error, but it doesn’t necessarily mean anything’s wrong. It might just mean the program has to create the file it’s looking for first.

By contrast, programmer errors are bugs. They’re cases where you made a mistake, maybe by forgetting to validate user input, mistyping a variable name, or something like that. By definition there’s no way to handle those.

## Handling operational errors
Just like performance and security, error handling isn’t something that can be bolted onto a program that has no error handling already. Nor can you centralize all error handling in one part of the program, the same way you can’t centralize “performance” in one part of the program. Any code that does anything which might possibly fail (opening a file, connecting to a server, forking a child process, and so on) has to consider what happens when that operation fails. That includes knowing how it may fail (the failure mode) and what such a failure would indicate.

You may end up handling the same error at several levels of the stack. This happens when lower levels can’t do anything useful except propagate the error to their caller, which propagates the error to its caller, and so on. Often, only the top-level caller knows what the appropriate response is, whether that’s to retry the operation, report an error to the user, or something else. But that doesn’t mean you should try to report all errors to a single top-level callback, because that callback itself can’t know in what context the error occurred, what pieces of an operation have successfully completed, and which ones actually failed.

Let’s make this concrete. For any given error, there are a few things you might do:

- Deal with the failure directly.
- Propagate the failure to your client.
- Retry the operation.
- Blow up.
- Log the error — and do nothing else.

## (Not) handling programmer errors
There’s nothing you can do to handle a programmer error. By definition, the code that was supposed to do something was broken, so you can’t fix the problem with more code. If you could, you’d just use the error handling code in place of the broken code.

Some people advocate attempting to recover from programmer errors — that is, allow the current operation to fail, but keep handling requests. This is not recommended. Consider that a programmer error is a case that you didn’t think about when you wrote the original code. How can you be sure that the problem won’t affect other requests? If other requests share any common state (a server, a socket, a pool of database connections, etc.), it’s very possible that the other requests will do the wrong thing.

__The best way to recover from programmer errors is to crash immediately.__ You should run your programs using a restarter that will automatically restart the program in the event of a crash. With a restarter in place, crashing is the fastest way to restore reliable service in the face of a transient programmer error.

The only downside to crashing on programmer errors is that connected clients may be temporarily disrupted, but remember:

- By definition, these errors are always bugs. We’re not talking about legitimate system or network failures, but actual bugs in the program. They should be rare in production, and the top priority has to be to debug and fix them.
- For all the cases described above (and many more), the requests in flight are not necessarily going to complete successfully anyway. They may complete successfully, they may crash the server again, they may complete incorrectly in obvious ways, or they may complete wrongly in very subtle ways that are very hard to debug.
- In a reliable distributed system, clients must be able to deal with server failure by reconnecting and retrying requests. Network and system failure are a reality, whether or not the Node.js program itself is allowed to crash.
- If your production program is crashing so often that these disconnections are a problem, then the real problem is that the server is so buggy, not that it crashes in the case of a bug.

If disconnecting clients is a frequently problem because a server crashes so often, you should focus on the bugs that cause the service to crash — and make those exceptional — rather than trying to avoid crashing in cases where the code is obviously wrong. The best way to debug these problems is to configure Node to dump core on an uncaught exception. On both GNU/Linux and illumos-based systems, you can use these core files to see not only the stack trace where the program crashed, but the arguments to each of these functions and most other JavaScript objects as well, even those only referenced in closures. Even without core dumps configured, you can use the stack information and logs to make a start at the problem.

## Bad input: programmer error or operational error?
How do you know what’s a programmer error vs. an operational error? Quite simply: it’s up to you to define and document what types your function will allow and how you’ll try to interpret them. If you get something other than what you’ve documented to accept, that’s a programmer error. If the input is something you’ve documented to accept but you can’t process right now, that’s an operational error.

## Examples

```js
const fs = require('fs');
const { OperationalError, getFullStack } = require('kixx-server-errors');

function readConfigFile(callback) {
  fs.readFile('/etc/my-server/config.inf', function (err, res) {
    if (err) {
      const wrappedError = new OperationalError('Failed reading config file', {
        cause: err,
        info: {
          path: '/etc/my-server/config.inf',
          syscall: err.syscall
        }
      });
      callback(wrappedError);
    } else {
      callback(null, res);
    }
  });
}

// Assume this call fails with a Node.js ENOENT error:
readConfigFile(function (err, res) {
  if (err) {
    // Assuming the file does not exist, we would get an OperationalError wrapping
    // a Node.js ENOENT error
    assert.isEqual(OperationalError.NAME, err.name);
    assert.isEqual(OperationalError.CODE, err.code);

    // Notice the message is the combined message from the root cause Error and
    // the wrapping OperationalError.
    assert.isEqual("OperationalErrror: Failed reading config file => Error: ENOENT: no such file or directory, open '/etc/my-server/config.inf'", err.detail)

    // The error is annotated with other helpful information.
    assert.isEqual('/etc/my-server/config.inf', err.info.path);
    assert.isEqual('open', err.info.syscall);

    // Print the combined stack trace of the OperationalError and the wrapped error.
    console.error(getFullStack(err));
  }
});
```

## API Reference

__Error Classes__

- [OperationalError](#operationalerror)
- [ProgrammerError](#programmererror)
- [JsonParsingError](#jsonparsingerror)
- [ValidationError](#validationerror)

__HTTP Specific Error Classes__

- [BadRequestError](#badrequesterror)
- [ConflictError](#conflicterror)
- [ForbiddenError](#forbiddenerror)
- [MethodNotAllowedError](#methodnotallowederror)
- [NotAcceptableError](#notacceptableerror)
- [NotFoundError](#notfounderror)
- [NotImplementedError](#notimplementederror)
- [UnauthorizedError](#unauthorizederror)
- [UnprocessableError](#unprocessableerror)
- [UnsupportedMediaTypeError](#unsupportedmediatypeerror)

__Helpers__

- [getFullStack()](#getfullstack)
- [getMergedInfo()](#getmergedinfo)
- [isProgrammerError()](#isprogrammererror)

### OperationalError
Use for wrapping low level operational errors like ENOENT and ECONNREFUSED.

OperationalError: Static properties:

static prop name | description | type
-----------------|-------------|-----
NAME | The default instance name | String
CODE | The default instance code | String
TITLE | The default instance title | String

OperationalError: Constructor arguments:

name | description | type | required | default
-----|-------------|------|----------|---------
message | The message string used in the base error | String | yes | none
spec | The specification object to set specific parameters | Object | optional | `{}`
sourceFunction | The function to pass into Error.captureStackTrace(). | Function | optional | undefined

OperationalError: Optional specification properties:

prop name | description | type | default
----------|-------------|------|--------
spec.cause | The cause error to wrap | Error or subclass of Error | `null`
spec.code | Assign the error code property instead of the default | String or Number | `OperationalError.CODE`
spec.title | Assign the error title property instead of the default | String | `OperationalError.TITLE`
spec.fatal | Assign the error fatal property instead of the default | Boolean | `false`
spec.info | Use as the error info object | Object | `{}`

OperationalError: Instance properties:

prop name | description | type
----------|-------------|-----
name | The error name. `OperationalError.NAME` | String
message | The composed message property from this error and all causal errors | String
code | Will be spec.code or `OperationalError.CODE` | String
title | Will be spec.title or `OperationalError.TITLE` | String
detail | The composed name:message from all causal errors | String
fatal | Will be spec.fatal or `false` | Boolean
info | Will be spec.info or an empty object | Object

### getFullStack()
Take any Error or "Error like" object and return the stack trace as a string. If the Error object has causal errors (an .errors Array property) then those stack traces will also be appended to the returned string delineated by "caused by:".

`getFullStack(err)`

parameter | description | type | required | default
----------|-------------|------|----------|---------
err | Any Error object | Error | yes | none

```js
const { getFullStack, ProgrammerError } = require('kixx-server-errors');

const err = new Error('Root Cause');
const topError = new ProgrammerError('You did something wrong', { err });

// Print out the combined stack trace of the top level error and all causal errors.
console.log(getFullStack(topError));

// Will print:
/*
ProgrammerError: You did something wrong: Root Cause
    at Object.<anonymous> (/Users/You/your-file.js:4:18)
    at Module._compile (node:internal/modules/cjs/loader:1103:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1155:10)
caused by:
Error: Root Cause
    at Object.<anonymous> (/Users/You/your-file.js:3:18)
    at Module._compile (node:internal/modules/cjs/loader:1103:14)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1155:10)
*/
```

### getMergedInfo()
Take any Error or "Error like" object and return the merged `.info` property from each one.

`getMergedInfo(err)`

parameter | description | type | required | default
----------|-------------|------|----------|---------
err | Any Error object | Error | yes | none

```js
const { getMergedInfo, OperationalError } = require('kixx-server-errors');

const nativeError = new Error('Plain error');

const operror1 = new OperationalError('Wrapper 1', {
  err: nativeError,
  info: { foo: 1, two: 'y' }
});

const operror2 = new OperationalError('Wrapper 2', {
  err: operror1,
  info: { foo: 2, one: 'z' }
});

const operror3 = new OperationalError('Wrapper 3', {
  err: operror2,
  info: { foo: 3, three: 'x' }
});

const info = getMergedInfo(operror3);

// The most recent error takes precedent.
assert.isEqual(3, info.foo);
assert.isEqual('x', info.three);
assert.isEqual('y', info.two);
assert.isEqual('z', info.one);
```

### isProgrammerError()
Take an Error or "Error like" object and determine if the given error or any nested causes are ProgrammerErrors. Will detect instances of ProgrammerError or any error with the name 'ProgrammerError'.

parameter | description | type | required | default
----------|-------------|------|----------|---------
err  | Any Error object | Error | yes | none

## Copyright and License
Copyright: (c) 2018 - 2023 by Kris Walker (www.kriswalker.me)

Unless otherwise indicated, all source code is licensed under the MIT license. See MIT-LICENSE for details.

repository: kixxauth/kixx-server-errors

repo_name: kixxauth/kixx-server-errors


text:
Widget Registry CLI

The widget registry CLI allows you to create a registry from your existing components repository. It does not matter if you are using Storybook, Fractal, ... The CLI will create the registry for you.

## Turn Your Components into Widgets

repository: KeyboardCowboy/webpack-cli

repo_name: KeyboardCowboy/webpack-cli


text:
# crud4playplugin

this plugin can be used to generate the boiler plate code to access a
database and provide a rest api for it that offers create read update delete.
I use Slick for the database access.

from the demo blog project for example

GET     /tables/blog ( with optional query params sortBy and direction)

GET     /tables/blog/<by field>/<value>   (this queries database where <by field> = <value> . You can also use optional query params sortBy and direction)

GET     /tables/blog/<primary key>

POST    /tables/blog

PUT     /tables/blog

DELETE  /tables/blog/:blog_id

Note if GET <by field>/<value> queries a timestamp it should be passes a long value not text representation

slick,controller and routes generated from single configuration file.

You have to create the database as well as configure it in application.conf

There are sample test projects under directory

a simple project

[src/sbt-test/crudplugin/playhello](src/sbt-test/crudplugin/playhello)

that shows how the configuration file

[src/sbt-test/crudplugin/playhello/conf/crud/Request.conf](src/sbt-test/crudplugin/playhello/conf/crud/Request.conf)

generates some simple code with an event simple form to create entries. There are
also from curl commands as well.

A more complicated 2 table example.

[src/sbt-test/crudplugin/blog](src/sbt-test/crudplugin/blog)

This one is a simple blog that shows a user table and a blog table. The user
table holds 1 entry for demo purposes, see
[src/sbt-test/crudplugin/blog/conf/evolutions/1.sql](src/sbt-test/crudplugin/blog/conf/eveolutions/1.sql). Without logging on the blog api is unavilable.

The example project shows uses a Module to override the generated Action implementation
and the project provides its own authentication classes. The project also includes
a better example of mapping the date from json to a timestamp in the conf file
```
object_mapper = "extends DateConvert(inDateFormat=\"YYYY-MM-dd HH:mm:ss\" , outDateFormat=\"YYYY-MM-dd HH:mm:ss\")"
```

## details
The configuration file is used to generate some slick db code to perform usual sql operations.
The generated scala code is directory target/scala-2.12/src_managed/main

The plugin will scan for all files under conf/crud and generate a set of
files
* Model.scala holds the case class that represents the db table
* TableOperation.scala holds the slick code for db operations
* Api.scala is the scala code for play to expose api
* DataConvert is a class for handling mapping db timestamp to json
* CrudAction is a trait and class for the api that can be overriden to implement
authentication. The blog project shows some simple authentication on the api's.

the plugin also generates a routes file in conf using the package as
defined in the equivalent conf/crud file

so in the example project the package is org.bjason and the config file is Request so
we end up with this file

org.bjason.request.routes

that needs to be included in routes file with this

-> /tables/request org.bjason.request.Routes

if we want to be able to call the crud api with a uri like

/table/request

## conf file format
```
model = {
    name = "<same as filename>"
        packageName = "<start of package name>"
        fields = [
                // a list of the fields now
                {
                        name = "<scala field name>"
                        type = "<scala type, can be an Option too>"
                        column = "<database column name>"
                        column_definition = "<optional entry see http://slick.lightbend.com/doc/3.0.0/schemas.html>"
                }, ....

        ]
        object_mapper = "<optional if the table has a timestamp to convert>"
}
```

the plugin can be built and tested using
```
sbt:crud4playplugin> scripted
```

Automated builds here

[https://app.travis-ci.com/github/bernardjason/crud4playplugin](https://app.travis-ci.com/github/bernardjason/crud4playplugin)

and to release code

```
sbt release
```


text:
# Capricorn - (Winter)

| Capricon 1  | December 22 |
| ----------- | ----------- |
| Capricon 2  | December 23 |
| Capricon 3  | December 24 |
| Capricon 4 - Yuletide Day  | December 25 |
| Capricon 5  | December 26 |
| Capricon 6  | December 27 |
| Capricon 7  | December 28 |
| Capricon 8  | December 29 |
| Capricon 9  | December 30 |
| Capricon 10 | December 31 |
| Capricon 11 | January 1   |
| Capricon 12 | January 2   |
| Capricon 13 | January 3   |
| Capricon 14 | January 4   |
| Capricon 15 | January 5   |
| Capricon 16 | January 6   |
| Capricon 17 | January 7   |
| Capricon 18 | January 8   |
| Capricon 19 | January 9   |
| Capricon 20 | January 10  |
| Capricon 21 | January 11  |
| Capricon 22 | January 12  |
| Capricon 23 | January 13  |
| Capricon 24 | January 14  |
| Capricon 25 | January 15  |
| Capricon 26 | January 16  |
| Capricon 27 | January 17  |
| Capricon 28 | January 18  |
| Capricon 29 | January 19  |

repository: nazrinrat/veda-warez

gha_license_id: NOASSERTION

repo_name: nazrinrat/veda-warez


text:
# Unipus Helper
* **[中文版](./doc/README_CN.md)**

[![LICENSE](https://img.shields.io/badge/license-Anti%20996-blue.svg)](https://github.com/996icu/996.ICU/blob/master/LICENSE)

## Introduction
It is a Chrome Extension whose purpose is to liberate broad Chinese college students who suffer oppression by Unipus. Liberate them from boring blank filling and Unipus's devils talons.

## Functions
* Fill the blank with correct answer **automatically**.
* Generate mistakes to mislead the evil Unipus's system **automatically**.
* Submit all **automatically**.
* ~~Hang up online 2 hours everyday.~~(developing)

## How to use it
* It is easy to use. Just load the unzip file under **developer mode** on your Chrome.
* If you don't use Chrome, you can use it in the same way with a **Chromium core** browser.

> If you have any problem about it, you can open an issues.

## About us
We are a group of college students who are tired of filling the blank on Unipus in vain. We want to liberate students who suffer oppression by Unipus with use our technological capability.

## Join us
**We need you!**
No matter you can code and be a developer or just help us to format key files. History will witness your contribution and all the user will never forget your distinctive contribution.

## To contribute
* **[Document of "To Contribute"](./doc/ToContribute.md)**
* **["如何贡献"中文版](./doc/ToContribute_CN.md)**

## Remarkable Contributors

## Stargazers over time

[![Stargazers over time](https://starchart.cc/Algebra-FUN/Unipus-Helper.svg)](https://starchart.cc/Algebra-FUN/Unipus-Helper)

repository: Algebra-FUN/Unipus-Helper

repo_name: Algebra-FUN/Unipus-Helper


text:
# Handling Unsupported Inbound Messages

<img src="https://developer.nexmo.com/assets/images/Vonage_Nexmo.svg" height="48px" alt="Nexmo is now known as Vonage" />

The demo shows you how to determine if an inbound Message from a social-messaging platform (e.g. WhatsApp, Facebook Messenger, or Viber) is of an unsupported type.

## Welcome to Vonage

<!-- change "github-repo" at the end of the link to be the name of your repo, this helps us understand which projects are driving signups so we can do more stuff that developers love -->

If you're new to Vonage, you can [sign up for a Vonage API account](https://dashboard.nexmo.com/sign-up?utm_source=DEV_REL&utm_medium=github&utm_campaign=unsupported-types) and get some free credit to get you started.

## How to Run

Install express and body parser with:

`npm install express body-parser`

Run the app with `node server.js`

Follow the guide for how to configure webhooks. You can do this with the [full Messages API](https://developer.nexmo.com/messages/code-snippets/inbound-message) - or if you're just getting started, with the [Messages API Sandbox](https://developer.nexmo.com/messages/concepts/messages-api-sandbox#configure-webhooks). With that done, all that's left to do is to send a message through a channel of your choice to your app!

## Getting Help

We love to hear from you so if you have questions, comments or find a bug in the project, let us know!

* Open an issue on this repository
* Tweet at us! We're [@VonageDev on Twitter](https://twitter.com/VonageDev)
* Or [join the Vonage Developer Community Slack](https://developer.nexmo.com/community/slack)

## Further Reading

* Check out the Developer Documentation at <https://developer.nexmo.com>

<!-- add links to the api reference, other documentation, related blog posts, whatever someone who has read this far might find interesting :) -->


text:
# Moogle

We could not find a decent webpage to quickly crop an image, so here's one.

<img src='https://raw.githubusercontent.com/hundredrabbits/Moogle/master/PREVIEW.jpg' width="600"/>

## Commands

- `moogle.select(0,0,860,520)` select target area.

## Controls

- `s` jpg.
- `e` png.

## Ecosystem

- [Poodle](https://hundredrabbits.github.io/Poodle/), scene
- [Noodle](https://hundredrabbits.github.io/Noodle/), sketch
- [Moogle](https://hundredrabbits.github.io/Moogle/), crop


text:
# Changelog
All notable changes to this project will be documented in this file.

## [0.4.0] - 2019-07-24
### Changed
- Add Linux support.
- Huge refactor.
- Improve BSD code to provide a cross platform compatible API.
- [BREAKING] Make static functions private, all calls now go through the Ctl object.

## [0.3.0] - 2019-01-07
### Changed
- Improve error handling.
- Publish CtlInfo struct.
- Add Cirrus CI script.

## [0.2.0] - 2018-05-28
### Changed
- Add iterator support (thanks to Fabian Freyer!).
- Add struct interface for control.
- Add documentation for macOS.
- Use failure create for error handling.

NOTE: Includes API breaking changes.

## [0.1.4] - 2018-01-04
### Changed
- Fix documentation link
- Fix test on FreeBSD

## [0.1.3] - 2018-01-04
### Added
- Macos support.

## [0.1.2] - 2017-05-23
### Added
- This changelog.
- API to get values by OID.
- Example value\_oid\_as.rs
- Node types can also contain data so treat Nodes same as Struct/Opaque.

repository: LuoZijun/sysctl-rs

repo_name: LuoZijun/sysctl-rs


text:
As part of aion compliance kit, this document describes avm integration needs in detail.

## 0 Conventions:

- operation ID: [group-number]
- abbreviation of multiple operations: [group-[x, y]], represents [group-x], [group-(x+1)], ... , [group-(y-1)], [group-y]
- Rm: Result of AVM
    - Rm.S: status code
    - Rm.E: energy used
    - Rm.D: return data
    - Rm.L: logs
- Priority:
    - x: avm internal or for debug use
    - xx: getter or computation ops
    - xxx: operations or signals which implicitly affect global state
    - xxxx: operations which explicitly affect global state

## 1 Motivation

keep State Root and Receipt Root the same among multiple Aion Blockchain clients.

## 1 Global variables

The global variables are initialized in kernel. They **MUST** be correct to ensure avm execution.

- [1-1] get_address: xx
- [1-2] get_caller: xx
- [1-3] get_origin: xx
- [1-4] get_enrgylimit: xx
- [1-5] get_energyprice: xx
- [1-6] get_value: xx
- [1-7] get_data: xx
- [1-8] get_blocktimestamp: xx
- [1-9] get_blocknumber: xx
- [1-10] get_blockenergylimit: xx
- [1-11] get_blockcoinbase: xx
- [1-12] get_blockdifficulty: xx

## 2 Atomic Operations

- [2-1] put_storage: xxxx
- [2-2] get_storage: xxxxx
- [2-3] get_balance: xxxxx
- [2-4] get_balanceofthiscontract: xxxxx
- [2-5] get_codesize: x
- [2-6] get_remainingenergy: xx
- [2-7] log: xxxx
- [2-8] log1: xxxx
- [2-9] log2: xxxx
- [2-10] log3: xxxx
- [2-11] log4: xxxx
- [2-12] blake2b: xx
- [2-13] sha256: xx
- [2-14] keccak256: xx
- [2-15] edverify: xx
- [2-16] revert: xxx
- [2-17] invalid: xxx
- [2-18] print: x
- [2-19] println: x

## 3 Composite Operations

- [3-1] call: xxx
- [3-2] create: xxxx
- [3-3] selfdestruct: xxxx

## 4 Exceptions

all exceptions must be correctly handled, including gas cost and global state.

### 4.1 Inner Signals

- success
- rejected
- rejected_insufficient_balance
- rejected_invalid_nonce
- failed
- failed_invalid_data
- failed_out_of_energy
- failed_out_of_stack
- failed_call_depth_limit_exceeded
- failed_revert
- failed_invalid
- failed_exception
- failed_rejected
- failed_abort
- failed_unexpected
- **any hidden exceptions which are not dealed**

### 4.2 Interface Signals

- [4-1] success: xxx
- [4-2] failure (all inner signals except success): xxx

## 5 Test Flow

- 1. base environment: [1-[1,12]]
- 2. computation: [2-[12,15]]
- 3. status code: [2-16], [2-17], [4-1], [4-2]
- 4. contract: [2-[1,11]], [3-[1,3]]

step 3 and 4 should compare results with another kind of client

repository: aion-camus/spec-test

repo_name: aion-camus/spec-test


text:
# Storage example

This example tests cross-origin requests in extensions.

1. update app.json to have

~~~
	"extensions": [
		{
			"url": "projects_root\\extension-example\\cross-origin"
		}
	]
~~~

2. start Runtime with app.json

3. running the following code in devtools->console for the extension should generate CORS error

~~~
let res = await fetch('https://example.com')
~~~

4. running the following code in devtools->console for the extension should work

~~~
let res = await fetch('https://openfin.co')
~~~

repository: wenjunche/extension-example

repo_name: wenjunche/extension-example


text:
# [Middle of the Linked List][title]

## Description

Given a non-empty, singly linked list with head node head, return a middle node of linked list.

If there are two middle nodes, return the second middle node.

**Example1**
```
Input: [1,2,3,4,5]
Output: Node 3 from this list (Serialization: [3,4,5])
The returned node has value 3.  (The judge's serialization of this node is [3,4,5]).
Note that we returned a ListNode object ans, such that:
ans.val = 3, ans.next.val = 4, ans.next.next.val = 5, and ans.next.next.next = NULL.
```

**Example2**
```
Input: [1,2,3,4,5,6]
Output: Node 4 from this list (Serialization: [4,5,6])
Since the list has two middle nodes with values 3 and 4, we return the second one.
```

**Tags:** Linked List

## 解读题意

## 思路1
快慢指针

```java
class Solution {

    public ListNode middleNode(ListNode head) {
        if (head == null || head.next == null)
            return head;

        // 定义快慢指针
        ListNode fast = head;
        ListNode slow = head;

        // 快指针每次走两步而慢指针每次走一步
        while (fast != null && fast.next != null) {
            fast = fast.next.next;
            slow = slow.next;
        }

        return slow;
    }

}
```
time complexity:O(n)

[title]: https://leetcode.com/problems/middle-of-the-linked-list/

repository: mcrwayfun/java-leet-code

repo_name: mcrwayfun/java-leet-code


text:
---
title: Anyone need more fediverse?
date: 2023/01/08
draft: false
description: Running a single user Mastodon instance can be lonely. But it doesn't have to be!
tags:
  - mastodon
  - fediverse
  - homelab
  - selfhosted
---

I've been running a single user Mastodon instance for a few months now. It's been running smoothly and has let me interact with the exodus of users from the bird site. But it can be lonely on a single user instance. Discovery can be hard, following #hashtags only shows you posts from
people you already follow, and you can't easily just browse the public timeline of some of the larger instances. I had read about [public relays](https://tool.motoretta.ca/2022/11/11/active-mastodon-relays/) but that seemed more like a firehose approach with too much content of questionable quality. I wanted something more curated.

## Enter GetMoarFediverse
While looking for a solution I stumbled upon [GetMoarFediverse](https://github.com/g3rv4/GetMoarFediverse#you-can-run-it-on-docker) by [@g3rv4@mastodonte.tech](https://mastodonte.tech/@g3rv4). It utilizes another one of @g3rv4's projects [FakeRelay](https://github.com/g3rv4/FakeRelay/) to allow you to follow hashtags, separately from your Mastodon followed hashtags, and automatically import posts.

### Running GetMoarFediverse
There are a few different steps, spread across a few containers, to be able to run a fully selfhosted version of GetMoarFediverse. There are several different options on how to run each step but in the spirit of self-hosting my own Mastodon instance, I wanted to run everything myself. The steps are as follows:

1. Configure and run FakeRelay
2. Add an authorized instance to FakeRelay
3. Add FakeRelay to your Mastodon instance
4. Configure and run GetMoarFediverse
5. Configure GetMoarFediverse to run on a schedule

### Configuring and running FakeRelay
[FakeRelay](https://github.com/g3rv4/FakeRelay/) has pretty good documentation in it's README but you have to make sure to follow the guide for [I want to run it myself!](https://github.com/g3rv4/FakeRelay/#i-want-to-run-this-myself). I use [Traefik](https://doc.traefik.io/traefik/) as my reverse proxy as well, so my `docker-compose.yaml` looks like this:

```yaml:docker-compose.yaml
fakerelay:
    image: 'ghcr.io/g3rv4/fakerelay:latest'
    command: web
    hostname: fakerelay
    container_name: fakerelay
    environment:
      - ASPNETCORE_ENVIRONMENT=Production
      - ASPNETCORE_URLS=http://+:5000
      - CONFIG_PATH=/data/config.json
    restart: unless-stopped
    volumes:
      - '/mnt/data/appdata/fakerelay:/data'
    ports:
      - 5000:5000
    labels:
      traefik.http.routers.fakerelay.rule: Host(`fakerelay.alexdobin.com`)
  cli:
    image: 'ghcr.io/g3rv4/fakerelay:latest'
    volumes:
      - '/mnt/data/appdata/fakerelay:/data'
    labels:
      - traefik.enable=false
```
‼ Do not immediately run `docker-compose up`. You need to configure the `config.json` file first using the `cli` container! You will want to run the following command to generate a new `config.json` file:

```bash
docker-compose run --rm cli config your-relay-host.example.com
```

You should now be able to start the main `fakerelay` container with `docker-compose up -d`. You should now be able to access the FakeRelay web interface at `http://fakerelay.alexdobin.com` (or whatever you set your hostname to).

### Adding an authorized instance to FakeRelay
You can use the `cli` container to interact with FakeRelay. FakeRelay can be used with multiple instances and requires authorization for each Mastodon instance you want to use it with. This is easy enough with our single instance, just run the following command:

```bash
docker-compose run --rm cli instance add social.alexdobin.com
```

You will now see an API key for your instance. Copy this to a safe place, you will need it later on to configure GetMoarFediverse.

### Adding FakeRelay to your Mastodon instance
Now that we have our FakeRelay instance running and authorized, we need to add it to our Mastodon instance. This is done by navigating to the admin portal on your Mastodon instance (/admin/relays). You will be prompted to add a new relay and should use the configured domain for your fake relay followed by `/inbox` (e.g. `http://fakerelay.alexdobin.com/inbox`). After submitting and waiting a few seconds, you should see the status update to `Enabled` next to your relay.

### Configuring and running GetMoarFediverse
There are several options for how to run `GetMoarFediverse`, including utilizing GitHub actions. Instead we will follow the docker-compose method outlined in the [README](https://github.com/g3rv4/GetMoarFediverse#you-can-run-it-on-docker) to keep everything running on our own server. The `docker-compose.yaml` file looks like this:

```yaml:docker-compose.yaml
  getmoarfediverse:
    container_name: getmoarfediverse
    image: 'ghcr.io/g3rv4/getmoarfediverse:latest'
    volumes:
      - '/mnt/data/appdata/getmoarfediverse:/data'
```

Before running, you will want to create the configuration file `config.json` needed for `GetMoarFediverse`. Below is an example configuration that I have used, placing it in `/mnt/data/appdata/getmoarfediverse` or wherever you have locate the volume for your container.

```json:config.json
{
  "FakeRelayUrl": "https://fakerelay.alexdobin.com",
  "FakeRelayApiKey": "YOUR_API_KEY_HERE",
  "Tags": [
    "javascript",
    "typescript",
    "svelte",
    "sveltekit",
    "100DaysOfHomeLab"
  ],
  "Instances": [
    "hachyderm.io",
    "mastodon.social",
    "fosstodon.org"
  ]
}
```

You should replace `YOUR_API_KEY_HERE` with the API key that you received earlier when registering your instance with FakeRelay. There are several options for configuring `GetMoarFediverse` but for now this has done a good job at bringing in new content that I might want without overwhelming me or my server.

### Configuring GetMoarFediverse to run on a schedule
GetMoarFediverse works great when it runs but it does not have any scheduling built in. I am using [Chadburn](https://github.com/PremoWeb/chadburn) which is a fork of [Ofelia](https://github.com/mcuadros/ofelia) with several quality of life fixes. I will cover setting Chadburn up in a separate blog post but adding the below to my Chadburn configuration was all I needed to run it with relative frequency.

```ini
[job-run "getmoarfediverse"]
schedule = @every 10m
container = getmoarfediverse
```

branch_name: refs/heads/source

gha_language: Svelte


text:
# AWS SAM Demos

## Description
This repo is a collection of simple demos using the [AWS Serverless Application Model](https://github.com/awslabs/serverless-application-model) framework.

## Testing
You can use the [aws-sam-local](https://github.com/awslabs/aws-sam-local) program to be able to locally test your functions. Here are some useful commands to help with that:
```
# Validate syntax of the template file
sam validate <name-of-template-file>

# Run function/API locally to test
sam local start-api

# Generate sample Lambda events. These can be used to test Lambda invocation.
sam local generate-event s3|sns|kinesis|dynamodb|api|schedule >> event.json

```

## Examples
Currently there are only a few examples:
- simple hello world
- multiple handler products example

## LICENSE
MIT


text:
+++
title = "Azure CLI"
date =  2020-10-19T15:02:42-07:00
weight = 5
+++

Open the Azure Cloud Shell and sign in with your account. Select the Bash version of Azure Cloud Shell.

{{% button href="https://shell.azure.com" %}}Azure Cloud Shell{{% /button %}}

We need to create some Bash variables for the values that we will be using throughout the workshop. If you select a different value, remember it for the rest of the exercises in this workshop. Run the following commands to record these values in Bash variables.

```bash
REGION_NAME=westus
RESOURCE_GROUP=jfrog-aks-workshop
SUBNET_NAME=aks-subnet
VNET_NAME=aks-vnet
```

At any point, the ```echo``` command can be used to show the value of a variable.

```bash
echo $RESOURCE_GROUP
```

![azure_cli](/images/azure_cli.png)

repository: stevewjfrog/azureworkshop

repo_name: stevewjfrog/azureworkshop


text:
#### Overview

This is a simple implementation of REST API for ClamAV virus scanner. You can use it to scan files uploaded by users, before they are saved or put into final destination, or to scan files on demand.

![Animation](./docs/images/animation.gif)

#### How to start clamav-rest-api?

First of all you have to have running ClamAV instance configured to accept TCP connections from `clamav-rest-api` instances. For more details I will guide you to CalmAV documentation ([here](https://blog.clamav.net/2016/06/regarding-use-of-clamav-daemons-tcp.html) and [here](https://www.clamav.net/documents/configuration#clamdconf)) but it's enough to say that you need `TCPSocket 3310` and eventually `TCPAddr` in your `clamd.conf` file. The easiest way is to use docker image with ClamAV already configured. I'm using `mailu/clamav` docker [image](https://hub.docker.com/r/mailu/clamav) during tests and development.

**_Note_:**
You have to give `mailu/clamav` couple of minutes to start because it needs to download new signatures from ClamAV servers (update its viruses database).

**_Recommended_** way of using `clamav-rest-api` is to start it as docker container or on k8s cluster (see [Configuration](#Configuration) below):

In [examples](./examples/k8s) directory there are kubernetes YAML files to create `configMap`, `deployments` and `services`. Just run `kubectl` command to create them in proper order:

```bash
kubectl apply -f cra-configmap.yml
kubectl apply -f clamavd.yml
kubectl apply -f cra.yml
```

`clamav-rest-api` service is published on `nodePort` 30080. On cluster network it is available on port 3000.

To start using clamav-rest-api on docker environment follow the steps below:

```
docker run -d -p 8080:8080 \
-e NODE_ENV=production \
-e APP_PORT=8080 \
-e APP_FORM_KEY=FILES \
-e CLAMD_IP=<IP_ADDRESS> \
benzino77/clamav-rest-api
```

or

```
docker run -d -p 8080:8080 -v /local/path/to/.env:/clamav-rest-api/.env benzino77/clamav-rest-api
```

or, if you are running docker in Swarm mode, you can use `configs`

```
docker config create cra /path/to/.env
docker service create --name clamav-rest-api --publish published=8080,target=8080 --config src=cra,target="/clamav-rest-api/.env" benzino77/clamav-rest-api
```

There is also an [example](./examples/docker-compose.yml) how to run _full_ stack on docker Swarm (clamavd and clamav-rest-api combined):

```
docker stack deploy -c docker-compose.yml cra
```

You can also start `clamav-rest-api` by cloning the repo and run commands listed below:

```
npm install
npm install -D # if you want to run tests or examples
# Configuration described below - needed before start app
npm start
```

##### Configuration

`clamav-rest-api` needs some information to run properly. For example it needs to know where to find ClamAV. This kind of information can be provided by `.env` file or by setting environemnt variables. Example `.env` file can be find [here](./.env.example). What you need to do is to copy `.env.example` file to `.env` and edit it to provide configuration parameters which meet your needs.
Here is a short description of those parameters:

- `NODE_ENV` - describe application environment (production, development, test, etc.)
- `APP_PORT` - port number on which `clamav-rest-api` will listen to requests
- `APP_FORM_KEY` - form key (element name) used when uploading files to scan (see [examples directory](examples/)). `clamav-rest-api` will only accept files uploaded with this form key.
- `APP_MORGAN_LOG_FORMAT` - log format used by `clamav-rest-api` to display information about requests. More infor can be found [here](https://github.com/expressjs/morgan#predefined-formats)
- `APP_MAX_FILE_SIZE` - max size (in bytes) of **single** file which will be accepted by `clamav-rest-api`. You have to also take care of `MaxScanSize`, `MaxFileSize`, etc. in your `clamd.conf` file.
- `APP_MAX_FILES_NUMBER` - maximum number of files uploaded to scan
- `CLAMD_IP` - ClamAV IP adress
- `CLAMD_PORT` - ClamAV listen port
- `CLAMD_TIMEOUT`- ClamAV timeout connection in miliseconds

As stated before you can set all those parameters by setting environment variables:

_Linux/MacOSX_

```
export APP_PORT=8080
export NODE_ENV=production
export CLAMD_IP=localhost
export APP_FORM_KEY=FILES
npm start
```

or

```
APP_PORT=8080 NODE_ENV=production CLAMD_IP=clamavd CLAMD_IP=localhost APP_FORM_KEY=FILES npm start
```

#### API endpoints

There are only two API endpoints:

`POST /api/v1/scan` - to scan files (see [examples](#Examples))

`GET /api/v1/version` - to get ClamAV version

#### Examples

##### wget example

Oooops: _Wget does not currently support "multipart/form-data" for transmitting POST data_

##### curl example

```
❯ curl -s -XPOST http://localhost:3000/api/v1/scan -F<EMAIL_ADDRESS>-F<EMAIL_ADDRESS>| jq
{
  "success": true,
  "data": {
    "result": [
      {
        "name": "1Mfile01.rnd",
        "is_infected": false,
        "viruses": []
      },
      {
        "name": "eicar_com.zip",
        "is_infected": true,
        "viruses": [
          "Win.Test.EICAR_HDB-1"
        ]
      }
    ]
  }
}
```

##### httpie example

```
❯ http --form POST http://localhost:3000/api/v1/scan<EMAIL_ADDRESS><EMAIL_ADDRESS>HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Connection: keep-alive
Content-Length: 172
Content-Type: application/json; charset=utf-8
Date: Sun, 07 Jun 2020 10:11:34 GMT
ETag: W/"ac-dmIyPllIezz2lPUbemX0zYljm9w"
X-Powered-By: Express

{
    "data": {
        "result": [
            {
                "is_infected": false,
                "name": "1Mfile01.rnd",
                "viruses": []
            },
            {
                "is_infected": true,
                "name": "eicar_com.zip",
                "viruses": [
                    "Win.Test.EICAR_HDB-1"
                ]
            }
        ]
    },
    "success": true
}
```

##### Postman example

![Postman](./docs/images/Postman.png)

##### Client and server side examples

Simple examples how to call `clamav-rest-api` (from client/browser side) using form action and axios library can be found in [examples/html](./examples/html) directory.

Server side examples (Node.js) using axios, fetch and request library can be found in [examples/nodejs](./examples/nodejs) directory.

There is also simple Python [example](./examples/python) using `requests` library.

repository: themenucha/clamav-rest-api

repo_name: themenucha/clamav-rest-api


text:
+++
title = "Pre-requisites"
weight = 30
aliases = [
    "/40-reinvent2019/30-prerequisites.html",
]
+++

In order to complete this workshop you will need:

- A single AWS Account which you can log into
- A web browser to access the AWS console

{{% notice note%}}

If you are taking this workshop at re:Invent 2019 you should have been given a note when you entered the workshop.  This
note contains all you need to log into a AWS account we have created for you.
We have installed the tools needed for you to get going.

{{% /notice %}}

{{% notice note%}}

If you want to run through this workshop in your own account please check the next section titled *running-yourself*.

{{% /notice %}}

{{% children depth="1" showhidden="false" %}}

gha_language: CSS


text:
# localization plugin

[![fastlane Plugin Badge](https://rawcdn.githack.com/fastlane/fastlane/master/fastlane/assets/plugin-badge.svg)](https://rubygems.org/gems/fastlane-plugin-localization)

## Getting Started

This project is a [fastlane](https://github.com/fastlane/fastlane) plugin. To get started with `fastlane-plugin-localization`, add it to your project by running:

```bash
fastlane add_plugin localization
```

## About localization

Export/import app localizations with help of xcodebuild -exportLocalizations/-importLocalizations tool

Using it is Apple's recommended approach when dealing with localizations. Read more info [here](https://developer.apple.com/library/ios/documentation/MacOSX/Conceptual/BPInternational/LocalizingYourApp/LocalizingYourApp.html#//apple_ref/doc/uid/10000171i-CH5-SW13).

## Example

Check out the [example `Fastfile`](fastlane/Fastfile) to see how to use this plugin. Try it by cloning the repo, running `fastlane install_plugins` and `bundle exec fastlane test`.

*Trimming*

Remove some localizations before sending them to your translation service.

```
trim_localizations(
  path: "/path/to/en.xliff",
  text: [ ".", "Label", /^ *$/, /^[0-9]+$/ ],
  comment: [ /^do not translate/i ]
)
```

*Linting*

Mostly, this is about finding strings in Interface Builder that have no "Comment for Localizer."

```
lint_localizations(
  path: "/path/to/en.xliff",
  missing_comments: "warning"
)
```

## Run tests for this plugin

To run both the tests, and code style validation, run

````
rake
````

## Issues and Feedback

For any other issues and feedback about this plugin, please submit it to this repository.

## Troubleshooting

If you have trouble using plugins, check out the [Plugins Troubleshooting](https://github.com/fastlane/fastlane/blob/master/fastlane/docs/PluginsTroubleshooting.md) doc in the main `fastlane` repo.

## Using `fastlane` Plugins

For more information about how the `fastlane` plugin system works, check out the [Plugins documentation](https://github.com/fastlane/fastlane/blob/master/fastlane/docs/Plugins.md).

## About `fastlane`

`fastlane` is the easiest way to automate building and releasing your iOS and Android apps. To learn more, check out [fastlane.tools](https://fastlane.tools).

repository: timshadel/fastlane-plugin-localization

repo_name: timshadel/fastlane-plugin-localization


text:
# Silk.NET Community

The Silk.NET Community GitHub is a home for useful community-maintained extensions for the Silk.NET library recognised by the official Silk.NET maintenance team.

## Summary
We created this organisation to give extra recognition to projects the Silk.NET team deem useful and trustworthy, and to serve as a single location for community projects endorsed by the Silk.NET team.

Benefits for the user:
- A single location for add-ons to Silk.NET - no need to go hunting!
- Readily-available access to mature projects that can be trusted and are endorsed by the Silk.NET team

Benefits to the community project maintainers:
- More exposure to more users
- Greater user buy-in given the "Trusted by the Silk.NET Team" image

Benefits for the Silk.NET maintainers:
- No need to envelop these projects into the main library, as a result:
    - Less work to maintain the Silk.NET library
    - Less risk of scope creep

## Get your project involved!

Simply open an issue using the "Project Submission" template and the Silk.NET team will review your project as soon as possible!

### Points to Note

- You keep all maintenance responsibility
- You keep admin permissions on the GitHub Repository.
- You keep full copyright of the project, and do not need to grant anyone any additional rights (such as trademark or patent licenses), though the permissive license requirement
- You can withdraw from the Silk.NET Community at any time (contact us on Discord)
- You still have full control over library design, code, and maintenance decisions & policies, except where otherwise noted in the "Onboarding Requirements"
- You may request a channel in the Silk.NET Discord Server for development discussion

### Prerequisites

1. You use Silk.NET predominantly for any low-level interoperation with libraries that Silk.NET provide bindings for, and help promote the Silk.NET as the one bindings library you need for low-level graphics.
2. You are stable enough to be recommended to our community, and the project is in a good enough state that our userbase can start integrating your work into theirs.
    - Betas and pre-releases are okay, so long as the primary advertised functionality works (i.e. it "does what it says on the tin")
3. You solve a problem which the Silk.NET maintainers team recognises as a problem, and they believe that your project is useful when building libraries and applications that use Silk.NET.
4.  You use a permissive copyright license that is suitable for consuming the project as intended without adverse restriction
     - MIT or MIT-compatible licenses (e.g. Apache 2.0, BSD-3, etc) are recommended

### Onboarding Requirements

- You will need to adopt the Contributor Covenant Code of Conduct, and ensure your community doesn't break the rules. A copy of this is provided in the [CODE_OF_CONDUCT.md](CODE_OF_CONDUCT.md) file.
- You will need to use Discord and join the Silk.NET Discord Server so that we can maintain contact with you, ideally providing an alternative contact method (such as an email address) in case we can't.

### Ongoing Requirements

- You will need to maintain conformance with the "Prerequisites"
- You, as a project team, will need to conform with the Code of Conduct
- You will need to remain contactable via Discord in the first instance, and via the alternative method provided if all else fails.

Non-conformance, in the worst case, may result in us requesting that the project be transferred out of the organisation - if we are unable to establish contact with a maintainer to do this within 30 days after at least 3 attempts, the project will be archived. You, as the project maintainer, will be able to contact us at any time to get the project unarchived and transferred at any time.

For the purposes of the Silk.NET team's relationship with the community project, a "project maintainer" is anyone with admin rights on the GitHub repository - this is defined as such so that you can add and remove maintainers to the project as you please without contacting us but please ensure all maintainers are in the Discord server.

repository: SilkCommunity/SilkCommunity

repo_name: SilkCommunity/SilkCommunity