BitBucket API

Package goey provides a declarative, cross-platform GUI. The range of controls, their supported properties and events, should roughly match what is available in HTML. However, properties and events may be limited to support portability. Additionally, styling of the controls will be limited, with the look of controls matching the native platform. The minimal GUI example application is bitbucket.org/rj/goey/example/onebutton, and additional example applications are in the example folder. There are screenshots of some of the example applications linked in the README, located at https://bitbucket.org/rj/goey/src/default/README.md. To get properly themed controls, a manifest is required. Please look at the source for the example applications for an example. This file needs to be compiled with github.com/akavel/rsrc to create a .syso that will be recognize by the go build program. Additionally, you could use build flags (-ldflags="-H windowsgui") to change the type of application built. CGO is not required. Although this package does not use CGO, some of its dependencies do. The build machine also requires that GTK+ 3 is installed. This should be installed before issuing `go get` or you will have error messages during the building of some of the dependencies. On Ubuntu: Darwin (MacOS) A port to darwin using the Cocoa API is in the repository, but is only available under the macos branch. Development has been done on linux using GNUstep, so the build tags will need to be updated to build on a darwin system.

Package binaryio provides a wrapper to encoding/binary to provide a concise API. Numbers are translated by reading and writing fixed-size values. A fixed-size value is either a fixed-size arithmetic type (bool, int8, uint8, int16, ...) or an array only fixed-size values. This package is intended for decoding and encoding existing binary formats and is not written as a high performance serializer deserializer.

Package codeconnections provides the API client, operations, and parameter types for AWS CodeConnections. This Amazon Web Services CodeConnections API Reference provides descriptions and usage examples of the operations and data types for the Amazon Web Services CodeConnections API. You can use the connections API to work with connections and installations. Connections are configurations that you use to connect Amazon Web Services resources to external code repositories. Each connection is a resource that can be given to services such as CodePipeline to connect to a third-party repository such as Bitbucket. For example, you can add the connection in CodePipeline so that it triggers your pipeline when a code change is made to your third-party code repository. Each connection is named and associated with a unique ARN that is used to reference the connection. When you create a connection, the console initiates a third-party connection handshake. Installations are the apps that are used to conduct this handshake. For example, the installation for the Bitbucket provider type is the Bitbucket app. When you create a connection, you can choose an existing installation or create one. When you want to create a connection to an installed provider type such as GitHub Enterprise Server, you create a host for your connections. You can work with connections by calling: CreateConnection DeleteConnection GetConnection ListConnections You can work with hosts by calling: CreateHost DeleteHost GetHost ListHosts You can work with tags in Amazon Web Services CodeConnections by calling the following: ListTagsForResource TagResource UntagResource For information about how to use Amazon Web Services CodeConnections, see the Developer Tools User Guide.

Package tgbotapi has functions and types used for interacting with the Telegram Bot API.

Package zap provides fast, structured, leveled logging. For applications that log in the hot path, reflection-based serialization and string formatting are prohibitively expensive - they're CPU-intensive and make many small allocations. Put differently, using json.Marshal and fmt.Fprintf to log tons of interface{} makes your application slow. Zap takes a different approach. It includes a reflection-free, zero-allocation JSON encoder, and the base Logger strives to avoid serialization overhead and allocations wherever possible. By building the high-level SugaredLogger on that foundation, zap lets users choose when they need to count every allocation and when they'd prefer a more familiar, loosely typed API. In contexts where performance is nice, but not critical, use the SugaredLogger. It's 4-10x faster than other structured logging packages and supports both structured and printf-style logging. Like log15 and go-kit, the SugaredLogger's structured logging APIs are loosely typed and accept a variadic number of key-value pairs. (For more advanced use cases, they also accept strongly typed fields - see the SugaredLogger.With documentation for details.) By default, loggers are unbuffered. However, since zap's low-level APIs allow buffering, calling Sync before letting your process exit is a good habit. In the rare contexts where every microsecond and every allocation matter, use the Logger. It's even faster than the SugaredLogger and allocates far less, but it only supports strongly-typed, structured logging. Choosing between the Logger and SugaredLogger doesn't need to be an application-wide decision: converting between the two is simple and inexpensive. The simplest way to build a Logger is to use zap's opinionated presets: NewExample, NewProduction, and NewDevelopment. These presets build a logger with a single function call: Presets are fine for small projects, but larger projects and organizations naturally require a bit more customization. For most users, zap's Config struct strikes the right balance between flexibility and convenience. See the package-level BasicConfiguration example for sample code. More unusual configurations (splitting output between files, sending logs to a message queue, etc.) are possible, but require direct use of go.uber.org/zap/zapcore. See the package-level AdvancedConfiguration example for sample code. The zap package itself is a relatively thin wrapper around the interfaces in go.uber.org/zap/zapcore. Extending zap to support a new encoding (e.g., BSON), a new log sink (e.g., Kafka), or something more exotic (perhaps an exception aggregation service, like Sentry or Rollbar) typically requires implementing the zapcore.Encoder, zapcore.WriteSyncer, or zapcore.Core interfaces. See the zapcore documentation for details. Similarly, package authors can use the high-performance Encoder and Core implementations in the zapcore package to build their own loggers. An FAQ covering everything from installation errors to design decisions is available at https://github.com/uber-go/zap/blob/master/FAQ.md.

