Blog

  • webpack-template

    Webpack work template

    Webpack is a module bundler. Its main purpose is to bundle JavaScript files for usage in a browser, yet it is also capable of transforming, bundling, or packaging just about any resource or asset.

    Author: Vedees | Youtube guide (ru)

    Features:

    • separated configs for dev and prod
    • typescript / javascript full support
    • sass / css full support
    • full babel & postcss setup
    • 0 dependencies
    • the best optimization for your production
    • easy webpack and babel customization

    Everybody knows that developing runs on coffee! Thanks for your support!

    Buy me a coffee

    Build Setup:

    # Download repository:
    git clone https://github.com/vedees/webpack-template webpack-template
    
    # Go to the app:
    cd webpack-template
    
    # Install dependencies:
    # npm install
    # or:
    yarn
    
    # Server with hot reload at http://localhost:8084/
    # npm run start
    # or:
    yarn start
    
    # Output will be at dist/ folder
    # npm run build
    # or:
    yarn build

    Project Structure:

    • public/*.html – HTML files
    • src/app – core app
    • src/shared – shared files
    • src/shared/img – images folder (! for html calls use correct path: static/img/some.jpg)
    • src/shared/misc – misc files (i.g. favicon, sitemap, etc.)
    • src/index.ts – main app entity

    Configs:

    • /babel-defines.js – config for babel
    • /webpack/webpack-pages.js – config for html pages
    • /webpack/webpack-defines.js – config for entire webpack

    Main entry point:

    • src/app/index.ts – core entry point

    Defines:

    Core webpack config from /webpack/webpack-defines.js:

    const PATHS = {
      // path to the src dir
      src: path.join(__dirname, '../src'),
      // path to the output dir
      dist: path.join(__dirname, '../dist'),
      // path to the public files (html files)
      public: path.join(__dirname, '../public'),
    
      // path to output sub dir (js, css, fonts, etc.)
      assets: 'assets/',
      // path to output sub dir (img, icons, etc.)
      static: 'static/'
    }

    Pages config:

    Pages config from /webpack/webpack-pages.js:

    const pages = [
      {
        // page title
        title: 'Home page',
        // template name `public/index.html`
        template: 'index.html',
        // output filename `dist/index.html`
        filename: 'index.html',
    
        // other options can be here
      },
      {
        title: 'About page',
        template: 'about.html',
        filename: 'about.html',
      }
    ]

    You can pass a hash of configuration options to html-webpack-plugin.

    Allowed values are as follows: https://github.com/jantimon/html-webpack-plugin#options

    Manual pages setup:

    In case if you don’t want to use Pages config:

    1. Create another html file in ./public
    2. Go to ./webpack/webpack.common.js
    3. Add new page to the config:
        // index page:
        new HtmlWebpackPlugin({
          title: 'Home page',
          favicon: defines.src + '/shared/misc/favicon.ico',
          template: defines.public + '/index.html', // public/index.html page
          filename: 'index.html' // output file
        }),
        // about page:
        new HtmlWebpackPlugin({
          title: 'About page',
          favicon: defines.src + '/shared/misc/favicon.ico',
          template: defines.public + '/about.html', // public/about.html page
          filename: 'about.html' // output file
        }),

    Import libs example:

    Install it:

    yarn add bootstrap react react-dom

    Import libs to src/app/index.ts:

    // React example
    import React from 'react'
    
    // Bootstrap example (with custom js imports)
    import Bootstrap from 'bootstrap/dist/js/bootstrap.min.js'
    import 'bootstrap/dist/js/bootstrap.min.js'

    Import SASS / CSS libs example:

    Import libs to src/app/index.scss:

    // sass lib import example:
    @import '../../node_modules/spinners/stylesheets/spinners';
    // css lib import example:
    @import '../../node_modules/flickity/dist/flickity.css';

    React example:

    Here’s an example with React + i18n Provider.

    Install react:

    yarn add react react-dom

    Create div with id app in public/index.html:

    <div id="app"></div>

    Init the app in src/app/index.ts:

    import React from 'react'
    import { createRoot } from 'react-dom/client'
    
    // app styles
    import './index.scss'
    
    // local providers:
    import { I18nProvider } from './providers/I18nProvider'
    
    const container = document.getElementById('app') as HTMLElement
    const root = createRoot(container)
    
    root.render(
      <React.StrictMode>
        <I18nProvider>...</I18nProvider>
      </React.StrictMode>
    )

    File src/app/providers/I18nProvider.tsx:

    import React, { FC, PropsWithChildren } from 'react'
    
    export const I18nProvider: FC<PropsWithChildren> = ({ children }) => {
      // ...
    
      return <I18n locale={detectedLocale}>{children}</I18n>
    }

    Vue example:

    Install vue:

    yarn add vue

    Init the app in src/app/index.ts:

    // vue example (react one is above):
    const app = new Vue({
      el: '#app'
    })

    Create div with id app in public/index.html:

    <div id="app"></div>

    Adding Vue Components:

    Create your component in src/app/components/.

    HTML Usage (in *.html files):

    Init component in src/app/index.ts:

    Vue.component('example-component', require('./components/Example.vue').default)

    In any html files:

    <example-component />

    VUE Usage (in *.vue files):

    Import component:

    import ExampleComponent from '@/components/Example.vue'

    Init component (template):

    <Example />

    Register component (script):

    components: {
      Example: ExampleComponent
    }

    Adding Google Fonts:

    Connect fonts to public/index.html:

    <link rel="preconnect" href="https://fonts.googleapis.com" />
    <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
    <link href="https://fonts.googleapis.com/css2?family=Open+Sans:wght@400;500&display=swap" rel="stylesheet" />

    Change the font in src/app/styles/body.scss:

    html {
      font-family: 'Open Sans', -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, 'Apple Color Emoji', Arial, sans-serif, 'Segoe UI Emoji', 'Segoe UI Symbol' !important;
    }

    Adding local fonts:

    In case if you don’t want to use Google Fonts:

    • Download fonts
    • Add fonts to the (i.g. /src/shared/fonts/OpenSans/...).

    Then add @font-face in some .scss file (i.g. /src/app/styles/font.scss):

    // Open Sans example:
    @font-face {
      font-family: 'Open Sans';
      font-style: normal;
      font-weight: 400;
      font-stretch: 100%;
      font-display: swap;
      src: url('/static/fonts/OpenSans/Open-Sans.woff2') format('woff2');
      unicode-range: U+0460-052F, U+1C80-1C88, U+20B4, U+2DE0-2DFF, U+A640-A69F, U+FE2E-FE2F;
    }

    The last step is to copy these fonts into the /dist folder every time you build the project.

    Add another config for CopyWebpackPlugin to /webpack/webpack.common.js:

    new CopyWebpackPlugin({
      // ...
    
      // `shared/fonts` to `dist/static/fonts`
      {
        from: `${defines.src}/shared/fonts`,
        to: `${defines.dist}/${defines.static}/fonts`
      },
    })

    Change the font in src/app/styles/body.scss:

    html {
      font-family: 'Open Sans', -apple-system, BlinkMacSystemFont, 'Segoe UI', Helvetica, 'Apple Color Emoji', Arial, sans-serif, 'Segoe UI Emoji', 'Segoe UI Symbol' !important;
    }

    License:

    MIT

    Copyright (c) 2018-present, Evgenii Vedegis

    Visit original content creator repository
  • CucumberAutomationReports

    Cucumber-Java-JUnit Archetype

    This is the simplest possible build script setup for Cucumber using Java.
    There is nothing fancy like a webapp or browser testing. All this does is to show you how
    to install and run Cucumber!

    Usage

    Open a command window and run:

    mvn test
    

    This runs Cucumber features using Cucumber’s JUnit runner. The @RunWith(Cucumber.class) annotation on the RunCukesTest
    class tells JUnit to kick off Cucumber.

    Overriding options

    The Cucumber runtime parses command line options to know what features to run, where the glue code lives, what plugins to use etc.
    When you use the JUnit runner, these options are generated from the @CucumberOptions annotation on your test.

    Sometimes it can be useful to override these options without changing or recompiling the JUnit class. This can be done with the
    cucumber.options system property. The general form is:

    mvn -Dcucumber.options="..." test
    

    Let’s look at some things you can do with cucumber.options. Try this:

    -Dcucumber.options="--help"
    

    That should list all the available options.

    IMPORTANT

    When you override options with -Dcucumber.options, you will completely override whatever options are hard-coded in
    your @CucumberOptions or in the script calling cucumber.api.cli.Main. There is one exception to this rule, and that
    is the --plugin option. This will not override, but add a plugin. The reason for this is to make it easier
    for 3rd party tools (such as Cucumber Pro) to automatically configure additional plugins by appending arguments to a cucumber.properties
    file.

    Run a subset of Features or Scenarios

    Specify a particular scenario by line (and use the pretty plugin, which prints the scenario back)

    -Dcucumber.options="classpath:skeleton/belly.feature:4 --plugin pretty"
    

    This works because Maven puts ./src/test/resources on your classpath.
    You can also specify files to run by filesystem path:

    -Dcucumber.options="src/test/resources/skeleton/belly.feature:4 --plugin pretty"
    

    You can also specify what to run by tag:

    -Dcucumber.options="--tags @bar --plugin pretty"
    

    Running only the scenarios that failed in the previous run

    -Dcucumber.options="@target/rerun.txt"
    

    This works as long as you have the rerun formatter enabled.

    Specify a different formatter:

    For example a JUnit formatter:

    -Dcucumber.options="--plugin junit:target/cucumber-junit-report.xml"
    

    Visit original content creator repository

  • hacky-game

    Hacky Game

    This is the start of a game involving some crazy technical jazz,
    for the sake of magical minimalism.

    The game will be a platformer,
    with lots of interconnected rooms and various enemies,
    taking some inspiration from Kirby & the Amazing Mirror.

    (Some basics are implemented, like blocks, slopes, one-way platforms, and doors.
    There are several rooms, but they’re pretty boring,
    and the art is very preliminary.)

    The game supports LAN multiplayer,
    and the client’s world is simulated in between updates from the server,
    a basic implementation of client-side prediction.

    Single player is treated the same: the client hosts a server and communicates with it locally over TCP.
    This might change.

    When other servers are discovered,
    a door is opened to another world.

    Players can travel between worlds,
    and you can even have two players in each other’s worlds.
    (But the player’s client has to be online for their world to be available.)

    You should be able to get a feel for the game in single-player,
    with a substantial world to explore, but
    I think multiplayer will be the real focus of the game
    and I think it would be interesting to have parts of the world that you can only explore with a friend.

    Oh, did I mention the worlds are gonna be procedurally generated?
    That’s probably kind of important.
    It might have some areas that are the same in all worlds, like a tutorial level,
    or perhaps just fairly similar and functionally identical.

    Both players should gain from exploring either players world.
    It should be like the worlds combined make up the space to explore,
    and which one to do first shouldn’t feel contentious.

    There could be doors that require multiple keys, that you need to get from several people.
    There could be keys that belong to random other worlds and you have to find the one player whose world contains the door.
    There could be halves of items (including keys).

    Keys could be 2D “pin arrays”, where locks run a game-of-life simulation for a number of iterations.
    This would work well for a 1BPP game, as alternative to using color to distinguish keys.

    There could be portals that you can pick up and place, including between worlds.

    There should be limits on the viewport,
    maybe fixed but not necessarily;
    it could have a maximum viewport size, and the ability to look in a direction,
    and then the total amount you could look could be fixed
    while allowing for a range of screen sizes on handheld systems etc.

    The game runs in nw.js (so it can include both client and server),
    but the final game.exe is a wrapper.
    The wrapper currently built with nexe,
    although this essentially means distributing two Node.js runtimes,
    which is a considerable amount of overhead which could ultimately be avoided.
    It downloads the nw.js runtime (on first load)
    and extracts a zip file from a resource in the executable containing the main application.
    Then it launches the game, passing in the path to the executable.
    It does all this so it can read and write game state from the end of the exe file.
    (At the moment this functionality is disabled.
    I did a tech demo of this first, but there are no persistent elements to the world yet.)

    Open Doors to Other Worlds

    • Local multiplayer

      • Discovers other clients through tiny JSON files stored with ports and PIDs.
        Discovers other clients through SSDP

      • TODO:
        Manage input methods for multiple players.
        You should be able to play with two people on one keyboard,
        without some program to send input to two windows at once.

      • Could try to do single window splitscreen (“normal” local multiplayer) instead.

    • Multiplayer over LAN

      • Discovers other clients with SSDP

      • You can use Hamachi to establish connections between computers if LAN doesn’t work for you

      • TODO:
        When booted from a server, have the world door sputter out behind you

      • TODO:
        Get booted if server doesn’t respond for some time

    • TODO:
      Implement client-side prediction smoothing

    • FIXME:
      There is a race condition when going back and forth between rooms
      where you can get viewing a room that you aren’t in.
      Entering a door involves sending a command to the server
      but you switch the room you’re viewing instantly.

    • TODO:
      Remove the need for client-side prediction on the client’s own server;
      maybe merge the client and the server so they use one World

    • TODO:
      Use random seeds to render the exact same blades of grass etc. as another client for the same world.
      (Also, with pixi.js, it’ll probably be fast enough to render the grass dynamically, so there could be wind and stuff,
      rustling through the grass as you move,
      explosions sending waves of air…)

    Install

    Final builds of the game will be standalone executables,
    but there’s not much of a point yet to trying to release builds.

    You’ll need Node.js.
    Clone the project
    and then, in a terminal/command prompt in the project’s directory,
    run:

    npm install ; cd game ; npm install ; cd ..
    

    Run

    After installing, you can run the game with:

    npm start
    

    On the first run, it’ll download the nw.js runtime.

    There are also scripts to run multiple instances of the game:

    npm run start-secondary
    npm run start-tertiary
    

    These only work on Windows, but I could make a CLI script that works cross-platform,
    and allows any number of instances,
    plus other options like --enable-logging.

    Build

    The game implements hackily saving game data directly to the executable binary,
    which is rather platform specific.
    This is only implemented for Windows so far,
    but it should be feasible on at least some other systems.

    On Windows:

    npm run build
    

    On other platforms, for now:

    npm run build-simple
    

    Visit original content creator repository

  • quotes_statistics

    С приложением можно ознакомиться по адресу: https://quotestats.netlify.app

    Available Scripts

    In the project directory, you can run:

    npm start

    Runs the app in the development mode.
    Open http://localhost:3000 to view it in the browser.

    The page will reload if you make edits.
    You will also see any lint errors in the console.

    npm run build

    Builds the app for production to the build folder.
    It correctly bundles React in production mode and optimizes the build for the best performance.

    The build is minified and the filenames include the hashes.
    Your app is ready to be deployed!

    See the section about deployment for more information.

    1. Условие:
      необходимо создать веб-приложение, которое максимально быстро считает
      статистические параметры по котировкам с биржи.
      Для этого необходимо создать интерфейс который содержит кнопки “Старт” и “Статистика”.
      По нажатию на “Старт” должно происходить подключение к эмулятору котировок по адресу
      вебсокета wss://trade.trademux.net:8800/?password=1234 для получения котировок онлайн.
      При
      нажатии на кнопку “Статистика” отображает на странице такие статистические значения:
      среднее,
      стандартное отклонение,
      моду (при мультимодности достаточно только одну моду),
      медиану,
      количество потерянных котировок если такие есть,
      время расчетов.
      Расчеты должны
      осуществляться по всем полученным данным от момента старта до текущего момента нажатия
      кнопки “Статистика”, кнопку можно нажимать сколько угодно раз для получения новых
      результатов на текущее время.
      Формат “котировки” json, поля : {id : idкотировки, value : значениекотировки}
      Технические требования:
      • Приложение должно быть максимально оптимизировано по скорости работы.
      • Время между нажатием Старт и Статистика может быть очень большим (несколько
      дней)
      • Интерфейс должен быть удобен для использования.
      • Стиль кнопок должен быть:
      бордер ровно 1пкс черный,
      фон кнопки серый,
      при
      наведении мыши на кнопку фон должен становится белым,
      при клике на кнопку фон
      должен становится желтым
      (использовать для этого только CSS / SCSS).
      • Принятые числа отображать не нужно.
      Уровни сложности задания:
      junior уровень: посчитать только среднее и стандартное отклонение
      Более высокий уровень: посчитать также моду и медиану
      2.
      Условие:
      Написать “пингователь” любого сервера на JavaScript, который покажет
      примерное время пинга до сервера указанного в поле ввода.
      Технические требования:
      • стиль кнопок должен быть:
      бордер ровно 1пкс черный,
      фон кнопки серый,
      при
      наведении мыши на кнопку фон должен становится белым,
      при клике на кнопку фон
      должен становится желтым
      (использовать для этого только CSS / SCSS).
      • стиль полей ввода должен быть:
      бордер ровно 1пкс черный,
      фон белый,
      при наведении
      мыши на поле ввода фон должен становится серым,
      при клике на поле фон должен
      становится желтым
      (использовать для этого только CSS / SCSS)
      Задания делать на ReactJS.

    Visit original content creator repository

  • core

    SCINE – Core

    Introduction

    Core provides the functionality necessary to couple the individual SCINE
    modules together. It is vital for the correct functioning of all SCINE
    modules, but it does not directly provide any functionality for end users.
    Therefore, only developers of SCINE need to directly interact with Core.

    License and Copyright Information

    For license and copyright information, see the file LICENSE.txt in this
    directory.

    Installation and Usage

    As a user of one of the SCINE modules (such as Sparrow), you do not need
    to set up Core yourself. Instead, this is done as part of the installation
    process of the respective SCINE module. Therefore, the following instructions
    are only necessary for developers of SCINE, or those implementing the
    interfaces defined here.

    Dependencies

    Required software, minimum required versions in brackets, for this SCINE project are:
    • A C++ compiler supporting the C++17 standard
    • CMake (3.9)
    • Boost (1.65.0)

    Installation

    In order to compile this as a SCINE developer, execute the following
    commands:

    git submodule init
    git submodule update
    mkdir build
    cd build
    cmake -DCMAKE_BUILD_TYPE=Release -DCMAKE_INSTALL_PREFIX=../inst ..
    make -j 4
    make CoreDocumentation
    make test
    make install
    

    Usage

    The main usage guidelines can be found in the part of the developers documentation
    that is shared across all projects associated with SCINE.

    How to Cite

    When publishing results obtained with any SCINE module, please cite the following paper:

    T. Weymuth, J. P. Unsleber, P. L. Türtscher, M. Steiner, J.-G. Sobez, C. H. Müller, M. Mörchen,
    V. Klasovita, S. A. Grimmel, M. Eckhoff, K.-S. Csizi, F. Bosia, M. Bensberg, M. Reiher,
    “SCINE—Software for chemical interaction networks”, J. Chem. Phys., 2024, 160, 222501
    (DOI 10.1063/5.0206974).

    Support and Contact

    In case you should encounter problems or bugs, please write a short message
    to scine@phys.chem.ethz.ch.

    Third-Party Libraries Used

    SCINE Core makes use of the following third-party libraries:

    Visit original content creator repository