Giter Site home page Giter Site logo

web-project-base's Issues

Git policy enforcing hooks

As it was discussed in this issue (precisely this comment) it would be good to setup Git to enforce branches naming scheme to much the one we settled down in the above mentioned issue.

The task is more or less clear and this article might be a good starting point.

UPDATE: here is more verbose version of Git branches naming policy.

Minimal viable product

Here we will describe minimal set of features which we need, to call our base project ready for usage.

Application Architecture design

I'm going to create number of classes designed to standardize and simplify work with applications implementation. These classes are interfaces and helpers in the same time.

Client side Google and Facebook sdk integration

Google and Facebook provide their own js SDKs which integrate into app at run time which is not really nice, but logically there is no other option for them to keep them updated on the sites which use their SDKs. Due to such integration method we should create React components which will load them automatically.

Facebook and Google login

We need to start researching how to implement Facebook and Google login, because these two are most popular in the web. It's very important to have such functionality because we can use it as good selling point because Facebook and Google login allow easy user conversion which is very improtant for clients who want to develop popular service.

User-specific configuration for Vagrant boxes

Add support for user-specific configuration parameter for Vagrant development box. Details are in ./xopos/vagrant directory on ddnomad-ex branch).

Example of vagrant.yml config:

# -*- mode: yaml -*-
# vi: set ft=yaml sw=2 :
---
# TODO: it's an external ruby class that should process this file
# TODO: make sure it does not break Vagrant when it runs `box remove *`
default:
  # Vagrant specific settings
  # NOTE: readonly key
  vagrant:
    base_box: debian/stretch64
    vc_version: 2
    plugins: [ 'vagrant-vbguest' ]

  # Virtualbox properties
  virtualbox:
    name: vagrant_arachnid42_web-project-base_debian9
    cpus: 2
    cpu_cap: 100
    ram: 4096

  # Ansible provisioning properties
  # NOTE: readonly key
  ansible:
    compat_mode: '2.0'
    install_mode: 'pip'
    base_path: /vagrant/xopos/ansible
    playbook: vagrant.yml
    config: ansible.cfg

  # execute command for each SSH session
  ssh:
    # NOTE: readonly key
    path: /etc/profile.d/exec_on_ssh.sh
    # NOTE: append only key
    cmds:
      - cd /vagrant

  # what ports to forward to host
  # <guest_port>: <to_host_port>
  forward:
    8080: 8080  # flask
    9000: 9000  # webpack dev server

ddnomad:
  ssh:
    path: /stab  # NOTE: should be banned
    cmds:
      # shadow "- cd /vagrant" entry as append-only
      - set -o vi
      - bind -m vi-insert "\C-l":clear-screen

Auth0 thirdparty

https://auth0.com

I already created account for us, but I did not explore service abilities yet.

It's very possible that we'll use this service for thridparty login/sign up functionality

Nested forms implementation.

I managed to create good nested form basic functionality. Nested forms add their values to root form values[nestedFormName]object and save their statuses into root form status.form[nestedFormName] object.
Only problem which I found is dirtyFocusOnErrros and resetFocus method functionality. I was surprised when I found that my implementation can treat nested forms as fields, which is obvious because input and form data transferring API are almost identical, so I decided to fix focus behavior of the nested forms by providing them dirty and focus data from the parent form, which will be recorded to root form status.dirty and status.focus objects. I'm going to try just pass root form status.dirty[nestedFormName] && status.focus[nestedFormName] as dirtyFocusOnErrors property of the nested form. Another question is nested form focus reset, but I think I'll find some way to solve it.

[lilxop] Preparation of baseline functionality