Package fasthttp provides fast HTTP server and client API. Fasthttp provides the following features: Optimized for speed. Easily handles more than 100K qps and more than 1M concurrent keep-alive connections on modern hardware. Optimized for low memory usage. Easy 'Connection: Upgrade' support via RequestCtx.Hijack. Server provides the following anti-DoS limits: The number of concurrent connections. The number of concurrent connections per client IP. The number of requests per connection. Request read timeout. Response write timeout. Maximum request header size. Maximum request body size. Maximum request execution time. Maximum keep-alive connection lifetime. Early filtering out non-GET requests. A lot of additional useful info is exposed to request handler: Server and client address. Per-request logger. Unique request id. Request start time. Connection start time. Request sequence number for the current connection. Client supports automatic retry on idempotent requests' failure. Fasthttp API is designed with the ability to extend existing client and server implementations or to write custom client and server implementations from scratch.

Package facebook is a Go library fully supports Facebook Graph API (both 1.0 and 2.x) with file upload, batch request, FQL and multi-FQL. It can be used in Google App Engine. Library design is highly influenced by facebook official PHP/JS SDK. If you have experience with PHP/JS SDK, you may feel quite familiar with it. Go to project home page to see samples. Link: https://github.com/huandu/facebook This library doesn't implement any deprecated old RESTful API. And it won't.

Package sfdc provides access to a small set of Salesforce APIs. This package is opinionated and intended for use in containers. It relies on reading environment variables for configuration. Function parameters are strongly typed to enable easier use with https://github.com/google/wire

Package gotwilio is a library for interacting with http://www.twilio.com/ API. Package gotwilio is a library for interacting with http://www.twilio.com/ API. Package gotwilio is a library for interacting with http://www.twilio.com/ API. Package gotwilio is a library for interacting with http://www.twilio.com/ API.

Package tinylib provides small functions for aws api gateway with lambda Package tinylib provides small functions for aws api gateway with lambda

Package docker provides a client for the Docker remote API. See https://goo.gl/o2v3rk for more details on the remote API.

The package postgresql-go provide a thin wrapper around the C library for accessing PostgreSQL databases. Nearly all of the functions in this package translate directly into calls to libpq. This package does not provide a driver for the package database/sql, although it could provide the basis for a pure Go driver. The goal is to provide the thinnest access to the standard API, while maintaining type safety. If the documentation in this package is unclear or incomplete, please refer to the full documentation for libpq, which is far more complete.

Package pay is a golang SDK for the Bronzecod payments REST API it provides type safe bindings for the APIs core features and entities as well as the various API endpoints available to get, enumerate and mutate them.

Package cos 腾讯云对象存储服务 COS(Cloud Object Storage) Go SDK。 封装了 V5 版本的 XML API 。 在项目的 examples 目录下有各个 API 的使用示例 。 默认所有 API 都是匿名访问. 如果想添加认证信息的话,可以通过自定义一个 http.Client 来添加认证信息. 比如, 使用内置的 AuthorizationTransport 来为请求增加 Authorization Header 签名信息:

