The KISS Framework is an application development framework for developing web-based business applications, portable desktop applications, and command-line utilities. The main home for Kiss is https://github.com/blakemcbride/Kiss
Kiss’ focus is on simplicity and development speed. By being simple to develop in, development and support of the application can occur more rapidly. Simplicity is achieved by abstracting away as much common functionality as possible so that developer lines of code are maximally applicable to the application solution rather than infrastructure and support of the framework. Throughout the framework, business-normal defaults have been employed in order to minimize commonly needed functionality.
Another goal of the Kiss framework is to be a complete web-based application development solution. Kiss isn’t a browser solution alone, nor is it a back-end solution. Kiss includes solutions for both ends – although the two sides may largely be used independently.
Kiss attempts to create a consistent interface. This can greatly simply code even in simple cases. For example, in terms of an input text control, why would you disable/enable it with:
$('#id').prop('disable', false); $('#id').prop('disable', true);
and then hide/show it with:
$('#id').hide(); $('#id').show();
Kiss provides a consistent interface. With Kiss, you would do:
$$('id').disable(); $$('id').enable(); $$('id').hide(); $$('id').show();
Kiss is designed to be simple to get started with, simple to learn, and simple to use. Kiss does this while supporting important technologies such as micro-services, front-end components, and SQL.
The term single page application has several, subtly different, meanings. One meaning is that the entire application code is bundled into a single file or HTTP GET request. In that sense, Kiss is not a single page application. This makes no sense for a business application that could have hundreds of screens.
Another meaning of the term single page application is that there is
only a single html
tag and all of the remaining pages are
modifications of the original html
tag contents. In this
sense, Kiss is a single page application. Kiss
applications lazy-load as needed. Browser cache is leveraged to
minimize Internet traffic.
Kiss is used in a production environment and built by someone with more than 30 years experience as a framework designer and a business application software engineer. So Kiss is not a proof of concept.
Kiss was built as a solution to the challenges faced by the author when developing web-based business applications. As such, Kiss is more a solution for business application development than for the development of public facing company presentation web sites.
Another goal of Kiss is to keep the front-end and back-end as independent of each other as possible. To this end, communications between the front-end and back-end occur via REST services and JSON. This accomplished two things. First, it allows your organization to be best prepared for the ever-evolving software environment. Pieces can be changed and enhanced without causing massive re-writes of the entire system. The second advantage is that by pushing as much processing to the front-end as possible (rendering the display on the front-end), the system can better scale.
Some highlights of the Kiss system include:
The following example depicts a complete back-end web service. The path to the file is its URL. The class name is the web method name.
The file is a text file, but compiled code gets executed.
Authentication occurs before main
is called.
Simply drop the file in place and the web service and method become immediately available on a running system. Changes to the service take effect immediately (no need to reboot the server app). There are no configuration files or other code that needs to be changed.
For example, the following file is located in the
services
directory.
class MyWebService { void myWebMethod(JSONObject injson, JSONObject outjson) { int num1 = injson.getInt("num1"); int num2 = injson.getInt("num2"); outjson.put("result", num1 + num2); } }
The following front-end example utilizes the web service defined in the previous sub-section.
let data = { num1: 22, num2: 11 }; let res = await Server.call("services/MyWebService", "myWebMethod", data); if (res._Success) { let result = res.result; //... }
The following development platforms are supported by the Kiss framework:
The following production platforms are supported by the Kiss framework:
The following database servers are supported by the Kiss framework:
The system is tested with Java verion 8 and 17. Any Java version above 8 is expected to work.
To use a component add to HTML:
<my-component></my-component>
Add to JavaScript:
Utils.useComponent('MyComponent');
The component can put any HTML in the component location, have any functionality, have its own modal windows, and use other components. The component can have custom and non-custom attributes (like style). Non-custom attributes do what you’s expect them to do.
The system also supports tag-less components. This provides an easy way to package arbitrary blocks of code (that can have screens too).
The Kiss system has been used in production environments for a several years. Additionally, several commercial applications utilize Kiss. In spite of this, however, Kiss is constantly being adjusted in response to additional needs, evolving environments, and bug fixes.
We use Kiss daily in a Linux and PostgreSQL environment. Therefore, it is best tested there. While we support all of the listed environments, they receive a bit less testing. If you encounter a problem, please reach out to us. It is probably easy for us to fix, and we are happy to do so.
Source code for all of Kiss and its dependencies is freely
available. The builder program located at
src/main/core/org/kissweb/builder/Tasks.java
contains the paths
to all of the external dependencies (those not included in the
Kiss distribution). The following lists the paths to the
internal dependencies (those included with Kiss):
abcl.jar
json.jar
SimpleWebServer.jar (only used during development)
The Kiss main web site is at http://kissweb.org
Source code is at https://github.com/blakemcbride/Kiss
Public discussion and support is available at
https://groups.google.com/forum/#!forum/kissweb
Issue tracking is at https://github.com/blakemcbride/Kiss/issues
Commercial support is available. Contact us via email at<EMAIL_ADDRESS>Copyright (c) 2018 Blake McBride<EMAIL_ADDRESS>Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the “Software”), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
1. Redistributions of source code must retain the above copyright notice, this list of conditions, and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.