Tasks to complete (from the most important to the least important):

  1. Implement indentation functionality for ./xopos/bash/utils/message.utils
    • Semantics should be like the following: set_indent [=-+][0-9]+
  2. Add support for compound options in resolver fixture in xop. It should be used in all subs then.
  3. Implement sub to install host dependencies for Debian-based and Arch distros. Dependencies are Vagrant and Virtualbox.
  4. Implement sub to add dependencies to ./xopos/ansible/requirements.txt
  5. Implement sub to add dependencies that can be installed with apt (Ansible)
  6. Implement sub-wrapper around vagrant.yml with an interactive guide
  7. Implement TODO sub: ./xop todo -u ddnomad find files with TODO[ddnomad]: in them. Possible support for external TODOs as well.

Working diaries.

Guys, we have one simple rule which applies to our working process. If you decided to work, you should leave the entry in your working diary. This diary is provided by slack bot "standup". This is particularly useful feature, because it gives me an ability to track you progress and working process in between issues which were assigned to you.

P.S.
It's better to start getting used today, then when we'll start working in real project you'll have well formed habit.

Branches naming scheme

I propose to introduce a fixed git branches naming scheme. It would make merging and overall developer interaction a little bit more intuitive. Moreover it would allow us to maintain more gradual access control across the whole repository (each developer has access only to <developer>-* branches of his own). Branches would be named like the following:

  • <developer>-exp - experimental features and proves of concept. Should not be merged into master or other upstream branches. Mostly serves as a stash for concept sketches and "maybe_implement" type of code.
  • <developer>-nightly - WIP branch where an actual development would take place. Should not be merged into master or other upstream branches.
  • <developer>-testing - testing branch where release candidate code is polished and prepared for merge with master or upstream branch.
  • <developer>-rc - release candidate branch. Could be reviewed by other developers to give feedback or help with a development (fork). Should not be merged into master or other upstream branches.
  • <developer>-stable - stable branch. Features that can be merged into master or upstream. The code is tested and is ready for merging into upstream.

In addition at least two "master" branches should exist:

  • testing - branch where merged across all <developer>-stable branches features are tested to make sure they work all together.
  • master - main branch where only tested, production grade code reside.

Each developer will go through at least <developer>-nightly -> <developer>-stable branches and then submit a pull request to testing. @Neketek then merge all stable branches into testing (or reject if needed) and all developer team makes sure testing branch behave as expected. If everything is working @Neketek then merge testing into master.

As a rare exception developers might create other branches though they must start with <developer>- prefix and developers themselves are responsible for deleting these branches afterwards. Generally, such behaviour is discouraged.

Thoughts?

Setup Slack integrations

We need to prepare Slack for organized crime development. Security policy and general configuration was already done by @ddnomad though we still need to add integrations and define channels that should be pre-created.

I propose the following channels list:

  • broadcast - team-wide announcements etc.
  • random - pretty self-descriptive
  • feed - updates from integrations (GitHub commits, ZenHub issues etc.)
  • reports - daily (and not only) reports from developers
  • server - back-end discussions
  • app - front-end and middle-end discussions
  • devops - DevOps, CI/CD discussions

This is not by any means a complete list but rather a starting point.

Integrations we would need (at least the most basic ones):

  • GitHub
  • ZenHub
  • Howdy or other standup meetings bot

Any thoughts/additions or critique?

Summarize Git branches naming scheme

Preferably in some sort of pseudo-regex form with an extended explanation.

@Neketek please let me know when you're done. I'll add your summary to "must read" in Slack so everybody will have an easy access to it.

Also Git enforcement policy will be set up by @vsmysle.

Landing design

We need to find good examples of the landings to which Martha can refer while she is designing landing for us.

I'm waiting for you suggestions in comments.

Starting the work.

Hi, my friends.

We want to create the base project which will help us to reduce the time required to start working with specific web projects.

There are three main elements of the web project which we need to do for any client who wants a project which targets wide audience.

Landing – simple react based application which users see when they land on the site domain.
Landing itself should not scare you at all, it’s very simple web application which primary functionality is a redirection of the users to login/sign-up functionality of the main application.