Package binance is a Golang SDK for binance APIs.

Package twilio simplifies interaction with the Twilio API. The twilio-go library should be your first choice for interacting with the Twilio API; it offers forward compatibility, very fine-grained control of API access, best-in-class control over how long to wait for requests to complete, and great debuggability when things go wrong. Get started by creating a Client: All of the Twilio resources are available as properties on the Client. Let's walk through some of the example use cases. Resources that can create new methods take a url.Values as an argument, and pass all arguments to the Twilio API. This method ensures forward compatibility; any new arguments that get invented can be added in client-side code. Call Get() with a particular sid. Call Update() with a particular sid and a url.Values. There are two flavors of interaction. First, if all you want is a single Page of resources, optionally with filters: To control the page size, set "PageSize": "N" in the url.Values{} field. Twilio defaults to returning 50 results per page if this is not set. Alternatively you can get a PageIterator and call Next() to repeatedly retrieve pages. Twilio Monitor subresources are available on the Client under the Monitor field, e.g. There are several custom types and helper functions designed to make your job easier. Where possible, we try to parse values from the Twilio API into a datatype that makes more sense. For example, we try to parse timestamps into Time values, durations into time.Duration, integer values into uints, even if the API returns them as strings, e.g. "3". All phone numbers have type PhoneNumber. By default these are E.164, but can be printed in Friendly()/Local() variations as well. Any times returned from the Twilio API are of type TwilioTime, which has two properties - Valid (a bool), and Time (a time.Time). Check Valid before using the related Time. There are constants for every Status in the API, for example StatusQueued, which has the value "queued". You can call Friendly() on any Status to get an uppercase version of the status, e.g.

Package service provides a simple way to create a system service. Currently supports Windows, Linux/(systemd | Upstart | SysV), and OSX/Launchd. moved to github.com/kardianos/service Windows controls services by setting up callbacks that is non-trivial. This is very different then other systems. This package provides the same API despite the substantial differences. It also can be used to detect how a program is called, from an interactive terminal or from a service manager.

Package molly is the root for the library API in molly

Package gonduit provides a client for Phabricator's Conduit API.

Package log is an important part of the application and having a consistent logging mechanism and structure is mandatory. With several teams writing different components that talk to each other, being able to read each others logs could be the difference between finding bugs quickly or wasting hours. With the log package in the standard library, we have the ability to create custom loggers that can be configured to write to one or many devices. Since we use syslog to send logging output to a central log repository, our logger can be configured to just write to stdout. This not only simplifies things for us, but will keep each log trace in correct sequence. This package does not included logging levels. Everything needs to be logged to help trace the code and find bugs. There is no such thing as over logging. By the time you decide to change the logging level, it is always too late. The question of performance comes up quite a bit. If the only performance issue we see is coming from logging, we are doing very well. I have had these opinions for a long time, but if you want more clarity on the subject listen to this recent podcast: Jon Gifford On Logging And Logging Infrastructure: Robert Blumen talks to Jon Gifford of Loggly about logging and logging infrastructure. Topics include logging defined, purposes of logging, uses of logging in understanding the run-time behavior of programs, who produces logs, who consumes logs and for what reasons, software as the consumer of logs, log formats (structured versus free form), log meta-data, logging APIs, logging as coding, logging and frameworks, the massive hairball of log file management, modern logging infrastructure in which log records are stored and indexed in a search engine, how searchable logs have transformed the uses of log data, log data and analytics, leveraging the log database for statistical insights, performance and resource issues of logging, are logs really different than other data that systems record in databases, and how log visualization gives users insights into their system. The show wraps up with a discussion of open source logging platforms versus commercial SAAS providers. There are two types of tracing lines we need to log. One is a trace line that describes where the program is, what it is doing and any data associated with that trace. The second is formatted data such as a JSON document or binary dump of data. Each serve a different purpose but they both exists within the same scope of space and time. The format of each trace line needs to be consistent and helpful or else the logging will just be noise and ultimately useless. Here is a breakdown of each section and a sample value: Here are examples of how trace lines would show in the log: In the end, we want to see the flow of most functions starting and completing so we can follow the code in the logs. We want to quickly see and filter errors, which can be accomplished by using a capitalized version of the word ERROR. The context is an important value. The context allows us to extract trace lines for one context over others. Maybe in this case 8890 represents a user id. When there is a need to dump formatted data into the logs, there are three approaches. If the data can be represented as key/value pairs, you can write each pair on their own line with the DATA tag: When there is a single block of data to dump, then it can be written as a single multi-line trace: When special block formatting required, the Stringer interface can be implemented to format data in custom ways: The API for the log package is focused on initializing the logger and then provides function abstractions for the different tags we have defined.