The Kiss design, code, documentation, and web site were written by Blake McBride. The author gratefully acknowledges and appreciates, among others, the following:
Apache Groovy located at http://groovy-lang.org
Dynamic Loader located at https://github.com/dvare/dynamic-loader
JSON-Java located at https://github.com/stleary/JSON-java (although I am using a modified version available at https://github.com/blakemcbride/JSON-java)
C3P0 located at https://www.mchange.com/projects/c3p0
Texinfo located at https://www.gnu.org/software/texinfo/
ABCL project located at https://common-lisp.net/project/armedbear
Melaine Sarbey<EMAIL_ADDRESS>for creating the Kiss logo.
The Kiss system comes with its own build system, so it doesn’t use build systems such as ant, maven, or gradle. It works under Linux, Mac, Windows, etc. This included build system will make things such as downloading remote libraries, installing and configuring a web server, building Kiss, and running Kiss for development purposes easy, intelligent, and automatic. This new build system can be used in conjunction with your favorite IDE.
The build system (called it bld) is small and written in Java. Its source code is included with the Kiss source code. So, a Java compiler will be needed before anything will work. Java 8, 11, and 17 are supported.
When building the system for the first time, BLD will automatically download and cache required libraries (jar files), install and configure the development server (tomcat), build the system, and it can even be used to launch the development-mode server. After building the system the first time, application development proceeds without any need for re-compiles or re-builds.
The program that runs BLD is “bld” under Unix-like systems and “bld.cmd” under Windows. In this manual, “bld” will be shown as “./bld”. The “./” is required under Linux and Mac but not under Windows. When running on Windows, use “bld” rather than “./bld” and the same for all the other commands shown.
Note. The Kiss system includes a file named pom.xml
.
However, Kiss is not a maven project. The
pom.xml
file is only included to provide GitHub with a
list of dependencies. Unfortunately, this file sometimes confuses IDEs
into interpreting the existence of that file as the project being a
maven project. Therefore, in some instances, it is a good idea
to delete that file prior to IDE configuration.
The build.xml
file is also not used by the Kiss system per se.
It is an integration with ant for IDE integration.
This is the simplest and shortest path to a running system. It assumes:
After doing a git clone
, all that is needed is the following:
./bld develop [Linux, Mac, BSD, etc.] -or- bld develop [Windows]
This will build the system, install tomcat, deploy the app, and run the server. At this point you will be able to go your browser at the following URL:
http://localhost:8000
Be sure not to use port 8080. Although port 8080 will appear to work, you will not be able to do front-end development while the system is running. Port 8000 will allow front-end development while the system is running.
At this point, you can do all development without any build procedures. You can add or change anything on the front-end or back-end while the system is running.
All application back-end code is located under the src/main/backend
directory.
All application front-end code is located under the src/main/frontend
directory.
If you change anything in either place, the system will notice the change and deliver it with the next request.
This is a more detailed and expanded description of the same super-quick-start.
The following enumerates the steps necessary to get the system up and running:
./bld develop
http://localhost:8000
You can also debug the back-end by
attaching to the process at port 9000.
Alternatively, your IDE can be configured to run the development process entirely through it.
Once the development server is running under bld, you can stop it by hitting any key.
As shipped, there are two different environments that Kiss may run in as follows:
The Production scenario is created with a single command
(./bld war
) and produces a single war
file (located in
the build.work
directory) that can be deployed to your production
environment.
Before doing anything with the Development environment, it is important that you have the JAVA_HOME environment variable set correctly to the root of your JDK (Java Developer Kit). Doing this varies according to the OS you are using and various other Java installation possibilities. There are plenty of instructions on the Internet for this.
The Development environment consists of two servers. One serves the back-end REST services, and the second serves the front-end HTML, CSS, and JavaScript files. By using this method, both front-end and back-end source files can be changed on a running system and take effect immediately without any builds, compiles, server reboots, re-deploys, or file copies. (This is also true of a production environment – with a single server – when the new files are put in place.)
Back-end REST services are debugged, and edited through the IDE. Saving a source file is all that is needed to have it take effect.
The front-end (HTML, CSS, and JavaScript files) are served by a simple server supplied with the Kiss system. This server is only used during the development process. See Front-end Development. (Source code to this server is available at https://github.com/blakemcbride/SimpleWebServer) Debugging the front-end is done through the browser debugger. There is no setup, and the front-end server runs by executing a single command.
You should download and install the following pre-requisites.
Correctly setting the JAVA_HOME environment variable to the root of your JDK is necessary. Setting this varies from OS to OS and also depends on where it gets installed. Instructions for setting this variable are all over the Internet.
The system was built and tested with JDK 8, 11 and 17, PostgreSQL, IntelliJ, and tomcat. Other environments such as IIS, Glassfish, eclipse, should work fine but may require some configuration.
Kiss comes with its own build system. See Important
Install the above according to their instructions.
The Kiss reporting facilities are dependent on the full groff system and the ability to convert Postscript files to PDF files. This is generally true on Linux, however, the full groff package may need to be installed. Mac’s are fine. These packages are not on Windows and must be installed.
Correctly installing groff and ghostscript will allow the reporting facilities to work under Windows. They may be obtained from:
https://sourceforge.net/projects/ezwinports
Kiss is located at https://github.com/blakemcbride/Kiss
It can be downloaded via the following command:
git clone https://github.com/blakemcbride/Kiss.git
The Kiss documentation consists of three parts; this manual, the detailed back-end API documentation contained in the JavaDocs, and the detailed front-end API documentation. The JavaDocs do not come with the system, but you can generate them yourself with what is provided. See Creating JavaDocs.
This manual may be created in two forms. The first is in an HTML form. The system comes with this. You can also generate a nicely formatted PDF file with the following commands (if you have all of the formatting tools installed):
cd manual make Kiss.pdf
Updates to the HTML file are achieved with the following commands:
cd manual make
All of the documentation can be accessed with your browser. For
example, if the root of Kiss is located at
/my/home/path/kiss
then you will be able to access the three
manuals at the following URL’s:
file:///my/home/path/kiss/manual/man/index.html file:///my/home/path/kiss/build.work/javadoc/index.html file:///my/home/path/kiss/manual/jsdoc/index.html
The system is configured by the contents of a single file
src/main/backend/KissInit.groovy
A reboot of the web server
is required if any of the parameters in this file are changed.
Given that Kiss is for business applications, it authenticates its users. In order for this to work, there is usually a database of valid users. This information is persisted in an SQL database. Therefore a database is normally required. However, for testing purposes, if no database is configured, the system will still run and allow any username and password to succeed.
As shipped, the system comes configured as follows:
| Database type | SQLite |
| Host | localhost |
| Database | DB.sqlite |
| Database user | [empty] |
| Database user password | [empty] |
Valid options for the Database type are as follows:
Support for other databases is easy to add.
setMaxWorkerThreads defines how many REST services may be processed in parallel. Service requests beyond this are placed in a FIFO queue and processed as worker threads become available. This capability drastically improves the system’s ability to handle a large number of simultaneous users.
The remaining parameters should be self-explanatory. Use the format shown in the example.
Although Kiss comes with a default demo database, another one
should be configured in live or more substantial development
environments. An SQL script file, named init.sql
, is included
with the system to initialize said database. Application specific tables
may be added to this database.
The default username is kiss, and the default password is password
On rare occasions, it is necessary to bypass authentication. In other words, be able to execute a web service without being logged in. One example of this is registering a new user. If the user isn’t already a valid user, they can’t execute services in order to register.
Kiss has a way of dealing with this scenario. This is done in
the same configuration file where all of the configuration options are
located. In the file src/main/backend/KissInit.groovy
. In
that file, you are able to specify specific web methods that may be
called without authentication. That file has an example.
It should be noted that it is recommended that something like a captcha be used to at least be confident you are communicating with a human. Additionally, it should be noted that the danger of providing unauthenticated services is somewhat mitigated by the combination of HTTPS and CORS.
Although the system may be built with the included build system (called bld) or your favorite IDE, the bld system should be used for the initial step which downloads the external dependencies (jar files).
The build system included with Kiss (called bld) has been tested on Linux, Mac, and Windows. The system also includes an Ant build file (named build.xml) that is only used for IDE integration with the included bld system.
The build system included with Kiss is written in Java and located under the src/main/core/org/kissweb/builder/ directory. This build system also includes two driver batch files / shell scripts used to build and run the build system. All that is needed to use this system is a Java compiler. (As a side note - this build system is generic and can be used to build other types of projects.)
The build process is run from the command-line. No IDE is necessary. There is no specific IDE integration. None is needed because the system is rarely built. After the first build, application development is done without any build process.
The build system, which comes in source form, must be built before it can be used to build Kiss. However, the build system gets built automatically by bld.
You can see what operations it can perform by typing:
./bld listTasks [Linux, Mac, BSD, etc.] -or- bld listTasks [Windows]
Those tasks that require prior tasks will evoke the dependent tasks automatically. The system is smart enough not to repeat tasks that are unneeded.
The main tasks that will be of interest to you are as follows:
libs
This task is only required if you intend to use your IDE to build the remainder of the system. It installs the required dependencies.
develop
This will cause the entire system to build (not repeating unnecessary
steps) and start up a tomcat instance to run the system in a
development mode. The system will be available from your local
browser at http://localhost:8000
. You may debug the
application by attaching to the running tomcat server at port
9000.
war
This will cause the system to generate the single file needed by a production system. It will end up in build.work/Kiss.war
Other tasks which may be useful are as follows:
clean
This task removes all files built but retains files that were downloaded from repositories (although bld caches those files anyway.)
realclean
This removes all built and downloaded files so the system should be everything you need to build it without any extraneous files
all
This performs all of the steps necessary to setup and build the system but doesn’t start up the tomcat server.
javadoc
This task creates the javadoc files that end up in build.work/javadoc
kisscmd
This task creates a command-line JAR that can be used in a non-web, command-line application.
This is useful when creating applications that perform various utility functions. This
JAR cannot be used in any web environment. See src/main/core/org/kissweb/Main.java
See Important and See Quick-Start Checklist.
Most IDE’s can be used to develop and debug the application. There are two way to do this as follows:
Using bld to build and run the development environment is the easiest to start off with but is somewhat klunky on an ongoing basis. Its main advantage is that it is portable and doesn’t require a lot of IDE configuration. The back-end development server is configured and started by bld by simply running ./bld develop After that, the IDE can be used to debug it by attaching to port 9000.
Kiss also comes with an ant build that simply calls the native bld program. This is useful as an intermediary between bld and the IDE since many IDE’s support ant.
Using your IDE to run the entire process is a bit tedious to initially
setup but makes the entire process simpler from that point forward.
Unfortunately, configuring your IDE is completely different for each
IDE. Instructions for setting up some of the IDEs is located under the
manual/IDE-Setup
directory.
The Kiss framework is continually enhanced. Kiss includes a mechanism to upgrade your application. However, this automated upgrade process currently only works on Unix-like operating systems such as macOS and Linux. On Windows, a manual process will need to be employed.
The process of upgrading your application is as follows:
git pull
./upgrade-application <path-to-your-application>
Caveat
While this upgrade process upgrades the majority of the system, there are a few files that are not auto-updated to be sure not to clobber possible application-specific code that may have been added. Therefore, the following files will need to be manually verified.
src/main/core/org/kissweb/builder/Tasks.java
This file is left untouched by the upgrade process. You may have
custom tasks or modified existing tasks. Be sure to check
buildForeignDependencies()
.
libs
The upgrade process installs new or updated JAR files that are part of the Kiss system. However, you may have added application-specific JAR files. After the upgrade, be sure to manually delete any outdated JAR files that come with Kiss that have been upgraded by this process.
What you have at this point is the beginnings of your new application. Kiss is provided as a running and deployable system. It is expected that you would modify what’s there to suit your application needs.
Besides this narrative, you would need the JavaDocs located under the
build.work/javadoc
directory for back-end API specific documentation and
front-end API reference located in the manual/jsdoc directory.
The entire source code comes with the system and is convenient when debugging, however, only a few areas in the system would normally be of concern when building an application as follows.
src/main/backend/KissInit.groovy
This file is used to configure the system. See Setup And Configuration
src/main/backend
All other files under this directory represent the application back-end. All the files are used and distributed in source form. The Kiss system compiles them at runtime but does not save the compiled form. Updates to files under this directory take affect immediately on a running system.
Files under the src/main/frontend
directory represent the
front-end of the application.
All files under the src/main/frontend/kiss
directory are part of
the Kiss system and would normally not need to be touched.
index.html
and index.js
are also part of the Kiss
system and aren’t normally modified.
login.html
and login.js
represent the user login page
and would be modified to suit your needs.
Other directories such as page1
represent other user pages and
would be the application specific screens you create. The included
page1
directory is only an example page.
Kiss supports Microsoft SQL Server, Oracle, PostgreSQL, MySQL, and SQLite.
As shipped, Kiss comes configured with an embedded SQLite
server and database. While this is fine for a demo or small
application, a real database should be configured for real use.
The included database is located in the backend
directory
and is named DB.sqlite
Although Kiss has no preferred database, PostgreSQL is strongly recommended because it is free, full featured, fast, rock solid, and portable on all major platforms.
Kiss applications are single page applications in the sense
that there is a single <body>
tag and all other pages
essentially get placed into that tag on a single page. However,
Kiss is not a single page application in the sense that the
entire application gets loaded with a single GET
request. This
doesn’t make sense for a large business application in which many
hundreds of pages may exist. Kiss lazy-loads pages as they are
used, and except for browser cache, eliminates them once another page
is loaded.
The user’s browser cache can be controlled from the file
src/main/frontend/index.html
In that file you will see two lines
that look as follows:
var softwareVersion = "1"; // version of the entire system var controlCache = false; // normally true but use false during // debugging
If controlCache
is set to true
, each time softwareVersion
is incremented all users starting the application will be forced to
load new code from the server and not use their browser’s cache. Once
they download the new version, normal browser cache activity will
occur.
JavaDocs for the Kiss system will need to be created. It is created from the command line by issuing the following command:
./bld javadoc [Linux, Mac, BSD, etc.] -or- bld javadoc [Windows]
The JavaDoc files end up in the build.work/javadoc
directory.
The only file needed to deploy the application is Kiss.war
It
can be built by typing ./bld war
at a command prompt.
Kiss.war
ends up in the build.work
directory. If you
have your IDE create the Kiss.war
file, it will likely not
work. The Kiss system requires a special build process because
application files are distributed in source form. Therefore, bld
should be used to create the production WAR file.
If using tomcat, Kiss.war
should be placed in the
webapps
directory. When tomcat starts, it will see the
file, unpack it, and run it. The application will be available at
[HOST]/Kiss
Renaming Kiss.war
to ABC.war
, for example, will cause
the application path to change to [HOST]/ABC
In order to start getting a feel for how Kiss
applications
function, in terms of the back-end, look at files in the
src/main/backend/services
directory. With Kiss
you can
develop applications in several different languages. The services
example shows the same code in all of the supported languages.
In terms of the front-end, see the example files under src/main/frontend/page1
This section details the development process with Kiss. The details provided will be for IntelliJ but can be adapted to other IDE’s. The use of an IDE is tremendously beneficial because of the graphical debugging and intelligent code completion capabilities.
A good development environment includes two separate servers running on two different ports. One serves the back-end REST services, and the other serves the front-end HTML, JavaScript, and CSS files. This arrangement allows both front-end and back-end development without any compiles, server reboots, file copies, or deployments. Back-end and front-end files can be edited and saved. Their changes take effect immediately.
Of course, in a production environment, only a single server would be utilized and front-end and back-end changes take effect immediately there too.
The following details the normal steps to boot up a development environment. Once this environment is set up, it may remain active for the whole day. There is rarely any reason to re-build or re-boot the development environment.
Note that all of the command-prompt commands are executed from the root of your application.
./view-log
This is where back-end messages appear. (Note that this command is not needed under Windows.)
./bld develop
This builds the system and runs the back-end and front-end servers.
This will allow you to debug the back-end.
This is where you view and interact with your application.
This is where you debug the front-end.
At this point, development, testing, and debugging can occur unabated. There should be no need to rebuild or bring anything down.
Front-end changes will appear as soon as you re-load the page on your browser. Back-end changes with take effect immediately.
While development with Kiss does not require an IDE, most developers utilize an IDE (Integrated Development Environment). Kiss includes an effort to assist with IDE integration (such as an ant interface to our build system).
See the files under the manual/IDE-Setup
director for further
information.
The back-end works differently in development and production environments. Although in both environments back-end and front-end changes take effect immediately, setup of the production environment copies all files into the production environment, whereas in a development environment the source and production code are split. In order to facilitate rapid and easy development, it is important that source files be used rather than the production copies during the development process.
The system automatically detects the location of the application
source in most configurations. However, this may be explicitly
set via a system environment variable (KISS_ROOT
). The
value of this environment variable should be the absolute path of the
root of the application source code. The directory it indicates
should have a sub-directory named src/main/backend
.
There are two different methods of running the back-end REST server as follows.
Running of the IDE back-end requires the following:
Typically, the IDE manages a tomcat instance and serves up the core back-end code serving the REST services. That code detects that it is running under an IDE and re-routes all back-end application files back to the source directories.
Although back-end files are edited in source form and run in compiled form, back-end code can be debugged (including break-points) as if they were compiled before the system was booted.
Once the back-end server is up, application files changed under the
src/main/backend
directory will take effect immediately.
Utilizing the included Kiss build system (bld) the many steps required to install and configure tomcat and the IDE are unnecessary. The whole process (for the back-end portion) can be done as follows:
./bld develop
Note: Remember that all commands that start with ./
would drop
the ./
under Windows.
At this point, the back-end will be running. From within your IDE you can attach to the process at port 9000 to debug the back-end (including breakpoints, etc.)
Remember, however, that you won’t be able to use or debug the application until the front-end server is started too.
All communications between the front-end and back-end occur over REST services you define. Each REST service exists in its own file or class. Web methods are methods within those classes.
As architected, directories under src/main/backend
represent the application’s REST services. Each class / file under that
directory represents a web service. The name of the class is the name
of the web service.
Instance methods within the web service class represent REST methods for that web service. Each web method is passed four arguments as follows:
JSONObject injson
This represents the data that came from the front-end.
JSONObject outjson
This represents the data being returned to the front-end. It is pre-initialized with an empty JSONObject
.
Connection db
This is a pre-opened connection to the defined database (defined in backend/KissInit.groovy
)
MainServlet servlet
This is a rarely used servlet context argument.
Basically what happens is:
Kiss
back-end receives the request.
outjson
object that is filled in by the web service that is to be returned to the front-end.
outjson
to the front-end.
Additional class and instance methods, that are not web methods, may be defined and used within web service classes.
Of course during this process, Kiss
handles many possible error conditions.
During the login process, user-specific data may be cached. This
often occurs in the login
Groovy method of the Login
application-specific class.
Every web service has access to this data via the following method:
servlet.getUserData().getUserData("dataName") servlet.getUserData().putUserData("dataName", "datValue")
See Authentication
At this point, Kiss supports the development of back-end REST services in the Java, Groovy, or Common Lisp languages. Groovy was added first because it was easy, worked with the IDE well, and did all that was needed. (See the document GroovyOverview included with KISS.) Java was added simply due to its natural integration with the rest of the system.
With Kiss, different web services can be written in different languages. You are not forced to use one or the other.
Common Lisp (ABCL) was added due to this author’s love of that
language. Unlike Groovy and Java, Lisp has an impedance mismatch with
the core Kiss system that is written in Java. For example, in
Java, one can have two methods with the same name in the same class
that differ only by their argument types. This is not part of the
Common Lisp language. Also, the foreign function interface in Lisp
requires some Lisp code to make the connection clear. Due to this
connection code having to run, the Lisp interface is very slow on the
first call. It is, however, reasonably fast on all subsequent calls.
The code that interfaces Java to Lisp is under the
src/main/core/org/kissweb/lisp
directory.
Do to the easy and natural connection between Java and many other JVM languages, interfaces to those languages is very easy. It is anticipated that support for many of these other languages (such as Scala, Clojure, JRuby, Jython, and Kotlin) will likely follow, especially if there are requests.
Kiss has the ability to run any number of commands at specified
intervals. For example, you could run a process every hour and
another process every Tuesday at 3 PM, etc. This facility echos
the standard Unix or Linux cron
facility.
The file that determines what gets run and when is
src/main/backend/CronTasks/crontab
. All tasks must be in
the Groovy
language and exist in the
src/main/backend/CronTasks
directory.
All contents of the src/main/backend/CronTasks
can be changed
on a running system. The change will get noticed and take effect.
There is no need to restart the system.
Look at the files in the src/main/backend/CronTasks
directory for samples and further documentation.
For security reasons, web servers prevent web services from an application that didn’t come from the same application. This is known as Cross-Origin Resource Sharing or CORS. Kiss fully supports this security standard.
Kiss automatically enables full CORS protection on production environments and allows CORS in the development environment.
A separate server is used so that development files will be served rather than the front-end that was present when the back-end server was started. This is the same whether your are using the IDE or bld back-end server modes.
Once the back-end and front-end servers are running, the front-end can be debugged through your browser debugger (F12 on Chrome).
In order to make this work, there are two steps that need to be followed.
src/main/frontend/index.js
. That file
contains a line that looks as follows:
Server.setURL('http://localhost:8080');
As shipped, that setting should be good in most cases. Adjust as needed.
SimpleWebServer.jar
on the
root of the Kiss system. From the root of the Kiss
system, run the following command to run the front-end server:
./serve
or on Windows:
serve.cmd
(Source code to this simple server is available at https://github.com/blakemcbride/SimpleWebServer)
Once the front-end and back-end servers are up, you can access the development
environment through your browser at http://localhost:8000
If you disable the browser cache through the browser developer console
settings, changes you make to the front-end will appear by just
reloading the page. On Chrome, for example, the browser cache can be
turned off by going into the page debugger (F12), then
settings
, and then select Disable cache (while DevTools
is open)
You can now develop the front-end portion of your application by
editing files under the src/main/frontend
directory.
It is often necessary to support mobile devices. Although many applications support mobile applications through pages that use responsive design, it is often the case that the pages are so different between various platforms that the use of whole new pages is simpler and more effective – especially for complex screens.
Although Kiss has always supported responsive design,
Kiss also supports the ability to have different pages for
different platforms. If you look at src/main/frontend/index.js
you will see how Kiss
handles this. Basically Kiss
detects the platform and loads different pages based on the platform.
Creating reports and exports requires both front-end and back-end components. The back-end usually creates the file to be sent to the front-end. It then returns a path that the front-end can use to download the file.
Kiss provides the infrastructure needed to support this facility. Kiss also manages and cleans up report files that are no longer needed.
In terms of producing reports, Kiss leverages the facilities provided by the common groff/tbl/mm utilities publicly available. These facilities automatically handle paging, titles, page numbering, tables, and overall formatting of your reports. See https://www.gnu.org/software/groff
In terms of producing CSV export files, see the back-end
DelimitedFileWriter
class.
When files are produced by the back-end, they are sent to the
front-end by just providing the URL to the file. At that point, the
front-end Utils.showReport
takes the URL returned by the back-end
and downloads the file.
Kiss has built-in authentication. However, each application has its own method of storing and validating users. Additionally, each application may have its own user-specific data it may want to retain between web service calls. Kiss has a generic and easy way of handling these needs.
Application-specific user login and data is handled by the Groovy file
located in the backend
directory named Login.groovy
.
That file must have two methods; login
and checkLogin
.
See that file for more details.
See Cached User Data
The front-end API are all the facilities that run on the browser.
This includes HTML, CSS, JavaScript, image files, etc. The Kiss
back-end does not produce or modify HTML or JavaScript code. These
files are served, unaltered, by the server as they are on the back-end
disk. The Kiss
model is that the browser receives these files
from the server, and that they include all the code that the browser
needs to perform its function. Besides these static files, all data
is communicated between the back-end and front-end via REST services.
Having all of the display logic running on the front-end or user’s browser makes a lot of sense for the following reasons:
All of this leads to the following:
The front-end API is documented in the file manual/jsdoc/index.html
.
On the front-end, the class Server
is what deals with the REST
communications between the front-end and back-end. In it, there are a
handful of methods that deal with the environment such as the back-end
URL. All communications between the back-end and front-end are done
with JSON.
The way it works is the login service requires a username and password, and it returns a login token (uuid). That token is used in all future calls, and it gets automatically invalidated after a certain amount of non-use time. There is no state kept on the back-end. Each REST call must login to the back-end with the provided token in order to be authenticated to communicate.
The method used to communicate is named Server.call()
. It is passed the
path to the REST service, the REST service method name, and a JSON
object that is send to the back-end method. A Promise
is
returned that is used to obtain the result of the call. This
can also be used with async/await
.
There is also a logout
method that simply erases the
login token so that future communications cannot occur.
The Server
class also includes a method (fileUploadSend
)
that makes it easy to upload files.
Although HTML provides what is needed for real applications, it provides those facilities in too low a level to be useful without a lot of custom code. Custom components (tags) allow you to encapsulate that advanced behavior into what is used as and appears as native functionality.
Kiss provides the ability to create your own custom HTML tags
or elements as well as use those provided by Kiss. There are
two principal user methods that make this work.
Utils.useComponent
is used to load either a Kiss defined
component or one you define yourself (there is no difference). This
loads the JavaScript file that defines the new tag. All of the
components that come with the Kiss system are under the
src/main/frontend/kiss/component
directory. You can see those
files for examples of how custom tags are defined.
New application pages are loaded with the Utils.loadPage
method. In addition to loading the HTML and JavaScript code
associated with that page, this method performs the processing
necessary to make the components work. It does this intelligently so
that, for example, one component can use another component without any
special loading order requirement.
Briefly, the code that describes the custom tag must describe what the tag is replaced with. Ultimately, it must boil down to straight HTML, CSS, and JavaScript code.
Let’s say you have a pop-up window that allows a user to search for employees, or product, or whatever. The user gets a variety of search capabilities and the selected item is returned. Let’s further say that you need this functionality in several places within your application. These are tagless components. They aren’t placed with a custom tag. They are a response to an event like a button push. Tagless components allow you to encapsulate a block of functionality (including pop-up windows) into a neat package that can be re-used in any number of places.
The method used to load tagless components is
Utils.useTaglessComponent
. Later, when the tagless component
is needed, one would execute Kiss.MyComponent.run(in_data, on_exit)
(where
MyComponent
is the name of your tagless component.
in_data
represents possible data passed to the component on entry.
on_exit
is a function that gets executed when the component exits.
Arguments passed to on_exit
are determined by the component.
Kiss supports draggable, modal popup windows. HTML is used to describe the layout of the popup, and JavaScript is used to control the appearance of the popup.
The HTML portion is represented as a top-level popup
tag
that represents the entire popup. Withing the top-level popup
there most be two child tags named popup-title
and
popup-body
. The first represents the single line header, and
the second represents the body of the popup window.
The top-level popup
tag’s attribute section must contain the following:
id="my-popup"
an ID is needed to reference the popup
width="600px" height="300px"
Set the height and width of the popup
An examples is as follows:
<popup id="my-popup" width="600px" height="300px"> <popup-title>The title</popup-title> <popup-body> The content <div style="display: inline-block; position: absolute; bottom: 20px; right: 20px;"> <push-button id="cancel" style="margin-left: 15px;">Cancel</push-button> <push-button id="ok" style="margin-left: 15px;">Ok</push-button> </div> </popup-body> </popup>
There are only two JavaScript functions used to control the popup.
Utils.popup_open(id [, focus-id])
open the popup indicated by the id
, and if focus-id
is present, set initial focus to that control
Utils.popup_close()
close the most recent popup
Your defined responses to the buttons on the popup determines your dealing with the data on the popup and when to close it.
Kiss includes facilities that make it easy to upload a file or multiple files. The way to use it is as follows:
The HTML would contain two controls; a file input and a button. The file input looks as follows:
<file-upload id="myUpload">Upload File</file-upload>
The file input control allows the user to select the file or files to
be uploaded. If multiple files are to be allowed the multiple
attribute should be added to the HTML.
The button is used to activate the upload process. Your code that sends the file(s) to the server should be attached to this button.
The file-upload
control contains the helper functions
numberOfUploadedFiles
and getFormData
, and the main
function used to send the files is fileUploadSend
in the
Server
class. The code would look like the following:
$$('upload').onclick(async () => { if ($$('the-file').numberOfUploadFiles() < 1) { Utils.showMessage('Error', 'You must first select a file to upload.'); return; } const fd = $$('the-file').getFormData(); let data = { var1: 22, // just some random data we want to sent to the back-end var2: 33 } const r = await Server.fileUploadSend('theService, 'theMethod', fd, data); });
Back-end code would look like this:
public void theMethod(JSONObject inJson, JSONObject outJson, MainServlet servlet) throws Exception { String var1 = inJson.getString("var1"); String var2 = inJson.getString("var2"); if (servlet.getUploadFileCount() == 0) throw new Exception("No file specified."); String originalFileName = servlet.getUploadFileName(0); BufferedInputStream bis = servlet.getUploadBufferedInputStream(0); // do something with the file stream bis.close(); -or- String localFileName = servlet.saveUploadFile(0); }
Kiss includes an ever-growing set of utilities to help deal with common tasks.
These utilities are located under the src/main/frontend/kiss
directory and have names such as
DateTimeUtils.js
, DateUtils
, TimeUtils
, Utils
, etc. These utilities
are documented in the front-end API documentation.
Browser’s have a mind of their own in term of deciding when to use their cache for a file and when to download a new one. This can cause no end of trouble when code gets changed. Some user files end up being old from the browser cache, and others are freshly downloaded. The old and new files don’t agree with each other and all sorts of errors occur.
Kiss includes a facility to assure that all files are
downloaded afresh whenever the application changes while still taking
maximal advantage of the browser cache when the files have not
changed. The only cost for this capability is the requirement
that the index.html
file always gets loaded afresh.
To that end, Kiss has code to ignore browser cache and always load
index.html
afresh.
index.html
contains two variables names softwareVersion
and controlCache
.
Assuming controlCache
is true
, Kiss has code that forces the browser
to re-load all files whenever softwareVersion
changes. After the code is re-loaded,
the browser cache will work as normal to maximally cache the files until the next
softwareVersion
change.
Although not a part of the Kiss system, there are some very valuable technologies and libraries that have been used with Kiss in order to create some very powerful solutions.
The first is the Lovefield library that adds SQL capabilities on the browser side. Data is persisted on the user’s browser and remains through browser or machine re-boots. The library is located at https://github.com/google/lovefield
A recent technology that has been used to enable browser application
that run when there is no Internet connection is called Service
Workers. There is a package at
https://developers.google.com/web/tools/workbox that makes
working with service workers very easy.
In addition to the full API provided by the Java system, and any additional JAR files you add, Kiss comes with an API that assists with the development of business application with Kiss. These API’s may be broadly grouped as follows:
An overview of these API’s is contained in this chapter. Detailed documentation is contained in the JavaDocs. See Creating JavaDocs.
Kiss comes with a powerful library for accessing SQL databases.
Code for this is located under org.kissweb.database
It is
currently being used in production environments. This API provides
the following benefits:
As shipped, this library supports PostgreSQL, Microsoft Server, Oracle, MySQL, and SQLite.
The detailed documentation for the database utilities are in the JavaDocs which you must generate. (See Creating JavaDocs.) This section provides an overview.
The Kiss database routines revolve around four main classes as follows:
Connection
This represents a connection to an SQL database.
Command
This represents a single action or command against the database.
Cursor
If the action is a select
, the Cursor
represents a
pointer into the result set.
Record
This class represents a single row within a table or result set.
The Connection
class contains several convenience methods that
are used in simple cases where only a single action is being
performed. These methods should not be used when multiple
simultaneous actions are taking place at once (by that single thread).
This issue is not a problem in multi-user or multi-threaded
situations. It is only a problem when a single thread is doing one
action while another action is still open.
You will notice that your REST services are passed a Connection argument. Kiss automatically forms a unique connection for each REST service call and closes it when the call is done. Therefore, you will not normally need to create your own connection. Additionally, Kiss automatically starts a new transaction with each REST service and commits it when the service is done. However, if the service throws any exception, the transaction is rolled back instead.
You would not normally write SQL for single record adds, updates, and
deletes. Using the Record API, Kiss
automatically
generates these statements for you.
In addition to the above, these utilities provide full support for transactions and parameters.
Microservices are classes that may be added, changed, or deleted while the system is running. In spite of this, however, all microservices are fully compiled and run at full speed. This has two major advantages.
First, in a development environment, all development may be done without the need to bring the development server down, rebuild, re-deploy, and reboot the development server. This means development time is significantly reduced. Additionally, IDE debuggers function in an environment such as this so the debugging process may proceed normally.
Second, in a production environment, the system may be upgraded without disrupting existing users on the system. Of course users actively using the exact features you have just changed could be affected (if their front-end and back-ends do not agree). A simple re-try would put everything back in sync.
Kiss microservices are on a class basis. What that means is that a microservice is always a single and whole class. You cannot have more than one class in a microservice. Microservices can call core components of the system just as regular methods can. However, if one wishes to have one microservice call another microservice, the calling mechanism is a little more clunky. However, using this clunkier mechanism retains all of the dynamic features of the system.
Defining microservices in Kiss involves defining a normal class just as you would write a class in any circumstance. No special configuration, wiring, declarations, or additional steps are required. Microservice additions, changes, and deletions take affect as soon as you save the source file. All microservices are compiled at runtime by the system automatically. So there is no compilation step that you need to perform.
The only caveat to the above is that remote microservices (described below) expect a certain method signature (standard arguments). This is only to assure that the front-end and back-end can communicate as expected. Local microservices do not have this requirement.
In Kiss, microservices can be written in Java, Groovy, or Common Lisp. However, Groovy microservices have been used exclusively in all current environments that we are aware of. Therefore, Groovy microservices are best tested.
The reasons Groovy was used are as follows:
Having said all this, however, all three languages are fully supported and there are no known bugs in any of the languages supported.
There are two types of microservices as follows:
Remote services are generally called by a (likely JavaScript) front-end or a remote client typically over HTTP or HTTPS. Local services are services that are called locally, from within the system as, for example, one microservice calling a method in a different microservice.
In Kiss, remote microservices appear to the outside world as typical REST services. They may be called by a JavaScript front-end, web service client, or any other facility that can talk to REST services.
Kiss REST services are asynchronous HTTP or
HTTPS services. Internally they are processed utilizing a
thread pool to assure optimal CPU utilization. The number of threads
in the thread pool is controlled by a configuration parameter given in
the KissInit.groovy
file.
Kiss comes with JavaScript code so that Kiss
REST
services can be easily accessed from a typical front-end.
This code resides in a single file and can and has been used by
alternative front-ends such as Angular and React
.
There is no need to handle authentication. Kiss handles that automatically. So, when your web method is called, you know who they are and that they have been authenticated.
Remote REST microservices typically reside under the
backend/services
directory. You can organize them any way you
like. A microservice is equivalent to a class. The class name is the
microservice name. The methods in that class that have a certain
signature (particular set of arguments) are the web methods.
A REST web microservice has the following signature:
void myMethod(JSONObject injson, JSONObject outjson, Connection db, ProcessServlet servlet) { ... }
This is a JSON
object that contains all of the arguments passed
in from the front-end.
This is a JSON
object which will contain all of the results
sent back to the front-end. Whatever is put in this object gets sent back to the front-end.
This is a database connection that can be used to access the SQL database. The connection is unique and independent of all other services.
This object provides access to various system facilities uniquely related to this call.
See JSON and the JavaDoc
for additional information.
Local microservices are simply regular classes. They typically reside
in the backend/services
directory organized anyway you like.
Although methods within a particular microservice/class can call each
other in the normal way, there is an extra step required for one
microservice to call method in a different microservice. One of the
reasons for this is so the system can be certain the latest version of
the service is loaded and that it is fully compiled before you attempt
to use it.
In Groovy, a method in one class/microservice can call a method in a different class/microservice via the following methods.
See the Javadoc.
The first two arguments to all REST methods is injson
and
outjson
. injson
is a JSONObject
that contains
the data passed in from the front-end. outjson
is a
pre-initialized, empty JSONObject
that will be returned
to the front-end. The rest service should read the data passed in
from injson
, perform any needed processes, and put the result
into outjson
to be returned to the front-end.
A modified version of a publicly available JSON Java package is included and used to access JSON from the front-end and create JSON to return to the front-end. This package has many methods but only a few are commonly used.
There are two main data type of interest. They are JSONObject
and
JSONArray
. They hold the JSON types indicated by their names.
Command useful for getting data out of injson
:
Again, outjson
is supplied as a pre-initialized, but empty,
JSONObject
. It is up to the REST service code to populate it
with the return data. Useful JSON utilities include the following:
Kiss includes an ever-growing set of utilities to help deal with common tasks.
These utilities are located under the src/main/core/org/kissweb
directory and have names such as
DateTime.java
, NumberFormat
, etc. These utilities
are documented in the JavaDocs.
In addition to utilizing Kiss as a web application development system, Kiss also provides a command line interface. This interface allows you to build quick but powerful utilities to do things like updating a database, parsing a CSV file, interfacing with a third-party REST service, and more. Basically, all of Kiss is available except the Kiss REST server.
Although this system supports PostgreSQL out-of-the-box, it also supports any of the other databases with a slightly more complex command line.
The build system (bld) has the ability to build a JAR file named KissGP.jar. The GP stands for Groovy and PostgreSQL. Basically, it is a JAR file capable of running Groovy scripts in the context of all of the Kiss utilities including access to a PostgreSQL database.
(It should be noted that although Groovy scripts are text / source files, they nevertheless run at full compiled speed because they are compiled at runtime.)
To build the JAR file, type the following:
./bld KissGP
A file named KissGP.jar will be created in the build.work directory. That, in addition to the JDK, is all that is needed to use the system.
To use the Kiss command line interface you first create the Groovy program you would like to run. It may use all of the Groovy and Kiss API. For example, let’s start with something simple. Create the following file named test1.groovy:
static void main(String [] args) { println "Hello world!" }
You can then run the program as follows:
java -jar KissGP.jar test1
test1.groovy can be extended arbitrarily to perform any function needed.
Although KissGP.jar comes bundled with support for the PostgreSQL database, KissGP.jar can support databases other than PostgreSQL by adding the driver for the database and using a slightly more complex command line as follows.
To use KissGP.jar with Microsoft SQL Server, for example, you’d have to include the database driver for it in addition to the KissGP.jar file and the file with your program. The command line would look as follows:
java -cp mssql-jdbc-8.2.0.jre8.jar -jar KissGP.jar test1
The same is true of the other databases. Please note that the drivers you’ll need are already in the libs directory.
Although there are no specific instructions, portable desktop applications can be built utilizing Kiss in conjunction with Electron (https://electronjs.org). These applications would be portable to Linux, Mac, Windows, and other platforms with a single codebase.
Kiss would provide the back-end portion of the application as a local server and could be written in Java, Groovy, or Lisp.
The front-end portion of Kiss would be used in conjunction with Electron in HTML, CSS, and JavaScript.
The two halves would communicate locally and operate as a standard desktop application.
If there is interest, please contact this author for assistance.


{{errMsg}}
If you delete group '{{selectedGroup.groupName}}'' the following students will become groupless:
You can make groups to make it easier to monitor progress of students you teach. Students can choose which group to join when visiting the webdicaat.
| Group {{g.groupName}} | {{g.members ? g.members.length : 'No '}} members | {{g.totalPoints}} points |
|
{{errMsg}}
| {{c.name}} | {{c.email}} | {{c.email == dictaat.owner.email ? 'Owner' : 'Contributer'}} |
This action CANNOT be undone. This will create a copy of the {{dictaat.name}} webdictaat, questions, ratings, etc..
Type the name of new dictaat to continue:
{{errorMsg}}
A copy will be made of all the quizes, polls, pages and assignments. Disclaimer: This is a new experimental feature. The new dictaat will require custom changes to function fully.
A new copy with the name {{newName}} has been created for you. Click here if you want to create another copy.
Once you delete a webdictaat, there is no going back. Please be certain.


Half-Life Is Back, This Time with Virtual Reality
After 12 years of break, Valve announced the new Half-Life game and it's going to be available on November 21.
by Nursah ErgüIf you like video games, you definitely know about Half-Life, which is a first-person shooter game. The first-ever Half-Life was released on November 19, 1998. The second game was released on November 16, 2004, and the last game, Half-Life 2: Episode Two was released on October 10, 2007.
SEE ALSO: COUNTER-STRIKE AT 20: A GAME CHANGER FOR GAMERS
And Half-Life fans have been waiting for Half-Life 2: Episode Three or Half-Life 3, but it's been a long time since the last Half-Life game was released.
On November 18, Valve announced on Twitter their new game, but it doesn't include any 3 in its name, it's called Half-Life: Alyx. Also, it's a VR (virtual reality) game.
This week on Thursday, the game will be introduced to the fans. However, the game has been criticized since it's a VR game and it obviously requires a VR headset, which isn't so cheap for fans all around the world.
While some other fans are really happy and excited at the moment about the announce of the new Half-Life game, which will be released after 12 years.
Are you excited about the new Half-Life game?


| Member function | typical form for class C : |
|---|---|
| Default constructor | C::C(); |
| Destructor | C::~C(); |
| Copy constructor | C::C (const C&); |
| Copy assignment | C& operator= (const C&); |
| Move constructor | C::C (C&&); |
| Move assignment | C& operator= (C&&); |
|
|
Example
has a default constructor. Therefore, objects of this class can be constructed by simply declaring them without any arguments:
|
|
|
|
int
. Therefore the following object declaration would be correct:
|
|
|
|
|
|
bar's content: Example |
Example3
has a default constructor (i.e., a constructor without parameters) defined as an empty block:
|
|
Example3
to be constructed without arguments (like foo
was declared in this example). Normally, a default constructor like this is implicitly defined for all classes that have no other constructors and thus no explicit definition is required. But in this case, Example3
has another constructor:
|
|
void
. It also uses the class name as its own name, but preceded with a tilde sign (~
):
|
|
bar's content: Example |
Example4
allocates storage for a string
. Storage that is later released by the destructor.foo
and bar
this happens at the end of function main
.const
qualified) and which can be invoked with a single argument of this type. For example, for a class MyClass
, the copy constructor may have the following signature:
|
|
|
|
|
|
Example4
we defined above, because it contains pointers of which it handles its storage. For that class, performing a shallow copy means that the pointer value is copied, but not the content itself; This means that both objects (the copy and the original) would be sharing a single string
object (they would both be pointing to the same object), and at some point (on destruction) both objects would try to delete the same block of memory, probably causing the program to crash on runtime. This can be solved by defining the following custom copy constructor that performs a deep copy:
|
|
bar's content: Example |
|
|
baz
is initialized on construction using an equal sign, but this is not an assignment operation! (although it may look like one): The declaration of an object is not an assignment operation, it is just another of the syntaxes to call single-argument constructors.foo
is an assignment operation. No object is being declared here, but an operation is being performed on an existing object; foo
.operator=
which takes a value or reference of the class itself as parameter. The return value is generally a reference to *this
(although this is not required). For example, for a class MyClass
, the copy assignment may have the following signature:
|
|
Example5
. In this case, not only the class incurs the risk of deleting the pointed object twice, but the assignment creates memory leaks by not deleting the object pointed by the object before the assignment. These issues could be solved with a copy assignment that deletes the previous object and performs a deep copy:
|
|
string
member is not constant, it could re-utilize the same string
object:
|
|
|
|
fn
and the value constructed with MyClass
are unnamed temporaries. In these cases, there is no need to make a copy, because the unnamed object is very short-lived and can be acquired by the other object when this is a more efficient operation.
|
|
&&
). As a parameter, an rvalue reference matches arguments of temporaries of this type.
|
|
foo's content: Example |
| Member function | implicitly defined: | default definition: |
|---|---|---|
| Default constructor | if no other constructors | does nothing |
| Destructor | if no destructor | does nothing |
| Copy constructor | if no move constructor and no move assignment | copies all members |
| Copy assignment | if no move constructor and no move assignment | copies all members |
| Move constructor | if no destructor, no copy constructor and no copy nor move assignment | moves all members |
| Move assignment | if no destructor, no copy constructor and no copy nor move assignment | moves all members |
default
and delete
, respectively. The syntax is either one of:function_declaration = default; function_declaration = delete; |
|
|
bar's area: 200 |
Rectangle
can be constructed either with two int
arguments or be default-constructed (with no arguments). It cannot however be copy-constructed from another Rectangle
object, because this function has been deleted. Therefore, assuming the objects of the last example, the following statement would not be valid:
|
|
|
|
|
|
default
does not define a member function equal to the default constructor (i.e., where default constructor means constructor with no parameters), but equal to the constructor that would be implicitly defined if not deleted.delete
or default
on the other special member functions they don't explicitly define.| Previous: Classes (II) | Index | Next: Friendship and inheritance |


{% extends "base.html" %} {% block title %} Home | Web Chain {% endblock %} {% block body %}
in the blockchain
of string saved as strings in the blocks of this blockchain
| Index | Block Hash | Time (UTC) | Block Data |
|---|---|---|---|
| {{ block.index }} | {{ block.hash[:20] }}... | {{ block.time }} | {{ block.data[:50] + (block.data[50:] and '...') }} |


@() @main("Dashboard") { @defining(play.core.PlayVersion.current) { version => Dashboard Services ServiceName OnTime } }


AP adding 14 statehouse reporters in new partnership
by TALI ARBELThe Associated Press is adding 14 statehouse reporters for 18-month jobs through a collaboration with Report for America, a group dedicated to local reporting.
Report for America is part of a growing effort to help local media. In rural areas and even many cities, papers are shrinking and shutting down while coverage peters out. The media group GroundTruth Project, which supports younger journalists globally, launched the initiative in 2017.
Report for America recruits reporters and pays part of their salaries, putting them to work at existing news organizations. It has funded reporters at newspapers, online publications, radio and TV outlets, and other news organizations such as the AP.
The initiative is one of many designed to support local news. Other efforts to fund local reporting have come from journalism foundations; tech companies like Google, which has a partnership with newspaper publisher McClatchy; and media organizations like the investigatory nonprofit website ProPublica.
AP’s new reporters will be in Colorado, Indiana, Kansas, Michigan, Minnesota, Mississippi, Nevada, New Mexico, North Carolina, Ohio, Oregon, South Carolina and Utah. They will be joined by a data journalist covering all 50 states. They will report on state politics and policy, as well as issues such as voter access, health care and state budgets.
“An investment in AP at the statehouse is an investment in the health of an entire state news ecosystem,” Noreen Gillespie, AP’s deputy managing editor for U.S. news, said in a statement.
Reporters’ stories will be available to AP’s customers and other news outlets in those states. AP will also distribute stories by other Report for America journalists.
“One of the most important crises facing our democracy is the alarming shortage of local news coverage about state government, which determines much of the public policy affecting the lives of Americans,” Report for America President Steven Waldman said in a statement.
Sign up for Daily Newsletters
Copyright © 2019 The Washington Times, LLC.
Please read our comment policy before commenting.


| Package | Description |
|---|---|
| javax.activation | |
| javax.annotation |
This package defines the common annotations.
|
| javax.annotation.security |
This package contains the security common annotations.
|
| javax.annotation.sql | |
| javax.batch.api |
Provides APIs used by Batch artifacts.
|
| javax.batch.api.chunk |
Provides APIs used by artifacts in a Batch chunk step.
|
| javax.batch.api.chunk.listener |
Provides APIs defining listener artifacts for a Batch chunk step.
|
| javax.batch.api.listener |
Provides APIs defining Batch job-level and step-level listener artifacts.
|
| javax.batch.api.partition |
Provides APIs for artifacts specific to a Batch partitioned step.
|
| javax.batch.operations |
Provides APIs for starting, managing, and viewing results of Batch job executions, along with a set of exceptions.
|
| javax.batch.runtime |
Provides APIs for viewing the detailed outcomes and metrics of Batch job executions.
|
| javax.batch.runtime.context |
Provides APIs for context classes allowing data sharing across Batch artifacts within a job instance and within a step.
|
| javax.decorator |
Annotations relating to decorators.
|
| javax.ejb | |
| javax.ejb.embeddable | |
| javax.ejb.spi | |
| javax.el | |
| javax.enterprise.concurrent |
Classes and interfaces that make up the Jakarta Concurrency specification.
|
| javax.enterprise.context |
Annotations and interfaces relating to scopes and contexts.
|
| javax.enterprise.context.control | |
| javax.enterprise.context.spi |
The custom context SPI.
|
| javax.enterprise.deploy.model | |
| javax.enterprise.deploy.model.exceptions | |
| javax.enterprise.deploy.shared | |
| javax.enterprise.deploy.shared.factories | |
| javax.enterprise.deploy.spi | |
| javax.enterprise.deploy.spi.exceptions | |
| javax.enterprise.deploy.spi.factories | |
| javax.enterprise.deploy.spi.status | |
| javax.enterprise.event |
Annotations and interfaces relating to events.
|
| javax.enterprise.inject | |
| javax.enterprise.inject.literal | |
| javax.enterprise.inject.se | |
| javax.enterprise.inject.spi |
The portable extension integration SPI.
|
| javax.enterprise.inject.spi.configurator | |
| javax.enterprise.util |
Contains shared, general-purpose helper classes and annotations.
|
| javax.faces | |
| javax.faces.annotation | |
| javax.faces.application | |
| javax.faces.bean |
This package is now deprecated.
|
| javax.faces.component | |
| javax.faces.component.behavior | |
| javax.faces.component.html |
Specialized user interface
component classes for HTML.
|
| javax.faces.component.search | |
| javax.faces.component.visit | |
| javax.faces.context | |
| javax.faces.convert | |
| javax.faces.el | |
| javax.faces.event | |
| javax.faces.flow | |
| javax.faces.flow.builder | |
| javax.faces.lifecycle | |
| javax.faces.model | |
| javax.faces.push | |
| javax.faces.render | |
| javax.faces.validator | |
| javax.faces.view | |
| javax.faces.view.facelets | |
| javax.faces.webapp | |
| javax.inject |
This package specifies a means for obtaining objects in such a way as to
maximize reusability, testability and maintainability compared to
traditional approaches such as constructors, factories, and service
locators (e.g., JNDI). This process, known as dependency
injection, is beneficial to most nontrivial applications.
|
| javax.interceptor | |
| javax.jms | |
| javax.json |
Provides an object model API to process JSON.
|
| javax.json.bind |
Provides JSON Binding API, which enables binding Java objects from and to
JSON documents.
|
| javax.json.bind.adapter |
Defines adapter related classes.
|
| javax.json.bind.annotation |
Defines annotations for customizing the mapping between Java program elements
and JSON documents.
|
| javax.json.bind.config |
Defines strategies and policies for customizing the mapping between Java program elements
and JSON documents.
|
| javax.json.bind.serializer |
Defines serializer depending classes.
|
| javax.json.bind.spi |
Service Provider Interface (SPI) to plug in implementations of JSON
Binding API
JsonbBuilder objects. |
| javax.json.spi |
Service Provider Interface (SPI) to plug in implementations for
JSON processing objects.
|
| javax.json.stream |
Provides a streaming API to parse and generate
JSON.
|
| javax.jws |
This package defines annotations for light-weight web services programming model.
|
| javax.jws.soap |
This package defines annotations for SOAP binding definition within light-weight web services programming model.
|
| javax.mail | |
| javax.mail.event | |
| javax.mail.internet | |
| javax.mail.search | |
| javax.mail.util | |
| javax.management.j2ee | |
| javax.management.j2ee.statistics | |
| javax.persistence |
Jakarta Persistence is the API for the management for persistence and object/relational mapping.
|
| javax.persistence.criteria |
Jakarta Persistence Criteria API
|
| javax.persistence.metamodel |
Jakarta Persistence Metamodel API
|
| javax.persistence.spi |
SPI for Jakarta Persistence providers
|
| javax.resource | |
| javax.resource.cci | |
| javax.resource.spi | |
| javax.resource.spi.endpoint | |
| javax.resource.spi.security | |
| javax.resource.spi.work | |
| javax.security.auth.message | |
| javax.security.auth.message.callback | |
| javax.security.auth.message.config | |
| javax.security.auth.message.module | |
| javax.security.enterprise |
The main Jakarta Security package.
|
| javax.security.enterprise.authentication.mechanism.http |
The HTTP authentication mechanism API package.
|
| javax.security.enterprise.credential |
The Identity Store Credential API package.
|
| javax.security.enterprise.identitystore |
The identity store API package.
|
| javax.security.jacc | |
| javax.servlet | |
| javax.servlet.annotation | |
| javax.servlet.descriptor | |
| javax.servlet.http | |
| javax.servlet.jsp | |
| javax.servlet.jsp.el | |
| javax.servlet.jsp.jstl.core | |
| javax.servlet.jsp.jstl.fmt | |
| javax.servlet.jsp.jstl.sql | |
| javax.servlet.jsp.jstl.tlv | |
| javax.servlet.jsp.tagext | |
| javax.transaction | |
| javax.validation |
Top level package of the Jakarta Bean Validation API.
|
| javax.validation.bootstrap |
Package containing bootstrap specific objects.
|
| javax.validation.constraints |
Contains all the Jakarta Bean Validation provided constraints
also called built-in constraints.
|
| javax.validation.constraintvalidation |
Package containing constructs specific to constraint validators.
|
| javax.validation.executable |
Package related to the control and execution of executable validation.
|
| javax.validation.groups |
A group defines a subset of constraints.
|
| javax.validation.metadata |
Package containing all objects specifically used and returned by the
metadata API.
|
| javax.validation.spi |
Package containing objects specific to the interaction between the
Jakarta Bean Validation bootstrapping process and Jakarta Bean Validation providers.
|
| javax.validation.valueextraction |
Package containing objects dedicated to extract values to validate from containers.
|
| javax.websocket |
This package contains all the Jakartq WebSocket APIs common to both the client and server side.
|
| javax.websocket.server |
This package contains all the Jakarta WebSocket APIs used only by server side applications.
|
| javax.ws.rs |
High-level interfaces and annotations used to create RESTful service
resources.
|
| javax.ws.rs.client |
The Client API
|
| javax.ws.rs.container |
Container-specific API.
|
| javax.ws.rs.core |
Low-level interfaces and annotations used to create RESTful service
resources.
|
| javax.ws.rs.ext |
APIs that provide extensions to the types supported by the API.
|
| javax.ws.rs.sse |
Server-Sent Events related API.
|
| javax.xml.bind |
Provides a runtime binding framework for client applications including
unmarshalling, marshalling, and validation capabilities.
|
| javax.xml.bind.annotation |
Defines annotations for customizing Java program elements to XML Schema mapping.
|
| javax.xml.bind.annotation.adapters |
XmlAdapter and its spec-defined
sub-classes to allow arbitrary Java classes to be used with Jakarta XML Binding. |
| javax.xml.bind.attachment |
This package is implemented by a MIME-based package processor that
enables the interpretation and creation of optimized binary data
within an MIME-based package format.
|
| javax.xml.bind.helpers |
Jakarta XML Binding Provider Use Only: Provides partial default implementations for
some of the
javax.xml.bind interfaces. |
| javax.xml.bind.util |
Useful client utility classes.
|
| javax.xml.registry |
This package and its sub-packages describe the API classes and interfaces
for the Jakarta XML Registries API.
|
| javax.xml.registry.infomodel |
This package describes the information model for the Jakarta XML Registries
API.
|
| javax.xml.rpc | |
| javax.xml.rpc.encoding | |
| javax.xml.rpc.handler | |
| javax.xml.rpc.handler.soap | |
| javax.xml.rpc.holders | |
| javax.xml.rpc.server | |
| javax.xml.rpc.soap | |
| javax.xml.soap |
Provides the API for creating and building SOAP messages.
|
| javax.xml.ws |
This package contains the core Jakarta XML Web Services APIs.
|
| javax.xml.ws.handler |
This package defines APIs for message handlers.
|
| javax.xml.ws.handler.soap |
This package defines APIs for SOAP message handlers.
|
| javax.xml.ws.http |
This package defines APIs specific to the HTTP binding.
|
| javax.xml.ws.soap |
This package defines APIs specific to the SOAP binding.
|
| javax.xml.ws.spi |
This package defines SPIs for Jakarta XML Web Services.
|
| javax.xml.ws.spi.http |
Provides HTTP SPI that is used for portable deployment of Jakarta XML Web Services
in containers (for example servlet containers).
|
| javax.xml.ws.wsaddressing |
This package defines APIs related to WS-Addressing.
|


--- layout: post title: Call Later with swiz date: type: post parent_id: '0' published: false password: '' status: pitch categories: [] tags: [] meta: _edit_last: '1' _su_title: '' author: login: akropp email<EMAIL_ADDRESS>display_name: akropp first_name: '' last_name: '' permalink: "/2012/12/17/call-later-with-swiz/" ---
talk about invlaidation manager as3


Your browser does not support the
video
element.
Heatmap
0 seconds
46 seconds
History
0 seconds
46 seconds


What is Docker?
- Motto: Build, Ship, Run
- Open platform for distributed applications
- Allow you to package your app with all its dependencies
What is Docker?

- So the software should always run the same (not depending of the environment)
Difference between VM and Docker?
- Containers include app and all the dependencies
- BUT share the kernel between each other
- So it is light, more portable and efficient than VM
- It is supported by Compute Canada! (On Guillimin for the moment,Mammouth soon)
Limitations?
- Run on Unix system
- On Mac and Windows it require VM!
- Painfull to use on Mac (own experience)
- Similar to Github but for Docker container sharing
- Public/private repo
- Collaborators, can have some privilege (example: push new version)
How to package pipeline, interactive
How to package Pipeline, interactive
How to package Pipeline, Docker file
How to package Pipeline, interactive
How to package Pipeline, interactive
How to package Pipeline, Dockerfile
How to package Pipeline, Dockerfile
How to package Pipeline, Dockerfile


|
Little Heroes
|
Classes | |
| class | ExitGames.Client.Photon.LoadbalancingPeer |
| Internally used by PUN, a LoadbalancingPeer provides the operations and enum definitions needed to use the Photon Loadbalancing server (or the Photon Cloud). | |
| class | ExitGames.Client.Photon.ErrorCode |
| Class for constants. | |
| class | ExitGames.Client.Photon.ActorProperties |
| Class for constants. More... | |
| class | ExitGames.Client.Photon.GameProperties |
| Class for constants. More... | |
| class | ExitGames.Client.Photon.EventCode |
| Class for constants. More... | |
| class | ExitGames.Client.Photon.ParameterCode |
| Class for constants. More... | |
| class | ExitGames.Client.Photon.OperationCode |
| Class for constants. More... | |
| class | AuthenticationValues |
| Container for "Custom Authentication" values in Photon (default: user and token). More... | |
Namespaces | |
| package | ExitGames.Client.Photon |
Typedefs | |
| using | Hashtable = ExitGames.Client.Photon.Hashtable |
Enumerations | |
| enum | MatchmakingMode : byte { MatchmakingMode.FillRoom = 0, MatchmakingMode.SerialMatching = 1, MatchmakingMode.RandomMatching = 2 } |
| Options for matchmaking rules for OpJoinRandom. More... | |
| enum | CustomAuthenticationType : byte { CustomAuthenticationType.Custom = 0, CustomAuthenticationType.Steam = 1, CustomAuthenticationType.Facebook = 2, CustomAuthenticationType.None = byte.MaxValue } |
| Options for optional "Custom Authentication" services used with Photon. More... | |
| using Hashtable = ExitGames.Client.Photon.Hashtable |
| enum CustomAuthenticationType : byte |
Options for optional "Custom Authentication" services used with Photon.
Used by OpAuthenticate after connecting to Photon.
| Enumerator | |
|---|---|
| Custom |
Use a custom authentification service. Currently the only implemented option. |
| Steam |
Authenticates users by their Steam Account. Set auth values accordingly! |
|
Authenticates users by their Facebook Account. Set auth values accordingly! | |
| None |
Disables custom authentification. Same as not providing any AuthenticationValues for connect (more precisely for: OpAuthenticate). |
| enum MatchmakingMode : byte |
Options for matchmaking rules for OpJoinRandom.


I was born November 22, 2000. My early childhood was spent growing up quickly to care for myself and my two sisters, necessary because of not having a parental figure. It wasn't an ideal start but I learned a lot about the world from a very young age, granting a unique perspective.
This was around the time of schooling, something I excelled at throughout most of the standard 12 years. Regardless of my ability to obtain good grades, the school system was never of much interest to myself. Instead, I spent most of my time exploring and learning in other ways such as building robots / solar cars, joining a mathlete team, and enjoying chess club.
After graduating in 2019 I tried out college for a while, quickly realizing it also was not for me. I have spent the past year teaching myself how to create a business, freelance various services such as coaching/management for Esports Teams, and Reselling items to help out my family and save up toward buying my first home.
While the start of this year was rough for everyone, I took it as an opportunity to become the best version of myself. I was able to successfully save up and buy my own place with my lovely partner, moving across the country to a beautiful small town in Massachusetts. I have learned about HTML, CSS, Facebook Ads, Google Analytics, Facebook Pixel, SQL, and the fundamentals of Growth Marketing with Mehak in OnDelta. I absolutely love learning and expanding my knowledge/skills ; I am excited to meet you and share knowledge with one another!


--- layout: post title: Thanks to git I'm releasing IP into the wild! tags: - Git - LinkedIn - Open Source Software - Software Development - Work Practices status: publish type: post published: true meta: _edit_last: '451289' --- This week I at last did something I'd wanted to do for a long time and release some of Voga's intellectual property to the wider world. I have already made material available either through this blog or via Slideshare. However for a geek it's obviously better to publish complete projects in an Open Source manner so they can be freely copied, modified and shared. For historical reasons this had been inconvenient to do as I used to hold everything in a single Subversion repository. Not only did this contain my potentially open material, but also my customers private data and my business records (yes, I keep my accounts database in a version control repository!). A few months I migrated my Subversion repo to git, but I still had a single large repo and no time or skill to fix it. However today I bit the bullet


|
|
|
How to Manage PestsCalifornia Weather Database: Description
DateThe date of the observation. Hour or Time of ObservationTime of observation on the 24-hour clock, from 0001 through 2400 represented by four-digits in the format HHMM, where HH is hours and MM is minutes. Some elements of a weather observation occur at the time of observation, e.g., dry-bulb, wet-bulb temperatures. Others are from the 24-hour period prior to time of observation, e.g., precipitation. If maximum and minimum temperatures are the only data entered for a date, it is assumed that they are for the midnight to midnight period for that date. PrecipitationAmount. The amount of precipitation (rain or liquid equivalent of frozen precipitation) during the 24 hours prior to the time of observation. Amounts are in inches (to hundredths), except where more than 10 inches fell in one day; then amounts are in inches to tenths. Also,
Type. The predominant type of precipitation that fell. Abbreviations are:
Air TemperaturesAir temperatures are measured at a height of 5 to 6 feet. Maximum and minimum. The highest and lowest, respectively, temperatures (F or C) that has occurred during the 24 hours prior to the time of observation, or that has occurred during the midnight to midnight period on the given day if no time of observation is specified. Temperatures below zero are indicated by a "-". Observation. The air temperature (F or C) at time of observation. Temperatures below zero are indicated by a "-". Weather Type"Weather type" contains information about the weather at the observation time. Also, if a significant weather event occurs during a day, hail or a tornado for instance, the occurrence may be noted in this field.
WindClimate and TouchTone stations: speed and direction at the time of observation are reported. Automatic and PestCast stations: average speed and direction for the date are reported. The format is DDSS, where DD is direction from which the wind is blowing with direction noted to 8 points of the compass (N, NE, E, SE, S, SW, W, NW), and SS is speed in miles per hour or meters per second. Calm or no wind is indicated by 0000. Bulb TemperaturesWet-bulb and dry-bulb temperature readings are made from a psychrometer, to be used in calculating dew point and relative humidity. Wet-bulb and dry-bulb temperature readings are made at the time of observation. They are entered to a tenth of a degree when the value is less than 100F. Above 100F, only whole degrees are entered. Values are in Fahrenheit or Celsius. Soil TemperaturesMaximum. Maximum soil temperature (F or C) at the depth indicated in the station description during the 24-hour period prior to time of observation. Minimum. The lowest soil temperature (F or C) at the depth indicated in the station description that has occurred during the 24 hours prior to the time of observation. Pan EvaporationThe amount of water evaporated from the surface of a water-filled evaporation pan. The amount is in inches and hundredths, for the 24-hour period prior to the time of observation. A value of "*SM" indicates that the amount is included in subsequent measurement. Relative HumidityThe maximum and minimum values of relative humidity for the 24 hours prior to the time of observation are reported for Automatic stations. Values are in percent. EToThe daily reference evapotranspiration (ETo) is calculated by the California Department of Water Resources CIMIS Project for its Automatic stations and it is also calculated for some PestCast stations. ETo is reported in inches or millimeters. Solar RadiationGlobal solar radiation is found in this field. Solar radiation is in langleys/day (cal/cm2/day) or Watts/m2. The value is for the 24 hours prior to the time of observation. Leaf Wetness DurationLeaf wetness is reported as the number of hours (and fractions) of a day that the sensor indicates it is wet.
The set of variables reported by each PestCast station is likely to be different from other stations. However, within a network, the reported variables are usually very similar. See a station's description to find out which variables are reported. Measured variables may include (* indicates that the measurement may be reported more frequently)
Calculated variables may include
Definitions of measured variablesDateThe date on which the observation was made. Obs Time (Time of Observation)Time is Pacific Standard Time year round. The elements of a weather observation occur at the time of observation or cover the reported collection period prior to time of observation, e.g., precipitation total or average relative humidity. Reports are for the interval prior to the time reported. For daily observations, reports are for the 24 hours prior to the time of observation. For hourly or sub-hourly reports, reports are for the hour or other interval prior to the reported time. Air TemperaturesAir temperatures may be reported for up to three probes: AIR TEMP, AIR TEMP2, AIR TEMP3. Temperatures below zero are indicated by a "-". Maximum and minimum. The highest and lowest temperatures (F or C) that have occurred during the 24 hours prior to the time of observation. Time. Time at which the maximum or minimum temperature occurred, on a 24-hour clock. Time is always Pacific Standard Time. Average. The air temperature (F or C) averaged over the measurement interval prior to the time of observation. Relative HumidityMaximum and minimum. The maximum and minimum values of relative humidity for the 24 hours prior to the time of observation. Values are in percent. Average. The relative humidity averaged over the period prior to the time of observation. Precipitation AmountThe amount of precipitation (rain, since gauges are not heated to measure liquid equivalent of frozen precipitation) during the period prior to the time of observation. Amounts are in inches (to hundredths). Solar RadiationGlobal solar radiation is found in this field."English" units are langleys accumulated over the reported period. Metric units are Watts/m2. WindAverage. The average speed and direction over the prior period, in miles per hour or meters per second. Direction is in degrees, with 0 as North. Maximum speed, direction, and time. The speed and direction of the maximum gust during the period prior to time of observation, and the time at which it occurred. Soil TemperaturesMaximum and minimum. Highest and lowest soil temperatures (F or C) at the depth indicated in the station description during the 24-hour period prior to time of observation. Time. Time at which the maximum or minimum soil temperature occurred, on a 24 hour clock. Time is Pacific Standard Time year round. Average. The soil temperature (F or C) averaged over the period prior to the time of observation. Leaf WetnessFor daily reports, the number of hours that the sensor indicates "wet." For hourly or sub-hourly reports, the numbe of minutes that the sensor indicates "wet." Definitions of calculated variablesHours <= 32FNumber of hours that the temperature was at or below 32 degrees Fahrenheit. ChillingNumber of hours that the temperature was at or below 45 degrees Fahrenheit, often called "chilling hours." ThresholdsNumber of hours that the temperature was at or below the threshold temperatures given, usually provided for use in a biological model such as grape powdery mildew. |


Nekøyume
First Fantasy Role-playing Game
based on Blockchain
If you would like to receive news about the token sales schedule,
please enter your email address in the form below.
Adventures in the blockchain.
Nekoyume has included players’ action information in a blockchain
to implement fantasy role-playing in a decentralized environment.
When players hunt monsters, sleep, or give gifts to other players, this information is securely shared in a blockchain.
| 49 | F7 | 0A |
| ⇣ | ⇣ | ⇣ |
| ⚀ | ⚃ | ⚂ |
Technology to determine fate,
Hash Random
Nekoyume devised a random consensus called Hash random to create a dynamic situation within the blockchain. A combination of hashes taken from blocks creates an algorithm that is hard to predict and ensures a deterministic outcome.
See white paperSimple and profound play based on Dungeon World
Nekoyume is a fantasy role-playing game based on Dungeon World. This rule, designed by Sage LaTorra and Adam Koebel, inherits the strengths of Apocalypse World and Dungeons & Dragons.
Learn moreWhat can I do?
⚔ Fight
You encounter a nearby monster and battle it. A result over 10 is a big success; if it is between 7 and 9, you will be counterattacked by the enemy. If you get 6 or less, something will go wrong.
💤 Sleep
Fall asleep in your bed and regain your hit point. If you are seriously wounded by an enemy, you can fight again after recovering your hit points by sleeping. If you are lucky, you might have a memorable dream.
🗣 Say
You can talk to players who is following you. If you leave something important, that story will be addressed by others.
➡ Send
You can pass on your items to other players. You can change your bandages to keep your colleagues from injury, or you can trade items for gold. Trading is the key to growth!
Players can grow bigger with Gold.
- 🔼 Obtain a status bonus proportional to the amount held
- 🤓 Obtain valuable items through composition
- 🤝 Collect various items through trading
How can I earn Gold?
● Buy gold at the Token Sales Event in August
Nekoyume Gold (NYG), which is available on the mainnet, will be sold in the form of the Ethereum ERC20 token. We will sell 21% of the total volume.1
● Participate in the core team
During the intensive development period over the next year, 9% of the gold reserves will be distributed to the core team members in proportion to their contribution amounts. If you can help with development in any direction, please apply for support at<EMAIL_ADDRESS>or send a Pull Request for the opened issue.
● Participate in the network
After launching the mainnet, you can obtain gold by providing a client based on the published code or creating a block by executing $ neko
. It will be the largest of all rewards portions and will be the only way to earn Gold from 2019 on. The planned amounts over four years are as follows.
| Miner & client incentive / 4y | Reward | Starting Year |
|---|---|---|
| 134,553,600 | 16 | 2018 |
| 67,276,800 | 8 | 2022 |
| 33,638,400 | 4 | 2026 |
| 16,819,200 | 2 | 2030 |
| 8,409,600 | 1 | 2034 |
If you would like to receive news about the token sales schedule, please enter your E-mail address in the form below.
{% include email_form.html %} 1: Total volume represents the 20-year volume including four half-lives. After 2038, block reward will be fixed at 1, resulting in inflation of about 0.5% per year.


Form Menu Title
Form Title
Form Item 1
Form Item 2
Form Item 3
Form Item 4
Form Item 5
Football calendar
Form
QR Code
Playground
Video
Album
Poster