Main Application can be anything which soul and mind of client want. Its functionality and look highly depends on the demands of the client, but it has one part which we should save for future usage. It’s a login/sign-up functionality which we need to do as simple(from the user standpoint) as possible, but functionally rich: Facebook login/sign-up, Twitter login/sign-up, Google login/sign-up and native login/sign up.

Administrative Application is the application which we create to give clients the ability to work with user base and custom project data over which non administrative users have no direct control. Its functionality and look also depends on client requirements. But we can create nice looking common application which will allow clients to control user system which will be the part of the base project as well as the login/sign-up functionality which is the part of the project’s primary user system functionality.

Now, a little bit about current state of work.

Lets start from the simple things, my friends, from the landing.

As we all understand in landing implementation there is no role more important than a designer. So, our designer should start working with landing concept. Unfortunately while designer is working, no developer can do anything substantial with a landing, but we can and certainly should create the setup for the landing: base component and store.

Alexander and his girlfriend, Martha, will work on the landing conception together.

Story is same for the main application, it’s not designed yet. We’ll create the base elements:store connection, main component, but unlike with landing, we have a chance to experiment with front-end framework by creating dynamic forms. Unfortunately for you, my front-end friends, firstly I need to create base classes which will regulate the data flow in forms and inputs, but this does not mean, that you should do nothing while I’m working. As far as I know, Kiril and Vlad don’t have any valuable experience with react, so they should work hard to compensate this lack of experience as fast as possible, because in future and in real project we’ll not have time to stop and learn.

Administrative application are under the same circumstances as the main application, and I’m not able to tell a lot about it right now. Only thing which is valuable and which we know certainly that it should control things like manual verification of the email and cell phone tokens, it should give an ability to ban/remove users, change their passwords and lots of very little but important administrative moments.

P. S.

Personally I want to tell you one important thing. As a project manager I plan to use no one of you just like a coder. I need the people who can organize themselves, who don’t rely on the project manager in every organizational matter, who can find the task for themselves and start doing them after project manager confirmed, otherwise you’ll never develop skills which are required to lead a development process, which, I suppose, you want to do in the closest future. I hope you guys understand that we have the better chance of comfortable survival only if we work together, because we know each other a long time and we trust each other.

P. P. S.

I you don’t have the experience with something, don’t wait for my task to start working with that something, just learn. I have a lot work here which is mostly dedicated to conceptual matters, and all of my attention is concentrated there. Please, have an initiative, you are not at the enterprise vessel, for now we are small team who wants to grow and make some money.

Current 'lilxop' development plans [brainstorm]

  • Fix for Vagrant panic issue
  • Implementation of Git branches naming scheme enforcement rules
  • Add user-specific configuration overriding in vagrant.yml (see xopos/vagrant/ on ddnomad-ex branch)
  • Develop generic runner for lilxop including the following functionality (shell or python):
    • Wrapper around vagrant * that hides vagrant log output and saves log under ./log/vagrant_<up?>_<ts> (with option to preserve all Vagrant output)
    • Implement indentation functionality for message.util
    • Support for compound options in resolver in xop
    • Sub to install Vagrant and Virtualbox supporting debian-based and arch distros
    • TODO sub: ./xop todo -u ddnomad find files with TODO[ddnomad]: in them
    • sub to add deps to requirements.txt
    • sub to add apt-get deps to Vagrant box
    • sub wrapping around vagrant.yml (preferably with interactive guide)

Session login management

I need to create session login manager and possibly if needed, I should create the client session controller, to make client session operations not so plain.

"Vagrant box remove" panic with current config approach