Moving to https://github.com/kardianos/service The github repository uses a new API along with more features. If you are using the alpha config struct, you should consider moving. Package service provides a simple way to create a system service. Currently supports Windows, Linux/(systemd | Upstart | SysV), and OSX/Launchd.

Package sso is a golang SDK for the Bronzecod SSO platforms REST API it provides type safe bindings for the APIs core features and entities as well as the various API endpoints available to get, enumerate and mutate them.

Package codedeploy provides the client and types for making API requests to AWS CodeDeploy. AWS CodeDeploy is a deployment service that automates application deployments to Amazon EC2 instances or on-premises instances running in your own facility. You can deploy a nearly unlimited variety of application content, such as code, web and configuration files, executables, packages, scripts, multimedia files, and so on. AWS CodeDeploy can deploy application content stored in Amazon S3 buckets, GitHub repositories, or Bitbucket repositories. You do not need to make changes to your existing code before you can use AWS CodeDeploy. AWS CodeDeploy makes it easier for you to rapidly release new features, helps you avoid downtime during application deployment, and handles the complexity of updating your applications, without many of the risks associated with error-prone manual deployments. Use the information in this guide to help you work with the following AWS CodeDeploy components: Application: A name that uniquely identifies the application you want to deploy. AWS CodeDeploy uses this name, which functions as a container, to ensure the correct combination of revision, deployment configuration, and deployment group are referenced during a deployment. Deployment group: A set of individual instances. A deployment group contains individually tagged instances, Amazon EC2 instances in Auto Scaling groups, or both. Deployment configuration: A set of deployment rules and deployment success and failure conditions used by AWS CodeDeploy during a deployment. Deployment: The process, and the components involved in the process, of installing content on one or more instances. Application revisions: An archive file containing source content—source code, web pages, executable files, and deployment scripts—along with an application specification file (AppSpec file). Revisions are stored in Amazon S3 buckets or GitHub repositories. For Amazon S3, a revision is uniquely identified by its Amazon S3 object key and its ETag, version, or both. For GitHub, a revision is uniquely identified by its commit ID. This guide also contains information to help you get details about the instances in your deployments and to make on-premises instances available for AWS CodeDeploy deployments. AWS CodeDeploy Information Resources AWS CodeDeploy User Guide (http://docs.aws.amazon.com/codedeploy/latest/userguide) AWS CodeDeploy API Reference Guide (http://docs.aws.amazon.com/codedeploy/latest/APIReference/) AWS CLI Reference for AWS CodeDeploy (http://docs.aws.amazon.com/cli/latest/reference/deploy/index.html) AWS CodeDeploy Developer Forum (https://forums.aws.amazon.com/forum.jspa?forumID=179) See https://docs.aws.amazon.com/goto/WebAPI/codedeploy-2014-10-06 for more information on this service. See codedeploy package documentation for more information. https://docs.aws.amazon.com/sdk-for-go/api/service/codedeploy/ To AWS CodeDeploy with the SDK use the New function to create a new service client. With that client you can make API requests to the service. These clients are safe to use concurrently. See the SDK's documentation for more information on how to use the SDK. https://docs.aws.amazon.com/sdk-for-go/api/ See aws.Config documentation for more information on configuring SDK clients. https://docs.aws.amazon.com/sdk-for-go/api/aws/#Config See the AWS CodeDeploy client CodeDeploy for more information on creating client for this service. https://docs.aws.amazon.com/sdk-for-go/api/service/codedeploy/#New