Running vagrant box remove ubuntu/xenial64 --all breaks Vagrant. It complains about config files in each Vagrant-enabled projects (can't find config) due to a bug where Vagrant do not cd into a respective project directory.

There is a need to fix this issue by modifying Vagrantfile architecture.

Select customization for material-ui

https://codesandbox.io/s/py61x4kz3j
Here you can see example of the customization. Personally I don't really care about how it will be done because customization will be hidden in the wrapper class which is located in modules/common/input/select.jsx . You need to customize select in the same way as in the example and play wit it's possibilities. To avoid merge conflicts you can createdubbinary-app.jsx entry in the modules/app and configure your hot loader to use it.

Another variant is this library downshift
https://codesandbox.io/s/zrwr3y7m94

Application styles module system

Webpack provides styles name spacing which we can use to create style modules for separate components and components groups which will not interfere with global styles. This is extremely useful feature because it allows proper code separation, especially in styles.

To use such system we need to define general core styles which we can import directly to application root.
In case of specific components styling we should import css module directly to root of the component which we want to customize, because in such case webpack creates namespace for that css module.

But I need to check this functionality, because I have a feeling, that something may not work because of the text extract webpack plugin which extracts css into separate bundle when production config was used.

Implementing some input elements

Currently, i'm working on implementing some input elements such as Radio Box, Check Box and a special phone number input, which aims to represent a set of numbers in a human-readable format

Creation of the pencil document with all inputs.

Currently I'm using Pencil to create the sketches for the front-end interface, but we need some basic inputs to able to quickly create these sketches. Due to the fact that we are going to use material-ui in our base project, we'll need to copy their inputs.

  • Buttons - one of each type.
  • Labeled text input.
  • Check boxes.
  • Radio buttons.

I think it will be better if this components will be created using base shapes which Pencil provides.
I didn't try yet to use custom font for the labels but you should try.

Links
http://pencil.evolus.vn/
https://material-ui-next.com/demos/text-fields/

Shout out to those willing to do DevOps-related work

To cut on reading/writing time I'll go straight to the point. Currently we have the following DevOps-related functionality tied directly to web-project-base:

  • Vagrant box with a configuration that is currently necessary
  • lilxop shell-based subsystem that is much WIP as for now
  • Ansible tasks that are a pure ad-hoc right now

Shortcomings of an existing configuration:

  • Ad-hoc nature: extremely limited ways of modification that won't involve "skolenki" hacks
  • Devenv only: no deploy/test/monitor etc. functionality
  • Shell based: while shell script would be a nice starting point to allow for local modification of Ansible tasks and Vagrant properties we should not go shell way to the end (cause in the end there is death and suffering mostly)

We also have a tiny base project for what will become our main DevSecOps system at some point. It's a very ambitious project that will require a lot of attention and work buy hopefully will become a desiderata for our clients per se.

Now to all of you here: if you wish to do DevOps related work or at least orient in this field you have to > contact me in the following week. I won't have much of a time to help you later so I have to explain everything to you ASAP.

Micro-services bundle architecture in the server.

I need to create special functionality which will allow us to disable certain parts of server functionality via command line arguments or config, which will technically turn server into group of the micro services which can be deployed separately on different hosts and therefore improve performance by delegating computation powers much wisely than with monolith server type.

Database models configurable mixin class

I'm building configurable mixing class which will allow model building via inheritance.
Right now I'm trying to decide should it have multi column configuration functionality or not .

Base form tweaks

First thing which I want to add is simplified form.input render method which will render component with predefined name, value, onChange, onFocus, onBlur props, but without errors and field related props.

Also I probably will move label prop to predefined props of the form.field or form.input render methods.

UTC+0 timezone for servers

I suppose that we should use UTC+0 as server timezone,because it will allow "easy" handling of different time zones. @ddnomad Please, tell me when you can set server timezone to UTC+0, because soon in will become important for my future experiments.

Predefined sql queries

I need to think about creation of predefined SQL queries at the modules.modles.sql.
This should help us to not write duplicated queries and allow easy query consistency maintenance between controllers.

Upgrade to webpack 4.0

It seems that now we have new major version of webpack. I'll try to upgrade it because it seems that nothing substantial has changed.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.