class ClusterGraph |
Description
Used to contain clusters that are intended to be sorted. Clusters are sorted according to the cardinality of genes per cluster. For example, clusters with 12 genes will be grouped in an array together. The cardinality of that array determines the order in which these clusters appear. Since the matrix is sorted in ascending order, group 12 will appear after 10 and 11 due to its cluster cardinality. Such information is used later to be depicted in a visual graph.
Right now, a multidimensional array is used to do this, but it might be easier to use an insertion sort and apply the Observer pattern. This would require more classes, and I'm not sure I care that much.
An index is kept (a HASH
) to key the index (the indices of the cluster in the array storage) by a Gene.
EVERY gene will points to an index for a cluster.
Author: Leo Przybylski<EMAIL_ADDRESS>Default Constructor
Constructs the ClusterGraph
from its attributes.
None are required though.
Initiates an array as its data store and saves a reference to it.
Parameters
identity
- % Identity lower bound used for validationalignment
- Alignment length lower bound used for validation
Method add
Adds a Cluster
to the graph.
Sets the index to the last unoccupied index and records it in the index HASH
.
Finally,
the cluster is appended to the array store.
This is the only place where the size of the ClusterGraph
is incremented.
Parameters
Method addGene
Add an Gene
to a Cluster
in the ClusterGraph
.
First,
try to locate a Cluster
with the same query id as the Gene
to add.
Make sure that this cluster is also referenced by the subject/hit id.
If one cannot be found,
then instantiate one.
Parameters
Getter clusters
Getter for the the stored array of clusters.
clusters
is a read-only attribute.
Returns
Gets the reference to clusters
array.
Getter cluster
Getter for the the a specific cluster
by its index.
cluster
is a read-only attribute.
Returns
Gets the reference to clusters
array.
Getter/Setter identity
Getter for the the % identity lower bound.
Parameters
Returns
Gets the % identity lower bound
Getter/Setter alignment
Getter for the the % alignment lower bound.
Parameters
Returns
Gets the alignment length lower bound
Getter size
Returns
The number of Cluster
instances that are part of this ClusterGraph
Method graph
Creates a data structure that can be used by the GD::Graph
module.
Returns
A sorted 2-dimensional array of the data to be represented in a visual graph


{% extends 'base/base.html' %} {% block content %} {% if request.user.is_authenticated %}
Looks like you're already logged in as {{ request.user.username }}
click here to go back to account
if you would like to register a new account you must logout of this one first


This operation allows a patients address to be changed by an authorized user.
The operation is invoked against an instance of a Patient and takes in a single parameter which is a FHIR Address data type.
There is no return value - in the event of a failure, a 4xx status will be returned, along with an OperationOutcome resource that may provide further details about the failure.
If the user is not authorized to make the update, then a 403 status will be returned.
POST [host]/Patient/1234/$addressUpdate
(with the body as an Address object)
{
"use": "home",
"type": "both",
"text": "534 Erewhon St PeasantVille, Rainbow, Vic 3999",
"line": [
"534 Erewhon St"
],
"city": "PleasantVille",
"district": "Rainbow",
"state": "Vic",
"postalCode": "3999",
"period": {
"start": "1974-12-25"
}
}


We are offering the community two versions of the Florence proposal to choose between, one with Baking Accounts (as described below) and one without; we’ll explain the rationale for this decision later in this blog post.
Increased Maximum Operation Size: Previously, the maximum size of an operation was 16kB. In Florence, we propose to increase it to 32kB. Among other things, this has the effect of slightly more than doubling the maximum size of a smart contract, which should be of interest to some developers with particularly complicated applications.
Gas Optimizations: We have again reduced gas consumption in smart contract execution by increasing the efficiency of gas computation inside the Michelson interpreter. This allows for smart contracts with more complicated functionality to operate economically on the chain. We will continue to work on further efficiency improvements in coming versions of the protocol.
Baking Accounts:
Previously, token holders delegated to a baker by specifying that baker’s
public key hash. This meant that bakers could never change their public keys,
which was exceptionally inconvenient. The new “Baking Accounts” feature
alleviates this issue. In Florence, a new account type has been added to
represent accounts managed by bakers. These accounts are Michelson smart
contracts running a fixed multisig script. This feature lets bakers renew and
split their consensus keys without moving to a new address and asking their
delegators to follow. In addition to the usual internal operations, baking
accounts can also emit baking operations such as proposing and voting for
protocol amendments.
(The rights granted to the baking key (baking, endorsing, voting, and spending
the funds) remain unchanged. However, the system also allows a baker to vote
and access their funds using multisig authentication. Not using the baking key
for such tasks reduces the risk of it being exposed, and the baking key can
also be rotated in a worst case scenario.)
Although we strongly believe that Baking Accounts are an important new
addition to the Tezos protocol, and although we have made considerable effort
to make them backwards compatible with existing code, we recognize that client
libraries, wallets, indexers, and other software will require some work to
fully support Baking Accounts. We are thus providing the community with the
opportunity to decide for itself during the Proposal Period whether or not to
include this feature in the Florence update.
Depth First Execution Order: Previously, intercontract calls were executed in a so-called “breadth first” ordering. This was believed to be the correct choice when the Tezos protocol was initially designed, but it has turned out to significantly complicate the lives of smart contract developers. If Florence is adopted, the calling convention will change to a “depth first” execution order. This will make it far easier to reason about intercontract calls.
No More Test Chain: Previously, during the voting process, a test chain would be spun up during the “testing period” which took place between the exploration and promotion voting periods. The intent was that this test chain be used to assure that the new proposal worked correctly, but in practice, the test chain has never been used in this manner, and has caused significant operational problems to node operators. The new proposal eliminates the test chain activation; the testing period has been retained but is now named the “cooldown period”. Instead, we will continue to test the protocol using test chains that operate outside of the mainnet voting process.
This protocol amendment and the related updates to the Tezos shell were developed by programmers from Nomadic Labs, Metastate, DaiLambda, Marigold, Tarides, and an external contributor, Keefer Taylor 16, to whom the proposals grant an invoice of ꜩ100 to thank him for his merge request that increased the maximum operation size.


All Files (80.23% covered at 1.24 hits/line)
59 files in total.
440 relevant lines.
353 lines covered and
87 lines missed
# frozen_string_literal: true
- 1
class ApplicationController < ActionController::Base
- 1
before_action :authenticate_user!
- 1
before_action :configure_permitted_parameters, if: :devise_controller?
- 1
protected
- 1
def configure_permitted_parameters
devise_parameter_sanitizer.permit(:sign_up, keys: %i[first_name last_name email avatar address password])
end
end
# frozen_string_literal: true
- 1
class CommentsController < ApplicationController
- 1
before_action :find_post, only: %i[new create save_like]
- 1
def new
@comment = Comment.new
end
- 1
def create
@comment = @post.comments.create(comment_params)
@comment.user_id = current_user.id
@comment.save
if @comment.save
flash[:success] = 'Comments created successfully'
redirect_to post_path(@post)
else
flash[:danger] = 'Something went wrong'
render 'new'
end
end
- 1
def save_like
current_user.likes.build(post_id: @post.id)
if current_user.save
flash[:success] = 'you liked a post'
else
flash[:danger] = 'you have already liked this post'
end
redirect_to root_path
end
- 1
private
- 1
def find_post
@post = Post.friendly.find(params[:id])
end
- 1
def comment_params
params.require(:comment).permit(:body)
end
end
# frozen_string_literal: true
- 1
class HomesController < ApplicationController
- 1
def index
- 4
@posts = Post.includes(:user, :likes).all.order('created_at DESC')
end
end
# frozen_string_literal: true
- 1
class PostsController < ApplicationController
- 1
before_action :find_post, only: %i[edit update]
- 1
def index
@posts = Post.includes(:user, :likes).all.order('created_at DESC')
end
- 1
def new
@post = Post.new
end
- 1
def user_posts
@user = User.friendly.find(params[:id])
@posts = @user.posts.order('created_at DESC')
render 'index'
end
- 1
def show
@post = Post.includes(:comments).friendly.find(params[:id])
end
- 1
def create
@post = current_user.posts.build(post_params)
if @post.save
flash[:success] = 'Your post has created successfully'
redirect_to @post
else
flash[:danger] = 'Invalid post, Please try again!'
render 'new'
end
end
- 1
def edit; end
- 1
def update
if @post.update(post_params)
flash[:success] = 'post was successfully updated.'
redirect_to @post
else
flash[:danger] = 'Something went wrong, Please try again!'
render :edit
end
end
- 1
private
- 1
def find_post
@post = current_user.posts.friendly.find(params[:id])
end
- 1
def post_params
params.require(:post).permit(:description, :image)
end
end
# frozen_string_literal: true
- 1
class UsersController < ApplicationController
- 1
def index
@users = current_user.potential_friends(current_user)
end
- 1
def show
@user = User.friendly.find(params[:id])
end
- 1
def edit; end
end
# frozen_string_literal: true
- 1
module ApplicationHelper
- 1
def gravatar_for(user, size = 30)
gravatar_id = Digest::MD5.hexdigest(user.email.downcase)
gravater_url = "https://secure.gravatar.com/avatar/#{gravatar_id}?s=#{size}"
image_tag(gravater_url, alt: user.first_name, class: 'rounded-circle')
end
- 1
def name(user = nil)
if user
user.first_name.capitalize + ' ' + user.last_name.capitalize
else
current_user.first_name.capitalize + ' ' + current_user.last_name.capitalize
end
end
- 1
def post_owner(post)
post.user.first_name + ' ' + post.user.last_name
end
- 1
def profile_route
current_page?(user_path(:id))
end
end
# frozen_string_literal: true
- 1
module CommentsHelper
- 1
def comment_owner(user)
user.first_name + user.last_name
end
end
# frozen_string_literal: true
- 1
module FriendsHelper
end
# frozen_string_literal: true
- 1
module HomesHelper
- 1
def contains_image(post)
false unless post.image.valid?
true
end
end
# frozen_string_literal: true
- 1
module PostsHelper
- 1
def owner(post)
return true if current_user.id == post.user.id
false
end
end
# frozen_string_literal: true
- 1
module UsersHelper
- 1
def my_profile(user)
return true if current_user == user
false
end
end
# frozen_string_literal: true
- 1
class ApplicationRecord < ActiveRecord::Base
- 1
self.abstract_class = true
end
# frozen_string_literal: true
- 1
class Comment < ApplicationRecord
- 1
belongs_to :user
- 1
belongs_to :post
- 1
validates :body, presence: true
end
# frozen_string_literal: true
- 1
class Friendship < ApplicationRecord
- 1
belongs_to :user
- 1
belongs_to :friend, class_name: 'User'
end
# frozen_string_literal: true
- 1
class Like < ApplicationRecord
- 1
belongs_to :user
- 1
belongs_to :post
- 1
validates :user_id, presence: true
- 1
validates :post_id, presence: true
- 1
validates :user, uniqueness: { scope: :post }
end
# frozen_string_literal: true
- 1
class Post < ApplicationRecord
- 1
extend FriendlyId
- 1
friendly_id :truncated_name, use: :slugged
- 1
belongs_to :user
- 1
has_many :comments
- 1
has_many :likes
- 1
has_one_attached :image
- 1
validates :description, presence: true, length: { minimum: 5 }
- 1
def truncated_name
- 8
description.split[0..4].join(' ')
end
end
# frozen_string_literal: true
- 1
class User < ApplicationRecord
- 1
extend FriendlyId
- 1
friendly_id :name, use: :slugged
- 8
before_save { self.email = email.downcase }
- 1
VALID_EMAIL_REGEX =<EMAIL_ADDRESS># Include default devise modules. Others available are:
# :confirmable, :lockable, :timeoutable, :trackable and :omniauthable
- 1
devise :database_authenticatable, :registerable,
:recoverable, :rememberable, :validatable
- 1
validates :first_name, presence: true
- 1
validates :last_name, presence: true
- 1
validates :email, presence: true, length: { maximum: 255 },
format: { with: VALID_EMAIL_REGEX },
uniqueness: { case_sensitive: false }
- 1
has_many :posts, dependent: :destroy
- 1
has_many :comments, dependent: :destroy
- 1
has_many :likes, dependent: :destroy
- 1
has_many :friendships
- 1
has_many :inverse_friendships, class_name: 'Friendship', foreign_key: 'friend_id'
- 1
def name
[
- 36
%i[first_name last_name]
]
end
- 1
scope :all_except, ->(user) { where.not(id: user) }
- 1
def friends
friends_array = []
friendships.each { |friendship| friends_array << friendship.friend if friendship.comfirmed }
inverse_friendships.each { |friendship| friends_array << friendship.user if friendship.comfirmed }
friends_array.compact
end
- 1
def comfirm_friend(user)
friendship = inverse_friendships.find { |friend| friend.user == user }
friendship.comfirmed = true
friendship.save
end
- 1
def friend?(user)
friends.include?(user)
end
- 1
def pending_friends
friendships.map { |friendship| friendship.friend unless friendship.comfirmed }.compact
end
- 1
def friend_requests
inverse_friendships.map { |friendship| friendship.user unless friendship.comfirmed }.compact
end
- 1
def pending_friend?(user)
pending_friends.include?(user)
end
- 1
def potential_friends(current_user)
User.all.map { |user| user unless friend?(user) || current_user == user }.compact
end
end
- 1
require_relative 'boot'
- 1
require 'rails/all'
# Require the gems listed in Gemfile, including any gems
# you've limited to :test, :development, or :production.
- 1
Bundler.require(*Rails.groups)
- 1
module Facebok
- 1
class Application < Rails::Application
# Initialize configuration defaults for originally generated Rails version.
- 1
config.load_defaults 6.0
# Settings in config/environments/* take precedence over those specified here.
# Application configuration can go into files in config/initializers
# -- all .rb files in that directory are automatically loaded after loading
# the framework and any gems in your application.
end
end
- 1
ENV['BUNDLE_GEMFILE'] ||= File.expand_path('../Gemfile', __dir__)
- 1
require 'bundler/setup' # Set up gems listed in the Gemfile.
- 1
require 'bootsnap/setup' # Speed up boot time by caching expensive operations.
# Load the Rails application.
- 1
require_relative 'application'
# Initialize the Rails application.
- 1
Rails.application.initialize!
# The test environment is used exclusively to run your application's
# test suite. You never need to work with it otherwise. Remember that
# your test database is "scratch space" for the test suite and is wiped
# and recreated between test runs. Don't rely on the data there!
- 1
Rails.application.configure do
# Settings specified here will take precedence over those in config/application.rb.
- 1
config.cache_classes = false
# Do not eager load code on boot. This avoids loading your whole application
# just for the purpose of running a single test. If you are using a tool that
# preloads Rails for running tests, you may have to set it to true.
- 1
config.eager_load = false
# Configure public file server for tests with Cache-Control for performance.
- 1
config.public_file_server.enabled = true
- 1
config.public_file_server.headers = {
'Cache-Control' => "public, max-age=#{1.hour.to_i}"
}
# Show full error reports and disable caching.
- 1
config.consider_all_requests_local = true
- 1
config.action_controller.perform_caching = false
- 1
config.cache_store = :null_store
# Raise exceptions instead of rendering exception templates.
- 1
config.action_dispatch.show_exceptions = false
# Disable request forgery protection in test environment.
- 1
config.action_controller.allow_forgery_protection = false
# Store uploaded files on the local file system in a temporary directory.
- 1
config.active_storage.service = :test
- 1
config.action_mailer.perform_caching = false
# Tell Action Mailer not to deliver emails to the real world.
# The :test delivery method accumulates sent emails in the
# ActionMailer::Base.deliveries array.
- 1
config.action_mailer.delivery_method = :test
# Print deprecation notices to the stderr.
- 1
config.active_support.deprecation = :stderr
# Raises error for missing translations.
# config.action_view.raise_on_missing_translations = true
end
# Be sure to restart your server when you modify this file.
# ActiveSupport::Reloader.to_prepare do
# ApplicationController.renderer.defaults.merge!(
# http_host: 'example.org',
# https: false
# )
# end
# Be sure to restart your server when you modify this file.
# Version of your assets, change this if you want to expire all your assets.
- 1
Rails.application.config.assets.version = '1.0'
# Add additional assets to the asset load path.
# Rails.application.config.assets.paths << Emoji.images_path
# Add Yarn node_modules folder to the asset load path.
- 1
Rails.application.config.assets.paths << Rails.root.join('node_modules')
# Precompile additional assets.
# application.js, application.css, and all non-JS/CSS in the app/assets
# folder are already added.
# Rails.application.config.assets.precompile += %w( admin.js admin.css )
# Be sure to restart your server when you modify this file.
# You can add backtrace silencers for libraries that you're using but don't wish to see in your backtraces.
# Rails.backtrace_cleaner.add_silencer { |line| line =~ /my_noisy_library/ }
# You can also remove all the silencers if you're trying to debug a problem that might stem from framework code.
# Rails.backtrace_cleaner.remove_silencers!
# Be sure to restart your server when you modify this file.
# Define an application-wide content security policy
# For further information see the following documentation
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy
# Rails.application.config.content_security_policy do |policy|
# policy.default_src :self, :https
# policy.font_src :self, :https, :data
# policy.img_src :self, :https, :data
# policy.object_src :none
# policy.script_src :self, :https
# policy.style_src :self, :https
# # If you are using webpack-dev-server then specify webpack-dev-server host
# policy.connect_src :self, :https, "http://localhost:3035", "ws://localhost:3035" if Rails.env.development?
# # Specify URI for violation reports
# # policy.report_uri "/csp-violation-report-endpoint"
# end
# If you are using UJS then enable automatic nonce generation
# Rails.application.config.content_security_policy_nonce_generator = -> request { SecureRandom.base64(16) }
# Set the nonce only to specific directives
# Rails.application.config.content_security_policy_nonce_directives = %w(script-src)
# Report CSP violations to a specified URI
# For further information see the following documentation:
# https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy-Report-Only
# Rails.application.config.content_security_policy_report_only = true
# Be sure to restart your server when you modify this file.
# Specify a serializer for the signed and encrypted cookie jars.
# Valid options are :json, :marshal, and :hybrid.
- 1
Rails.application.config.action_dispatch.cookies_serializer = :json
# frozen_string_literal: true
# Use this hook to configure devise mailer, warden hooks and so forth.
# Many of these configuration options can be set straight in your model.
- 1
Devise.setup do |config|
# The secret key used by Devise. Devise uses this key to generate
# random tokens. Changing this key will render invalid all existing
# confirmation, reset password and unlock tokens in the database.
# Devise will use the `secret_key_base` as its `secret_key`
# by default. You can change it below and use your own secret key.
# config.secret_key = '225543f7336cd28ede848f2bb990e12d71c8b7136daf7206db665325ce0c520290ca6784bc7a7e7bc48fd7a87dd9f6e2afeb4fc8f2b75a91bbf0b6d3bd1f9d37'
# ==> Controller configuration
# Configure the parent class to the devise controllers.
# config.parent_controller = 'DeviseController'
# ==> Mailer Configuration
# Configure the e-mail address which will be shown in Devise::Mailer,
# note that it will be overwritten if you use your own mailer class
# with default "from" parameter.
- 1
config.mailer_sender =<EMAIL_ADDRESS># Configure the class responsible to send e-mails.
- 1
config.mailer = 'Devise::Mailer'
# Configure the parent class responsible to send e-mails.
# config.parent_mailer = 'ActionMailer::Base'
# ==> ORM configuration
# Load and configure the ORM. Supports :active_record (default) and
# :mongoid (bson_ext recommended) by default. Other ORMs may be
# available as additional gems.
- 1
require 'devise/orm/active_record'
# ==> Configuration for any authentication mechanism
# Configure which keys are used when authenticating a user. The default is
# just :email. You can configure it to use [:username, :subdomain], so for
# authenticating a user, both parameters are required. Remember that those
# parameters are used only when authenticating and not when retrieving from
# session. If you need permissions, you should implement that in a before filter.
# You can also supply a hash where the value is a boolean determining whether
# or not authentication should be aborted when the value is not present.
# config.authentication_keys = [:email]
# Configure parameters from the request object used for authentication. Each entry
# given should be a request method and it will automatically be passed to the
# find_for_authentication method and considered in your model lookup. For instance,
# if you set :request_keys to [:subdomain], :subdomain will be used on authentication.
# The same considerations mentioned for authentication_keys also apply to request_keys.
# config.request_keys = []
# Configure which authentication keys should be case-insensitive.
# These keys will be downcased upon creating or modifying a user and when used
# to authenticate or find a user. Default is :email.
- 1
config.case_insensitive_keys = [:email]
# Configure which authentication keys should have whitespace stripped.
# These keys will have whitespace before and after removed upon creating or
# modifying a user and when used to authenticate or find a user. Default is :email.
- 1
config.strip_whitespace_keys = [:email]
# Tell if authentication through request.params is enabled. True by default.
# It can be set to an array that will enable params authentication only for the
# given strategies, for example, `config.params_authenticatable = [:database]` will
# enable it only for database (email + password) authentication.
# config.params_authenticatable = true
# Tell if authentication through HTTP Auth is enabled. False by default.
# It can be set to an array that will enable http authentication only for the
# given strategies, for example, `config.http_authenticatable = [:database]` will
# enable it only for database authentication. The supported strategies are:
# :database = Support basic authentication with authentication key + password
# config.http_authenticatable = false
# If 401 status code should be returned for AJAX requests. True by default.
# config.http_authenticatable_on_xhr = true
# The realm used in Http Basic Authentication. 'Application' by default.
# config.http_authentication_realm = 'Application'
# It will change confirmation, password recovery and other workflows
# to behave the same regardless if the e-mail provided was right or wrong.
# Does not affect registerable.
# config.paranoid = true
# By default Devise will store the user in session. You can skip storage for
# particular strategies by setting this option.
# Notice that if you are skipping storage for all authentication paths, you
# may want to disable generating routes to Devise's sessions controller by
# passing skip: :sessions to `devise_for` in your config/routes.rb
- 1
config.skip_session_storage = [:http_auth]
# By default, Devise cleans up the CSRF token on authentication to
# avoid CSRF token fixation attacks. This means that, when using AJAX
# requests for sign in and sign up, you need to get a new CSRF token
# from the server. You can disable this option at your own risk.
# config.clean_up_csrf_token_on_authentication = true
# When false, Devise will not attempt to reload routes on eager load.
# This can reduce the time taken to boot the app but if your application
# requires the Devise mappings to be loaded during boot time the application
# won't boot properly.
# config.reload_routes = true
# ==> Configuration for :database_authenticatable
# For bcrypt, this is the cost for hashing the password and defaults to 11. If
# using other algorithms, it sets how many times you want the password to be hashed.
#
# Limiting the stretches to just one in testing will increase the performance of
# your test suite dramatically. However, it is STRONGLY RECOMMENDED to not use
# a value less than 10 in other environments. Note that, for bcrypt (the default
# algorithm), the cost increases exponentially with the number of stretches (e.g.
# a value of 20 is already extremely slow: approx. 60 seconds for 1 calculation).
- 1
config.stretches = Rails.env.test? ? 1 : 11
# Set up a pepper to generate the hashed password.
# config.pepper = 'f36bb52504fbbe251484d2f6c2839311d9baf39a8fe715070a456cca44a130a98a581af9ad05e4b71a1275e2c4f1fc1e6ca1a3fa5a1efb1551d566bf013476c0'
# Send a notification to the original email when the user's email is changed.
# config.send_email_changed_notification = false
# Send a notification email when the user's password is changed.
# config.send_password_change_notification = false
# ==> Configuration for :confirmable
# A period that the user is allowed to access the website even without
# confirming their account. For instance, if set to 2.days, the user will be
# able to access the website for two days without confirming their account,
# access will be blocked just in the third day.
# You can also set it to nil, which will allow the user to access the website
# without confirming their account.
# Default is 0.days, meaning the user cannot access the website without
# confirming their account.
# config.allow_unconfirmed_access_for = 2.days
# A period that the user is allowed to confirm their account before their
# token becomes invalid. For example, if set to 3.days, the user can confirm
# their account within 3 days after the mail was sent, but on the fourth day
# their account can't be confirmed with the token any more.
# Default is nil, meaning there is no restriction on how long a user can take
# before confirming their account.
# config.confirm_within = 3.days
# If true, requires any email changes to be confirmed (exactly the same way as
# initial account confirmation) to be applied. Requires additional unconfirmed_email
# db field (see migrations). Until confirmed, new email is stored in
# unconfirmed_email column, and copied to email column on successful confirmation.
- 1
config.reconfirmable = true
# Defines which key will be used when confirming an account
# config.confirmation_keys = [:email]
# ==> Configuration for :rememberable
# The time the user will be remembered without asking for credentials again.
# config.remember_for = 2.weeks
# Invalidates all the remember me tokens when the user signs out.
- 1
config.expire_all_remember_me_on_sign_out = true
# If true, extends the user's remember period when remembered via cookie.
# config.extend_remember_period = false
# Options to be passed to the created cookie. For instance, you can set
# secure: true in order to force SSL only cookies.
# config.rememberable_options = {}
# ==> Configuration for :validatable
# Range for password length.
- 1
config.password_length = 6..128
# Email regex used to validate email formats. It simply asserts that
# one (and only one) @ exists in the given string. This is mainly
# to give user feedback and not to assert the e-mail validity.
- 1
config.email_regexp = /\A[^@\s]+@[^@\s]+\z/
# ==> Configuration for :timeoutable
# The time you want to timeout the user session without activity. After this
# time the user will be asked for credentials again. Default is 30 minutes.
# config.timeout_in = 30.minutes
# ==> Configuration for :lockable
# Defines which strategy will be used to lock an account.
# :failed_attempts = Locks an account after a number of failed attempts to sign in.
# :none = No lock strategy. You should handle locking by yourself.
# config.lock_strategy = :failed_attempts
# Defines which key will be used when locking and unlocking an account
# config.unlock_keys = [:email]
# Defines which strategy will be used to unlock an account.
# :email = Sends an unlock link to the user email
# :time = Re-enables login after a certain amount of time (see :unlock_in below)
# :both = Enables both strategies
# :none = No unlock strategy. You should handle unlocking by yourself.
# config.unlock_strategy = :both
# Number of authentication tries before locking an account if lock_strategy
# is failed attempts.
# config.maximum_attempts = 20
# Time interval to unlock the account if :time is enabled as unlock_strategy.
# config.unlock_in = 1.hour
# Warn on the last attempt before the account is locked.
# config.last_attempt_warning = true
# ==> Configuration for :recoverable
#
# Defines which key will be used when recovering the password for an account
# config.reset_password_keys = [:email]
# Time interval you can reset your password with a reset password key.
# Don't put a too small interval or your users won't have the time to
# change their passwords.
- 1
config.reset_password_within = 6.hours
# When set to false, does not sign a user in automatically after their password is
# reset. Defaults to true, so a user is signed in automatically after a reset.
# config.sign_in_after_reset_password = true
# ==> Configuration for :encryptable
# Allow you to use another hashing or encryption algorithm besides bcrypt (default).
# You can use :sha1, :sha512 or algorithms from others authentication tools as
# :clearance_sha1, :authlogic_sha512 (then you should set stretches above to 20
# for default behavior) and :restful_authentication_sha1 (then you should set
# stretches to 10, and copy REST_AUTH_SITE_KEY to pepper).
#
# Require the `devise-encryptable` gem when using anything other than bcrypt
# config.encryptor = :sha512
# ==> Scopes configuration
# Turn scoped views on. Before rendering "sessions/new", it will first check for
# "users/sessions/new". It's turned off by default because it's slower if you
# are using only default views.
# config.scoped_views = false
# Configure the default scope given to Warden. By default it's the first
# devise role declared in your routes (usually :user).
# config.default_scope = :user
# Set this configuration to false if you want /users/sign_out to sign out
# only the current scope. By default, Devise signs out all scopes.
# config.sign_out_all_scopes = true
# ==> Navigation configuration
# Lists the formats that should be treated as navigational. Formats like
# :html, should redirect to the sign in page when the user does not have
# access, but formats like :xml or :json, should return 401.
#
# If you have any extra navigational formats, like :iphone or :mobile, you
# should add them to the navigational formats lists.
#
# The "*/*" below is required to match Internet Explorer requests.
# config.navigational_formats = ['*/*', :html]
# The default HTTP method used to sign out a resource. Default is :delete.
- 1
config.sign_out_via = :delete
# ==> OmniAuth
# Add a new OmniAuth provider. Check the wiki for more information on setting
# up on your models and hooks.
# config.omniauth :github, 'APP_ID', 'APP_SECRET', scope: 'user,public_repo'
# ==> Warden configuration
# If you want to use other strategies, that are not supported by Devise, or
# change the failure app, you can configure them inside the config.warden block.
#
# config.warden do |manager|
# manager.intercept_401 = false
# manager.default_strategies(scope: :user).unshift :some_external_strategy
# end
# ==> Mountable engine configurations
# When using Devise inside an engine, let's call it `MyEngine`, and this engine
# is mountable, there are some extra configurations to be taken into account.
# The following options are available, assuming the engine is mounted as:
#
# mount MyEngine, at: '/my_engine'
#
# The router that invoked `devise_for`, in the example above, would be:
# config.router_name = :my_engine
#
# When using OmniAuth, Devise cannot automatically set OmniAuth path,
# so you need to do it manually. For the users scope, it would be:
# config.omniauth_path_prefix = '/my_engine/users/auth'
# ==> Turbolinks configuration
# If your app is using Turbolinks, Turbolinks::Controller needs to be included to make redirection work correctly:
#
# ActiveSupport.on_load(:devise_failure_app) do
# include Turbolinks::Controller
# end
# ==> Configuration for :registerable
# When set to false, does not sign a user in automatically after their password is
# changed. Defaults to true, so a user is signed in automatically after changing a password.
# config.sign_in_after_change_password = true
end
# Be sure to restart your server when you modify this file.
# Configure sensitive parameters which will be filtered from the log file.
- 1
Rails.application.config.filter_parameters += [:password]
# FriendlyId Global Configuration
#
# Use this to set up shared configuration options for your entire application.
# Any of the configuration options shown here can also be applied to single
# models by passing arguments to the `friendly_id` class method or defining
# methods in your model.
#
# To learn more, check out the guide:
#
# http://norman.github.io/friendly_id/file.Guide.html
- 1
FriendlyId.defaults do |config|
# ## Reserved Words
#
# Some words could conflict with Rails's routes when used as slugs, or are
# undesirable to allow as slugs. Edit this list as needed for your app.
- 2
config.use :reserved
- 2
config.reserved_words = %w(new edit index session login logout users admin
stylesheets assets javascripts images)
# This adds an option to treat reserved words as conflicts rather than exceptions.
# When there is no good candidate, a UUID will be appended, matching the existing
# conflict behavior.
# config.treat_reserved_as_conflict = true
# ## Friendly Finders
#
# Uncomment this to use friendly finders in all models. By default, if
# you wish to find a record by its friendly id, you must do:
#
# MyModel.friendly.find('foo')
#
# If you uncomment this, you can do:
#
# MyModel.find('foo')
#
# This is significantly more convenient but may not be appropriate for
# all applications, so you must explicity opt-in to this behavior. You can
# always also configure it on a per-model basis if you prefer.
#
# Something else to consider is that using the :finders addon boosts
# performance because it will avoid Rails-internal code that makes runtime
# calls to `Module.extend`.
#
# config.use :finders
#
# ## Slugs
#
# Most applications will use the :slugged module everywhere. If you wish
# to do so, uncomment the following line.
#
# config.use :slugged
#
# By default, FriendlyId's :slugged addon expects the slug column to be named
# 'slug', but you can change it if you wish.
#
# config.slug_column = 'slug'
#
# By default, slug has no size limit, but you can change it if you wish.
#
# config.slug_limit = 255
#
# When FriendlyId can not generate a unique ID from your base method, it appends
# a UUID, separated by a single dash. You can configure the character used as the
# separator. If you're upgrading from FriendlyId 4, you may wish to replace this
# with two dashes.
#
# config.sequence_separator = '-'
#
# Note that you must use the :slugged addon **prior** to the line which
# configures the sequence separator, or else FriendlyId will raise an undefined
# method error.
#
# ## Tips and Tricks
#
# ### Controlling when slugs are generated
#
# As of FriendlyId 5.0, new slugs are generated only when the slug field is
# nil, but if you're using a column as your base method can change this
# behavior by overriding the `should_generate_new_friendly_id?` method that
# FriendlyId adds to your model. The change below makes FriendlyId 5.0 behave
# more like 4.0.
# Note: Use(include) Slugged module in the config if using the anonymous module.
# If you have `friendly_id :name, use: slugged` in the model, Slugged module
# is included after the anonymous module defined in the initializer, so it
# overrides the `should_generate_new_friendly_id?` method from the anonymous module.
#
# config.use :slugged
# config.use Module.new {
# def should_generate_new_friendly_id?
# slug.blank? || <your_column_name_here>_changed?
# end
# }
#
# FriendlyId uses Rails's `parameterize` method to generate slugs, but for
# languages that don't use the Roman alphabet, that's not usually sufficient.
# Here we use the Babosa library to transliterate Russian Cyrillic slugs to
# ASCII. If you use this, don't forget to add "babosa" to your Gemfile.
#
# config.use Module.new {
# def normalize_friendly_id(text)
# text.to_slug.normalize! :transliterations => [:russian, :latin]
# end
# }
end
# Be sure to restart your server when you modify this file.
# Add new inflection rules using the following format. Inflections
# are locale specific, and you may define rules for as many different
# locales as you wish. All of these examples are active by default:
# ActiveSupport::Inflector.inflections(:en) do |inflect|
# inflect.plural /^(ox)$/i, '\1en'
# inflect.singular /^(ox)en/i, '\1'
# inflect.irregular 'person', 'people'
# inflect.uncountable %w( fish sheep )
# end
# These inflection rules are supported but not enabled by default:
# ActiveSupport::Inflector.inflections(:en) do |inflect|
# inflect.acronym 'RESTful'
# end
# Be sure to restart your server when you modify this file.
# Add new mime types for use in respond_to blocks:
# Mime::Type.register "text/richtext", :rtf
# Be sure to restart your server when you modify this file.
# This file contains settings for ActionController::ParamsWrapper which
# is enabled by default.
# Enable parameter wrapping for JSON. You can disable this by setting :format to an empty array.
- 1
ActiveSupport.on_load(:action_controller) do
- 2
wrap_parameters format: [:json]
end
# To enable root element in JSON for ActiveRecord objects.
# ActiveSupport.on_load(:active_record) do
# self.include_root_in_json = true
# end
# frozen_string_literal: true
- 1
Rails.application.routes.draw do
- 1
root to: 'homes#index'
- 1
get '/user-post/:id', to: 'posts#user_posts', as: :user_post
- 1
get 'like/:id', to: 'comments#save_like', as: :like
- 1
get 'comment/:id', to: 'comments#new', as: :new_comment
- 1
post 'comment/:id', to: 'comments#create', as: :comments
- 1
get 'friends/:id', to: 'friends#friends', as: :friends
- 1
get 'pending-friends/:id', to: 'friends#pending_friends', as: :pending_friends
- 1
get 'request-friendship/:id', to: 'friends#create', as: :request_friend
- 1
get 'friend-requests', to: 'friends#friend_requests', as: :friend_request
- 1
get 'accept-friendship/:id', to: 'friends#accept_friend', as: :accept_friend
- 1
devise_for :users, skip: [:sessions]
- 1
as :user do
- 1
get 'login', to: 'devise/sessions#new', as: :new_user_session
- 1
post 'login', to: 'devise/sessions#create', as: :user_session
- 1
delete 'logout', to: 'devise/sessions#destroy', as: :destroy_user_session
- 1
get 'signup', to: 'devise/registrations#new', as: :new_user
end
- 1
resources :posts
- 1
resources :users, only: [:index, :show]
end
- 1
Spring.watch(
".ruby-version",
".rbenv-vars",
"tmp/restart.txt",
"tmp/caching-dev.txt"
)
# frozen_string_literal: true
- 1
require 'rails_helper'
- 1
RSpec.describe CommentsController, type: :controller do
- 1
describe 'create new comment' do
- 1
context 'when comment creation succeeds' do
- 1
it 'creates comment with body' do
- 1
user = FactoryBot.create(:user)
- 1
post = user.posts.create(description: 'This is the comment')
params = {
- 1
body: 'This is the comment',
user_id: user.id
}
- 1
expect do
- 1
post.comments.create(params)
end.to change(Comment, :count).by(1)
end
end
- 1
context 'when comment creation fails' do
- 1
it 'should not create comment without body' do
- 1
user = FactoryBot.create(:user)
- 1
post = user.posts.create(description: 'This is the comment')
params = {
- 1
body: nil,
user_id: user.id
}
- 1
expect do
- 1
post.comments.create(params)
end.to_not change(Comment, :count)
end
end
end
end
# frozen_string_literal: true
# # frozen_string_literal: true
# require 'rails_helper'
# RSpec.describe FriendsController, type: :controller do
# end
# frozen_string_literal: true
- 1
require 'rails_helper'
- 1
RSpec.describe HomesController, type: :controller do
- 1
describe 'GET #index' do
- 5
let(:user) { FactoryBot.create(:user) }
- 1
context 'when user is logged in' do
- 1
before do
- 4
sign_in user
- 4
get :index
end
- 1
it 'responds successfully' do
- 1
expect(response).to be_successful
end
- 1
it 'responds with 200' do
- 1
expect(response).to have_http_status(200)
end
- 1
it 'renders index page' do
- 1
expect(response).to render_template(:index)
end
- 1
it 'does not respond with 404' do
- 1
expect(response).to_not have_http_status(404)
end
end
- 1
context 'when user is not logged in' do
- 1
it 'renders new' do
- 1
get :index
- 1
expect(response).to have_http_status(:redirect)
end
end
end
end
# frozen_string_literal: true
# # frozen_string_literal: true
# require 'rails_helper'
# RSpec.describe LikesController, type: :controller do
# describe 'Like post' do
# context 'when post like succeeds' do
# it 'should increase likes on post' do
# user = FactoryBot.create(:user)
# post = user.posts.create(description: 'This is the comment')
# params = {
# user_id: user.id
# }
# expect do
# post.likes.create(params)
# end.to change(Like, :count).by(1)
# end
# end
# end
# end
# frozen_string_literal: true
- 1
require 'rails_helper'
- 1
RSpec.describe PostsController, type: :controller do
- 1
describe 'GET #index' do
- 1
it 'returns http redirect' do
- 1
get :index
- 1
expect(response).to have_http_status(302)
end
end
end
# frozen_string_literal: true
- 1
require 'rails_helper'
- 1
require_relative '../support/devise'
- 1
RSpec.describe UsersController do
- 1
describe 'authenticated access' do
- 1
login_user
- 1
it 'should have a current_user' do
- 1
expect(subject.current_user).to_not eq(nil)
end
end
- 1
describe 'unauthenticated access' do
- 1
it 'should not have a current_user' do
- 1
expect(subject.current_user).to eq(nil)
end
- 1
it 'should not get index' do
- 1
get :index
- 1
expect(response).to redirect_to(new_user_session_path)
end
- 1
it 'should not get show' do
- 1
get :show, params: { id: :user }
- 1
expect(response).to redirect_to(new_user_session_path)
end
end
end
# frozen_string_literal: true
- 1
FactoryBot.define do
- 1
factory :comment do
- 4
body { Faker::Lorem.paragraph }
- 1
association :user, factory: :user
- 1
association :post, factory: :post
end
end
# frozen_string_literal: true
- 1
FactoryBot.define do
- 1
factory :friendship do
- 1
user { nil }
- 1
friend { nil }
- 1
confirmed { false }
end
end
# frozen_string_literal: true
- 1
FactoryBot.define do
- 1
factory :like do
- 1
association :user, factory: :user
- 1
association :post, factory: :post
end
end
# frozen_string_literal: true
- 1
FactoryBot.define do
- 1
factory :post do
- 6
description { Faker::Lorem.paragraph }
- 1
association :user, factory: :user
end
end
# frozen_string_literal: true
- 1
FactoryBot.define do
- 1
factory :user do
- 21
first_name { Faker::Name.first_name }
- 21
last_name { Faker::Name.last_name }
- 21
email { Faker::Internet.email }
- 21
address { Faker::Address.street_address }
- 21
password { Faker::Internet.password }
end
end
# frozen_string_literal: true
- 1
require 'rails_helper'
- 1
RSpec.describe 'homepage;' do
- 1
let(:new_user) { FactoryBot.create(:user) }
- 1
def fill_in_login_detials
visit(root_path)
within 'form.form-inline' do
fill_in 'user[email]', with: new_user.email
fill_in 'user[password]', with: new_user.password
click_button 'Log In'
end
end
end
# frozen_string_literal: true
- 1
require 'rails_helper'
- 1
RSpec.describe 'Users' do
- 1
let(:returning_user) { FactoryBot.create(:user) }
- 1
let(:factory_post) { FactoryBot.create(:post) }
- 1
def new_user
{
first_name: Faker::Name.first_name,
last_name: Faker::Name.last_name,
email: Faker::Internet.email,
address: Faker::Address.street_address,
password: Faker::Internet.password
}
end
- 1
def signup(new_user)
within '.new_user' do
fill_in 'user[first_name]', with: new_user[:first_name]
fill_in 'user[last_name]', with: new_user[:last_name]
fill_in 'user[email]', with: new_user[:email]
fill_in 'user[address]', with: new_user[:address]
fill_in 'user[password]', with: new_user[:password]
click_button 'Sign up'
end
end
- 1
def login(user)
within 'form.form-inline' do
fill_in 'user[email]', with: user.email
fill_in 'user[password]', with: user.password
click_button 'Log in'
end
end
- 1
def create_post(description, image)
fill_in 'post[description]', with: description
fill_in 'post[image]', with: image
click_button 'Create'
end
end
# frozen_string_literal: true
# require 'rails_helper'
# Specs in this file have access to a helper object that includes
# the CommentsHelper. For example:
# describe CommentsHelper do
# describe "string concat" do
# it "concats two strings with spaces" do
# expect(helper.concat_strings("this","that")).to eq("this that")
# end
# end
# end
# RSpec.describe CommentsHelper, type: :helper do
# pending "add some examples to (or delete) #{__FILE__}"
# end
# RSpec.describe CommentsHelper, type: :helper do
# pending "add some examples to (or delete) #{__FILE__}"
# end
# frozen_string_literal: true
- 1
require 'rails_helper'
# Specs in this file have access to a helper object that includes
# the FriendsHelper. For example:
#
# describe FriendsHelper do
# describe "string concat" do
# it "concats two strings with spaces" do
# expect(helper.concat_strings("this","that")).to eq("this that")
# end
# end
# end
# RSpec.describe FriendsHelper, type: :helper do
# pending "add some examples to (or delete) #{__FILE__}"
# end
# frozen_string_literal: true
- 1
require 'rails_helper'
- 1
RSpec.describe Comment, type: :model do
- 4
let(:comment) { FactoryBot.build(:comment) }
- 1
describe 'validations' do
- 2
it { is_expected.to validate_presence_of(:body) }
end
- 1
describe 'associations' do
- 2
it { should belong_to(:user) }
- 2
it { should belong_to(:post) }
end
- 1
it 'is a valid comment' do
- 1
expect(comment).to be_valid
end
- 1
it 'is invalid when comment does not contain body' do
- 1
comment.body = ''
- 1
expect(comment).not_to be_valid
end
- 1
it 'is valid when comment contains body' do
- 1
comment.body = 'Nice work'
- 1
expect(comment).to be_valid
end
end
# frozen_string_literal: true
- 1
require 'rails_helper'
- 1
RSpec.describe Friendship, type: :model do
- 1
let(:friendship) { FactoryBot.build(:friendship) }
- 1
describe 'associations' do
- 2
it { should belong_to(:user) }
- 2
it { should belong_to(:friend) }
end
end
# frozen_string_literal: true
- 1
require 'rails_helper'
- 1
RSpec.describe Like, type: :model do
- 1
let(:like) { FactoryBot.build(:like) }
- 1
describe 'associations' do
- 2
it { should belong_to(:user) }
- 2
it { should belong_to(:post) }
end
end
# frozen_string_literal: true
- 1
require 'rails_helper'
- 1
RSpec.describe Post, type: :model do
- 3
let(:post) { FactoryBot.build(:post) }
- 1
describe 'association' do
- 2
it { belong_to(:user) }
end
- 1
it 'is valid post if it has at least five character length content' do
- 1
expect(post).to be_valid
end
- 1
it 'is invalid post if it does not have content' do
- 1
post.description = ''
- 1
expect(post).not_to be_valid
end
end
# frozen_string_literal: true
- 1
require 'rails_helper'
- 1
RSpec.describe User, type: :model do
- 6
let(:new_user) { FactoryBot.build(:user) }
- 1
describe 'validations' do
- 2
it { is_expected.to validate_presence_of(:first_name) }
- 2
it { is_expected.to validate_presence_of(:last_name) }
- 2
it { is_expected.to validate_presence_of(:email) }
end
- 1
describe 'associations' do
- 2
it { have_many(:posts) }
end
- 1
it 'is a valid user' do
- 1
expect(new_user).to be_valid
end
- 1
it 'is invalid when user does not provide first name' do
- 1
new_user.first_name = ''
- 1
expect(new_user).not_to be_valid
end
- 1
it 'is invalid when user does not provide last name' do
- 1
new_user.last_name = ''
- 1
expect(new_user).not_to be_valid
end
- 1
it 'is invalid when user does not provide email' do
- 1
new_user.email = ''
- 1
expect(new_user).not_to be_valid
end
- 1
it 'requires the email address to look like an email' do
- 1
new_user.email = 'jboltik'
- 1
expect(new_user).to_not be_valid
end
end
# frozen_string_literal: true
# This file is copied to spec/ when you run 'rails generate rspec:install'
- 1
require 'spec_helper'
- 1
ENV['RAILS_ENV'] ||= 'test'
- 1
require File.expand_path('../config/environment', __dir__)
# Prevent database truncation if the environment is production
- 1
abort('The Rails environment is running in production mode!') if Rails.env.production?
- 1
require 'rspec/rails'
- 1
require 'shoulda/matchers'
- 1
require 'capybara/rspec'
- 1
require 'capybara/rails'
- 1
require 'devise'
- 1
require 'database_cleaner'
# Add additional requires below this line. Rails is not loaded until this point!
# Requires supporting ruby files with custom matchers and macros, etc, in
# spec/support/ and its subdirectories. Files matching `spec/**/*_spec.rb` are
# run as spec files by default. This means that files in spec/support that end
# in _spec.rb will both be required and run as specs, causing the specs to be
# run twice. It is recommended that you do not name files matching this glob to
# end with _spec.rb. You can configure this pattern with the --pattern
# option on the command line or in ~/.rspec, .rspec or `.rspec-local`.
#
# The following line is provided for convenience purposes. It has the downside
# of increasing the boot-up time by auto-requiring all files in the support
# directory. Alternatively, in the individual `*_spec.rb` files, manually
# require only the support files necessary.
#
# Dir[Rails.root.join('spec', 'support', '**', '*.rb')].each { |f| require f }
# Checks for pending migrations and applies them before tests are run.
# If you are not using ActiveRecord, you can remove these lines.
begin
- 1
ActiveRecord::Migration.maintain_test_schema!
rescue ActiveRecord::PendingMigrationError => e
puts e.to_s.strip
exit 1
end
- 1
RSpec.configure do |config|
- 1
config.include FactoryBot::Syntax::Methods
- 1
config.include Devise::Test::ControllerHelpers, type: :controller
# Remove this line if you're not using ActiveRecord or ActiveRecord fixtures
- 1
config.fixture_path = "#{::Rails.root}/spec/fixtures"
# If you're not using ActiveRecord, or you'd prefer not to run each of your
# examples within a transaction, remove the following line or assign false
# instead of true.
- 1
config.use_transactional_fixtures = false
# RSpec Rails can automatically mix in different behaviours to your tests
# based on their file location, for example enabling you to call `get` and
# `post` in specs under `spec/controllers`.
#
# You can disable this behaviour by removing the line below, and instead
# explicitly tag your specs with their type, e.g.:
#
# RSpec.describe UsersController, :type => :controller do
# # ...
# end
#
# The different available types are documented in the features, such as in
# https://relishapp.com/rspec/rspec-rails/docs
- 1
config.infer_spec_type_from_file_location!
# Filter lines from Rails gems in backtraces.
- 1
config.filter_rails_from_backtrace!
# arbitrary gems may also be filtered via:
# config.filter_gems_from_backtrace("gem name")
end
- 1
Shoulda::Matchers.configure do |config|
- 1
config.integrate do |with|
- 1
with.test_framework :rspec
- 1
with.library :rails
end
end
# frozen_string_literal: true
- 1
module ControllerMacros
- 1
def login_user
- 1
before(:each) do
- 1
@request.env['devise.mapping'] = Devise.mappings[:user]
- 1
user = FactoryBot.create(:user)
- 1
sign_in user
end
end
end
# frozen_string_literal: true
- 1
require_relative './controller_macros'
- 1
RSpec.configure do |config|
- 1
config.include Devise::Test::ControllerHelpers, type: :controller
- 1
config.extend ControllerMacros, type: :controller
end


Enter the challengeId to finish registration
You have been successfully registered on this browser
You should now be able to access this page


 This is to make sure that the mobile number you enter belongs to you.
We'll send you a code every time you sign in, to make sure it's not someone pretending to be you.


A Central Indiana Lawncare and Grounds Maintenance Service Provider
Basic 1 is a proud member of the Better Business Bureau of Central Indiana. We honor your time and promise to deliver a professional lawn care service too you.
We are fully licensed professionals and take risk management and your property seriously. As a fully insured service we cover the risk so you don't have too.
We service residential and commercial properties including mowing, gutter cleaning, snow removal, and more. Call for a free estimate today or complete our estimate web form.
Our services can be used one time only, weekly, bi-weekly, monthly, by contract or no contract, however you would prefer. We are available when you need us.
We have a proven record of client satisfaction and would like to prove ourselves to you and your needs. Hear what others are saying about Basic 1 and our services.
We pride ourselves on professionalism and cleanliness. We promise to leave your property looking top notch when we are done. We guarantee client satisfaction.
For questions and requests email us at<EMAIL_ADDRESS>or call<PHONE_NUMBER>
Receive our newsletter for lawn tips and service updates
Follow us on Facebook, see our fan page at Facebook.com/Basic1.
Have a Twitter account, then follow us at @basic1.


{% block navbar %}
Toggle navigation
BMx Dashboard
Categories
Services
Data and Analytics
Watson
Internet of Things
APIs
Network
Storage
Security
DevOps
Application Services
Integrate
All Services
{% endblock %} {% block body %} {% endblock %}


BEFORE THE NATIONAL GREEN TRIBUNAL SOUTHERN ZONE, CHENNAI APPEAL NOs. 22 and 23 of 2014 (SZ) In the matter of: M/s. Sri Murugan Dyeing Rep. by its Partner N. Sakthivel S.F.No. 159/1C1 & 1C2 Nallur village Tiruppur Taluk and District .. Appellant in both the appeals AND 1. The Disrict Environmental Engineer Tamil Nadu Pollution Control Board 2nd Floor, Kumaran Commercial Complex Kumaran Road Tiruppur-641 601 2. The Appellate Authority Tamil Nadu Pollution Control 'Krishna Vilas' No.51, Gangadeeswarar Koil Street Purasawalkam Chennai- 600 084 .. Respondents in both the appeals Counsel appearing: Appellants in both the appeals .. Shri C. Prakasam. Advocate Respondents in both the appeals .. Shrimathi Rita Chandrasekar, Advocate JUDGMENT1
Present:
1. Hon'ble Shri Justice M. Chockalingam, Judicial Member
2. Hon'ble Prof. Dr. R. Nagendran, Expert Member
------------------------------------------------------------------------------------------------
Date: 15th October, 2014
------------------------------------------------------------------------------------------------ (Hon'ble Shri Justice M. Chockalingam, Judicial Member) These appeals have been filled by appellant herein challenging the order of the 2nd respondent, namely, the Appellant Authority, Tamil Nadu Pollution Control (Appellant Authority) made in Appeal Nos. 37 and 38 of 2013 dated 28.02.2014 whereby the appeals have been dismissed.
2. The brief facts made out from the appeal memoranda can be stated thus:
The appellant submitted the application to the 1st respondent, District Environmental Engineer (DEE), Tamil Nadu Pollution Control Board (Board), Tiruppur on 19.06.1992 seeking consent to operate (CFO) the dyeing unit at S.F. No.143/1 and 143/2 in Nallur village, in Tiruppur Taluk and District at the rate of 20 MT per month and to discharge 105 KLD of trade effluent. The Chairman of the Board issued a communication to the appellant unit on 14.10.1993 stating that the Board had decided to recommend the case of the appellant for relaxing the conditions of G.O. Ms. No. 213, Environment and Forest Department dated 30.03.1989 (G.O. No. 213) and directed the appellant to obtain the relaxation order and communicate the same to the Board. Accordingly, 2 the appellant submitted a revised application for consent on 01.04.1999 to carry on the dyeing of hosiery fabric at the rate of 30 MT/month. The said application was not considered. Hence, the appellant again submitted a revised application on 20.07.2005 to carry on the dyeing of hosiery fabric of 1.15 MT per day and to discharge trade effluent at the rate of 172.5 KLD. The Chairman, Tamil Nadu Pollution Control Board refused to grant consent and hence the appellant unit became a member of the Kasipalyam Common Effluent Treatment Plant (CETP) Ltd., situated at S.F.No.249 (Part), 250 (Part) and 250/1, Agrahara Periyapalayam village, Avinashi Taluk. The trade effluent of the appellant's unit was taken to the said Kasipalayam CETP which was operating under a valid consent. The Kasipalayam CETP was closed by an order of the Hon'ble Madras High Court and again started functioning by an order of the Board dated 16.03.2012. The G.O. No. 213 dated 30.03.1989 prohibits only the establishment of new industries and not the shifting of an existing unit from one place to another. The unit is being shifted from a rented premises to the own premises and to facilitate the Zero Liquid Discharge (ZLD), and the pipelines are already in place to convey the trade effluent to the Kasipalayam CETP. The members of the Kasipalayam CETP do not have individual consent and are all operating based on the consent given to the CETP. The appellant unit has already installed the pipelines to carry the trade effluent to the 3 Kasipalayam CETP and the appellant unit is also to be treated as one of the members of the Kasipalayam CETP to operate the unit based on the consent given to the CETP.
3. The appellant unit is operating in a rented premise at S.F. No.143/1 and 143/2 in Nallur village, in Tiruppur Taluk and District from the year 2007 and as the landlord wanted the land for his own use, the appellant purchased land at S.F. No. 159/1C1 and 1C2 of the same village which is situate right opposite to the rented premises. The application for consent to shift the dyeing unit to the new premises was made on 28.07.2008 to the 1st respondent and the 1st respondent in his letter dated 08.08.2008 refused to give consent to shift the premises stating that the lands are situated within the prohibited distance of 300 m from Noyyal River and also further observed that even though the appellant unit is a member of the Kasipalayam CETP, the said unit is situated in a mixed residential zone as per letter No. 715/2008 dated 04.07.2008 of the Tiruppur Local Planning Authority. The appellant unit approached the Hon'ble High Court at Madras in W.P.No. 13878/2008 seeking a direction to the respondent to consider the appellant's representation dated 16.04.2008 and the Hon'ble High Court was pleased to dispose of the writ petition with a direction to the Chairman, TNPCB to consider the appellants representation within a period of one month. The appellant unit's consent application dated 25.04.2008 was 4 placed before the Consent Clearance Committee on 04.12.2008 and the application for consent was dismissed on the ground that the appellant unit's new premises is located at a mixed residential zone and the appellant unit is situated within a distance of 300 m from the Noyyal River and the same was communicated to the appellant unit in proceedings Lr.No.T8/TNPCB/F.3702/TPR/2008 dated 15.12.2008.
4. Aggrieved by the order of the Board, the appellant unit preferred a statutory appeal before the Appellate Authority in Appeal Nos. 21 and 22 of 2013 and the appeals were dismissed by the Appellate Authority. The Appellate Authority passed an order of consent to shift M/s. Syndicate Colours which is a member of Sirupooluvapatti CETP in Appeal Nos. 15 and 16 of 2009 which is adjacent to the unit of the appellant herein. Another dyeing unit namely, M/s. Colour Lines, Tiruppur is located in the agricultural area and even the Kasipalayam CETP is also situate in the river bed and agriculture area and the consent was granted by the Board on 07.10.2010. The appellant unit preferred a writ petition before the Hon'ble High Court of Madras aggrieved by the order of the Appellate Authority in W.P.No. 7480 of 2010 and the Hon'ble High Court disposed of the writ petition with a direction to the respondent/Board to consider the application of the appellant and pass orders within a period of 4 weeks. The respondent/Board rejected the application dated 25.04.2013 of the 5 appellant in Lr. No. F.TPR 0233/RS/DEE/TPR/2013 dated 25.04.2013 on the same reasons that the unit is located in a mixed residential zone and the unit is located within the prohibited distance from Noyyal River.
5. Aggrieved by the order of the respondent/Board, the appellant preferred an appeal before this Bench of National GreenTribunal (NGT) in Appeal No. 54 of 2013 as the Appellate Authority was not functioning at that time and the Tribunal by its order dated 12.07.2012, directed the appellant to approach the Appellate Authority as the order of the respondent/Board is appealable under the Water (Prevention and Control of Pollution) Act, 1974 (Water Act) and Air (Prevention and Control of Pollution) Act, 1981 (Air Act). The Appellate Authority dismissed the appeals filed by the appellant seeking permission to shift the existing dyeing unit. Hence, these appeal are filed by the appellant herein seeking to set aside the order dated 28.02.2014 of the Appellate Authority in Appeal Nos. 37 and 38 of 2013 and to grant permission to shift the appellant's unit.
6. Per Contra, the Joint Chief Engineer of the Board would state in reply that the appellant unit, namely M/s. Murugan Dyeing, is a member of the Kasipalayam CETP and originally applied for consent at S.F. No. 142/1 of Nallur village, Tiruppur Taluk and District on 19.06.1992 for the dyeing of hosiery fabric at 20 MT per month and to discharge 105 KLD of trade effluent. As the unit of the appellant is situate within 1 km from 6 Noyyal River, the Board in its letter dated 14.10.1993 informed the appellant to obtain orders of the Government relaxing the condition relating to the distance factor as per G.O. No. 213 dated 30.03.1989. Hence, consent was not issued to the appellant's unit. A revised application was submitted on 01.04.1999 by the appellant unit seeking consent to the dyeing of hosiery fabric at 30 MT per month and to discharge 150 KLD of trade effluent at S.F. No. 143/1, 143/2 and 141 of Nallur village in Tiruppur Taluk and District. Thereafter, the unit has submitted another revised application on 25.07.2005 seeking consent to dyeing of hosiery fabric at 1.15 MT per day and to discharge 172.5 KLD of trade effluent. The location of the unit is within 1 km of the Noyyal River and attracted by the provisions of G.O.No.213 dated 30.03.1989. Further, Kasipalayam CETP with which the appellant's unit is attached did not have consent from the Board and hence the application made by the appellant could not be considered and consent was not issued.
7. The appellant filed a writ petition in W.P. No. 13878 of 2008 before the Hon'ble High Court of Madras seeking permission to shift the existing unit from the present location at S.F. No. 143/1, 143/2, and 141 of Nallur village in Tiruppur Taluk and District to a new location at S.F. No. 159/1C1 and 1C2 of the same village and in the order dated 16.06.2008, the High Court disposed of the writ petition based on the submissions made by the Board that the representation dated 7 16.04.2008 shall be disposed of in accordance with law by a reasoned order within a period of one month from that date. When the appellant herein was directed to apply for the consent of the Board under Water Act and Air Act, the appellant filed application on 28.07.2008 for a new location at S.F. No. 159/1C1, 1C2 of Nallur village in Tiruppur Taluk and District for the dyeing of hosiery fabric at 28.125 MT per month and to discharge 172.5 KLD of trade effluent. The proposed location of the appellant's unit at S.F. No. 159/1C1 and 1C2 of Nallur village is at a distance of 300 m from Noyyal River which is within the prohibited distance as per the G.O.No. 213 dated 30.03.1989 and G.O.Ms.No. 127, Environment and Forest Department dated 08.05.1998 and the location of the existing unit in S.F. No. 143/1, 143/2 and 141 of Nallur village is at a distance of 270 m and both the locations are within the prohibited distance of the said Government orders. The location of the unit of the appellant has been classified as mixed residential area by the Tiruppur Local Planning Authority and hence, the Board has not issued consent even for the unit in the existing location since the Government has not relaxed the G.O.No. 213 dated 30.03.1989. The issue of consent for shifting the unit to the new location could not also be considered as the River Noyyal is flowing at a distance of 300 m. The Board, therefore, rejected the application on the above reasons. The appellant unit preferred appeals before the Appellate Authority in Appeal Nos. 21 and 8 22 of 2009 and the Appellate Authority dismissed the appeals on 15.03.2010 stating that unless and otherwise the appellant gets the location of its unit reclassified from mixed residential zone, the appellant would not be entitled to consent. Further, the Appellate Authority has also given the liberty to the appellant to make appropriate application to the Board for getting whatever remedy he required.
8. At this juncture, the appellant unit made fresh application on 25.03.2010 seeking consent of the Board for its existing location at S.F. No. 143/1, 143/2 and 141 of Nallur village to carry on dyeing hosiery fabrics at 29.326 MT per month and to generate 200 KLD of trade effluent to discharge into Kasipalayam CETP and when additional particulars were called from the unit, the same were not submitted by the appellant unit.
9. In the meantime, the appellant filed W.P.No. 7480 of 2010 against the order dated 15.12.2008 of the Board and order dated 15.03.2010 of the Appellate Authority. The writ petition was disposed of on 15.06.2010 with directions to the Board to consider the application dated 25.03.2010 which was for the unit in the existing location and pass orders on merit and in accordance with law.
10. The Board vide its memo dated 16.07.2010 has returned the application to the office of the DEE of the Board, Tiruppur as requested by the DEE so as to comply with the orders of the Hon'ble High Court of 9 Madras issued in W.P.No.7480/2010. At this juncture, the Noyyal River Ayacutdars Protection Association filed contempt petitions in No.1013 and 1068 of 2010 for non-compliance of orders of the Hon'ble High Court of Madras made in W.P. No. 29791/2003 dated 22.12.2006 and the orders of the Hon'ble Supreme Court of India. Since the contempt case was under trail in the Hon'ble High Court of Madras, the unit's application was not processed by the DEE of the Board at Tiruppur. Moreover, the unit has not made any representation to the Board to effect the orders of the Hon'ble High Court. In the meantime, all the dyeing and bleaching units in Tiruppur were closed based on the order dated 28.01.2011 of the Hon'ble High Court of Madras in Contempt Petition Nos. 1013 and 1068 of 2010 with respect to W.P. No. 29791/2003 filed by the Noyyal River Ayacutdars Protection Association and with disconnection of power supply which includes the appellant's unit also. Based on the representation dated 05.12.2002 made by appellant, the application seeking consent for the unit was placed before the VI Zonal Level Consent Clearance Committee meeting held on 19.04.2013 and the application was decided to be rejected for the following reasons and these were communicated to the appellant by DEE's letter dated 25.04.2013.
1. In the existing location at S.F. No.143/1, 2 and 141 this industry is not existence.
10
2. In the new location at S.F. No.159/1C1, 1C2, Nallur village, construction activities have been completed.
3. The unit's above sites are located in the Mixed Residential area, where the dyeing activity is not permitted.
4. The river Noyyal which is included in the G.O. Ms. No. 213, Environment and Forest Department, dated 30.03.1989 and G.O.Ms.No.127, Environment and Forest Department dated 08.09.1998 is flowing within 1 km from the locations as stated above. The said Government orders ban the setting up of dyeing activity 1 km/5 km from River Noyyal.
11. Aggrieved over the above letter dated 25.04.2013, the appellant preferred Appeal No. 54 of 2013 before the Tribunal as the Appellate Authority was not functioning at that time and the Tribunal passed orders on 12.07.2013 directing the appellant to exhaust the appeal remedy available under Water Act and Air Act and disposed of the appeal. The appellant preferred necessary appeals before the Appellate Authority in Appeal Nos. 37 and 38 of 2013 to direct the Board to issue consent to the appellant's unit to shift from the existing location to a new location and the appeals were dismissed as the appellant did not convince the Board with reference to any of the factual issue or on the point of law so as to seek the relief in those appeals.
12. On the above averments, the respondent Board seeks to uphold the order dated 28.02.2014 made by the Appellate Authority 11 which sustained the rejection order made by the DEE on 25.04.2013 and to dismiss the appeals.
13. The following points are formulated for decision in these appeals based on the above pleadings.
1. Whether the orders of the 2nd respondent/Appellate Authority in Appeal Nos. 37 and 38 of 2014 dated 28.02.2014 upholding the orders of the 1st respondent/Board in Letter No. F.
TPR/0233/RS/DEE/TPR/2013 dated 25.04.2013 are liable to be set aside as sought for by the appellant and consequently grant permission to the appellant to shift the unit as applied for. POINT:
14. The Tribunal heard the arguments advanced on both sides and looked into all the materials available and in particular the order of the 2nd respondent/Appellate Authority and also of the 1st respondent/Board and paid its anxious considerations thereon.
15. As could be seen from the specific averments from both sides, the appellant unit applied for consent on 19.06.1992 to commence its activity in S.F. No. 143/1, 143/2 of Nallur village for dyeing of hosiery fabric at 20 MT per month and to discharge 105 KLD of trade effluent. The appellant was informed by the Board in Lr. No. T.13/1473/W/93 dated 14.10.1993 that a recommendation would be sent to Government for relaxation of the G.O.No.213 dated 30.03.1989 since the appellant's 12 unit was located within 1 km from Noyyal River. There is no material available and it is not the case of the appellant also that any relaxation of the G.O.No.213 dated 30.03.1989 was given to the appellant at any point of time. Under the circumstances, consent was not issued to the appellant by the Board as applied for by the appellant. It is admitted by the Board as contended by the appellant that revised applications were made on 01.04.1999 and also on 25.07.2005 for the dyeing of hosiery fabric at 30 MT per month and to discharge 150 KLD of trade effluent and at 1.15 MT per day and to discharge 172.5 KLD of the trade effluent, respectively.
16. Though the Kasipalayam CETP was closed for a period as per the orders of the Hon'ble Madras High Court in Contempt Petition Nos. 1013 and 1068 of 2010, the same has been in operation as per the orders dated 16.03.2012 of the Board.
17. The case of the appellant is that the unit was operating at S.F. Nos. 143/1, 143/2 and 141 of Nallur village on a rented premises and in view of the demand by the landlord, the partners of the appellant's unit purchased a piece of land situate at S.F. No. 159/1C1, 1C2 of Nallur village whereupon an application for consent to shift the dyeing unit to the new premises was made on 25.07.2008 and the same was refused by a communication dated 08.08.2008 stating that the proposed unit of the appellant was within the prohibited distance of 1 km from the Noyyal 13 River and also the appellant unit is a member of the Kasipalayam CETP and the said unit is situate in a mixed residential zone as per the letter dated 04.07.2008 of the Tiruppur Local Planning Authority. The appellant made an application on 16.04.2008 to the respondent Board and approached the Hon'ble High Court, Madras in W.P.No. 13878 of 2008 for a direction to the respondent Board to consider the representation dated 16.04.2008. The same was disposed of with a direction to the Chairman of the Board to pass appropriate order on the representation of the appellant unit within a period of one month. The Board called for necessary particulars and details from the appellant which were furnished.
18. The application for the consent of the Board for the appellant's unit dated 25.04.2008 which was placed before the Consent Clearance Committee was rejected on 04.12.2008 on the grounds that the new premises where the appellant's unit is to be located falls under mixed residential zone and is also within a distance of 300 m from Noyyal River. The same was communicated to the appellant by the Board in the proceedings dated 15.12.2008.
19. Aggrieved over the same, the appellant preferred the Appeal Nos. 21 and 22 of 2009 before the Appellate Authority who dismissed the same. Challenging the said dismissal order on the said appeals, the appellant filed W.P.No. 7480 of 2010 before the Hon'ble Madras High 14 Court and the same was disposed of by the Hon'ble High Court with a direction to the Board to consider and pass order within a time frame. The respondent Board rejected the application made by the appellant unit on 25.04.2013 on the reasons that the unit is in a mixed residential area and is also situate within the prohibited distance from the Noyyal River. The appellant preferred an appeal before this Bench of NGT in Appeal No. 54 of 2013 since the Appellate Authority was not functioning during that time. The said appeal was disposed of by this Bench with a direction to the appellant to approach the Appellate Authority within a period of 30 days therefrom. Accordingly, the appellant preferred Appeal Nos. 37 and 38 of 2013 under the Water Act and Air Act before the Appellate Authority which was dismissed. The appellant has preferred these two appeals therefrom.
20. The bone of contention of the appellant is that the respondent Board should have granted the consent to the appellant's unit since it was an existing unit which was carrying on its operations in S.F. No. 143/1, 143/2 and 141 of the Nallur village and the appellant is intending to shift the unit to the own land of the appellant purchased and situate at S.F. No. 159/1C1 and 1C2 of Nallur village and made an application on 28.07.2008. Pointing to the application made by the appellant before the Board seeking consent, the counsel would vehemently contend that it was only the shifting of the unit from the old premises to a new premises 15 and thus it is not a new industry or a new unit and thus the prohibition on the distance criteria that it is situate at a distance of 300 m from Noyyal River would not apply. No doubt, the shifting of an existing unit to a new location cannot be construed as a new industry. It is also true that the appellant has originally filed the application, revised applications and representations and also application dated 28.07.2008 and the rejection of which has culminated in all subsequent proceedings including these appeals. From the materials available, it is quite evident that from the year 1992 onwards the appellant unit was never granted consent to carry on its activities. Under the said circumstances, the appellant's unit cannot be termed as an existing unit. Even if the unit was carrying on its activities, it should have been without any consent of the Board. Hence, the Tribunal is afraid whether it can agree with the contention of the appellant that the appellant's unit is an existing unit and hence the distance criteria would not apply. Equally, the contention putforth by the appellant that it is a member of a CETP which has commenced functioning from February, 2014 is worth to be ignored for the reason that consent granted to a CETP in which the appellant's unit is a member cannot be taken as a ground to the appellant's unit to carry on the activities. Consent to a CETP is only for treatment, discharge and disposal of the trade effluent generated from different member units 16 which has nothing to do with the grant of consent to the dyeing unit as that of the appellant.
21. In the instant case, at no point of time consent was ever given to the appellant's unit to commence its activities despite a number of applications and representations and hence, it cannot be construed as an existing unit. Hence, the case of the appellant that the appellant unit has applied for shifting of the existing unit cannot be accepted. Thus, both the appeals have got to be dismissed as devoid of merits and accordingly dismissed.
No cost.
(JusticeM. Chockalingam) Judicial Member (Prof. Dr. R. Nagendran) Expert Member Chennai 15th October, 2014 17


Gnome Xmonad Lucid
I just got started using tiling window managers because I find that I am a little more productive when I don't use the mouse. With Xmonad, I don't have to deal with overlapping windows and I never have to use the mouse!
I did have some trouble integrating Xmonad into my Ubuntu 10.04 install. I couldn't interface with my wireless card, and I can't always be somewhere with a cable. I had to continue using the NetworkManager app until I had more time to play and look through manuals.
Luckily, I stumbled upon this straightforward walkthrough (Link no longer active). Now I am happily using Gnome and Xmonad in Ubuntu 10.04 Lucid!


https://ismailezzaki.me -
0708070221 -
<EMAIL_ADDRESS>Simulation of a mach zehnder interferometer as a coronagraph (Python, Tkinter).
Build a simulation of Mach Zehnder interferometer as a coronagraph for the observatory of Oukaimeden
Simulation of atlas events using a neural network gan (Python, Tensorflow , KERAS).
Trained a GAN neural network to produce \(Z → μμ\) events under conditions that mimic collisions at CERN ATLAS detector
Analysis of the Higgs boson in the final states of four leptons (C++ , ROOT).
Reproduced the analysis of the Higgs boson discovery using the 2011 and 2012 datasets, in four-lepton final states
Master degree in particle physics and computational physics (Cadi ayyad university).
Ranking : \(2^{nd}\) of the promotion
Master thesis : Black holes physics : thermodynamics and phase transitions I studied the four laws of thermodynamics in a black hole and deduced the possible phase transitions
Bachelor degree in physics (Ibn zohr university).
Bachelor thesis : Laser physics and modes of operation
Programming : Experienced
: C++ / Python
/ Fortran Familiar
: Maple / Matlab / Mathematica
Technologies: Git / Linux / Monte Carlo Simulation / Latex
Frameworks: Tensorflow / Keras / Sci-kit learn / ROOT / NodeJs
Languages: English
(C1) -
French
(C1)
Mohamed Chabab : Director of LPHEA laboratory, My master’s supervisor -<EMAIL_ADDRESS>Mohamed El kacimi : Member of ATLAS collaboration - elkacimi@uca.ac.ma


--- layout: default ---
Hey! I’m Victor 👋 I am a Linux, Emacs, and Tmux heavy user. I use a weird keyboard and like to build programming languages.
I’m currently working for Code Climate.


If you have a Merit Desktop Wallet already, synchronizing it with or adding a separate Web Wallet is a great way to make your experience smoother.
To synchronize your web wallet with an existing wallet, you must first get your wallet's Pass Phrase.
Go to: Help > Debug Window > Console
Type: getmnemonic
To create a standalone wallet, you simply use your existing alias or address as your invite code. This method requires a spare invite that you must send to your new wallet in order to active it.
Ensure you have at least 1 available invite.
Use your own Alias as a referral.


FlushKeys
Parameters
None.
Description
This command 'resets' or 'empties out' the queue holding the keyboard inputs. Can't make it much easier than that.
Example
; clear all keystrokes from the queue
FlushKeys
Index
Click
here
to view the latest version of this page online


I promised to dig a little deeper into what you can do with Ansible and NetApp in my last post. In the spirit of 30 blog posts in 30 days I decided to cheat a little on the first post by counting this as #1. Without further ado let’s jump right in to the good stuff.
How many times have you had to create multiple volumes, LIFs, etc. and you pop open Excel to create a concatenate formula and copy and paste into your terminal emulator of choice? Ansible allows you to accomplish this using the built in “with_items:” statement. Consider the following task of creating several LIFs.
- name: Create lif 1 for nfs
int_create:
cluster: "<IP_ADDRESS>"
user_name: "admin"
password: "Password1"
vserver: "svm_nfs"
lif: "lif_nfs_01"
role: "data"
data_proto: "nfs"
node: "atlcdot-01"
port: "e0d"
ip: "<IP_ADDRESS>"
netmask: "<IP_ADDRESS>"
- name: Create lif 2 for nfs
int_create:
cluster: "<IP_ADDRESS>"
user_name: "admin"
password: "Password1"
vserver: "svm_nfs"
lif: "lif_nfs_02"
role: "data"
data_proto: "nfs"
node: "atlcdot-01"
port: "e0d"
ip: "<IP_ADDRESS>"
netmask: "<IP_ADDRESS>"
- name: Create lif 3 for nfs
int_create:
cluster: "<IP_ADDRESS>"
user_name: "admin"
password: "Password1"
vserver: "svm_nfs"
lif: "lif_nfs_03"
role: "data"
data_proto: "nfs"
node: "atlcdot-01"
port: "e0d"
ip: "<IP_ADDRESS>"
netmask: "<IP_ADDRESS>"
Now the same tasks using “with_items:”
- name: Create lif for nfs
int_create:
cluster: "<IP_ADDRESS>"
user_name: "admin"
password: "Password1"
vserver: "svm_nfs"
lif: {{ item.name }}
role: "data"
data_proto: "nfs"
node: "atlcdot-01"
port: "e0d"
ip: {{ item.ip }}
netmask: "<IP_ADDRESS>"
with_items:
- { name: 'lif_nfs_01', ip: '<IP_ADDRESS>' }
- { name: 'lif_nfs_02', ip: '<IP_ADDRESS>' }
- { name: 'lif_nfs_03', ip: '<IP_ADDRESS>' }
As you can see, the task is cleaner and shorter. Now what if we had a dictionary of LIF names and their respective home nodes, home ports, vservers and ip addresses that we wanted to loop over in our playbook. That would be accomplished using the “with_dict:” statement. Say we had our dictionary in the following variable file.
---
lifs:
lif_cifs_01:
vserver: svm_cifs
proto: cifs
home_node: node1
home_port: e0c
ipaddr: <IP_ADDRESS>
lif_nfs_01:
vserver: svm_nfs
proto: nfs
home_node: node2
home_port: e0d
ipaddr: <IP_ADDRESS>
We could loop through this dictionary using “with_dict:” in our playbook as follows:
- name: Create lifs
int_create:
cluster: "<IP_ADDRESS>"
user_name: "admin"
password: "Password1"
vserver: {{ item.value.vserver }}
lif: {{ item.key }}
role: "data"
data_proto: {{ item.value.proto }}
node: {{ item.value.home_node }}
port: {{ item.value.home_port }}
ip: {{ item.value.ipaddr }}
netmask: "<IP_ADDRESS>"
with_dict: "{{ lifs }}"
Hopefully these tips can save you some time with your own playbooks. For more information about loops in Ansible I recommend the Ansible documentation.


Beta This is a test version of the layout of this page. Take the survey to help us improve it
Research and analysis
Report looking at an evaluation of the home access programme, using evidence from school-based case studies.
The vision for home access was to make sure that all pupils aged 5 to 19 in state maintained education in England had access to computers and internet connectivity for education at home. In July 2008, the home access taskforce report identified evidence of market failure, and made the case for government intervention in providing home access to technology, particularly to lower income families with children.
This document is the final report of an evaluation of the home access programme. It includes findings from:
The report qualitatively assesses programme effectiveness to date and provides analysis of the extent to which it has achieved its intended outcomes. Secondary data provides an updated national context on the take up of home access to connectivity.


Oops!
Page not available.
The page you're looking for is not available. I promise no unicorns here.
Take Me Home


Note: To complete these procedures, you must be assigned a role having the necessary permissions. To determine your role, follow the directions in Participant roles. For a basic understanding of roles and permissions, see Permissions and roles: Overview.
On this page:
Note: The following instructions are for uploading new files to the Resources tool. To replace an existing file with a new version, see Updating a file's contents below.
To upload files using Resources, in your site's menubar,
click Resources
, and then:
Add
menu, click Upload Files
.
Browse
to find the appropriate file on your
computer or network, and then click Open
.
Note: Filenames that include certain characters cannot be accepted. For a list of unsupported characters, see Unsupported characters.
Note: When you use WebDAV to access your item, you'll see only the filename, not the display name.
Add details for this
item
, which will allow you to do the following:Use copyright below
, a text box will appear
in which you can add information about the copyright.
more
info
.
Display copyright alert and require
acknowledgment when accessed by others
. This option will require
users to agree to the copyright terms to view the resource. To see the
alert, click what's this?
. You cannot edit this alert.
Only members
of this site can see this file
. (This option is not available if
the folder to which you're adding the resource is publicly viewable.)
This file is publicly viewable
. (This option
is not available if the folder to which you're adding the resource is
publicly viewable.)
Display
this file to selected groups only.
, and then select the
group(s) that should have access. (This option does not appear if you
don't have any groups in your site; for more, see Managing groups.)
Optional properties
. You
can then add information to the following fields:
Add Another File
.
You can add any number of files at once, as long as the total file size does not exceed the limit set by your system administrators. This limit will vary depending on your institution's policies, and is displayed at the bottom of the file upload screen.
Note: To remove a file from the list of files to
add, click the red X
next to it.
Upload Files Now
to finish.
Note: You can also use WebDAV to drag and drop files from your computer to your Resources area. See:
To edit the name, description, availability, access settings, or
optional properties for a file, from the Actions
menu next to
your file's name, click Edit Details
. Make your changes, and
then click Update
to save them.
Whenever you open a file from Resources, such as a Word document, your computer creates a temporary copy and displays it, while the original file stays on the server. If you make any changes to the temporary copy, they are not saved automatically to the original. If you want to change the contents of the original, you will need to open it, make and save your changes, and then replace the original version with your updated version.
To replace a Resources file with an updated version from your
computer, from the Actions
menu next to your file's name,
click Upload New Version
. Click Browse
to select the
updated file from your computer, and then click Upload New Version
Now
.


{% extends 'base.html' %} {% block header %}
The year is 20XX and due to an unknown pathogen outbreak civilization as we know it has been reduced to rubble. Larger cities fell first due to the population density. You are currently in your old apartment but the Z's are pounding on your rear door and will break through any moment.  You know that it is safer on the outskirts of the city but you have to go through the thick of it if you want to escape to the other side and get to a local farm and live out the rest of days.
HOW TO PLAY: You will have to go through 3 randomly picked areas where you will have to make decisions that will either lead to your escape or it will lead to your death. Pick wisely and remeber if you need help just type 'help'. To make a choice enter the number that corrisponds to the choice you want to make.
{% for message in get_flashed_messages() %}


Santa claus can may check you, if you are naughty or nice. Try these for random names/numbers here.


JavaScript
Topics
ECMAScript
weakly-typed
prototypal inheritance
Functions as first-class objects
Use of 'this' keyword
Strict equivalence
Modules


{% extends "global/Page.html" %} {% load otree static %} {% block title %} Demographic Questions {% endblock %} {% block content %}
Please answer the following questions. These are used for demographic purposes only. This information will not be associated with your name as you remain anonymous to all th other players and the experimenters.
{% for field in form %} {% formfield field %} {% endfor %} {% next_button %} {% endblock %}


{% extends "base.html" %} {% block title %} | Login{% endblock %} {% block content %} Login {% if form.errors %} Your username and password didn't match. Please try again. {% comment %} {% else %} Please, enter username or email, and password: If you don't have an account register here {% endcomment %} {% endif %} {% include 'partials/_alerts.html' %} {% csrf_token %} Username Password {% endblock %}
Your username and password didn't match. Please try again.
Please, enter username or email, and password:
If you don't have an account register here


About Us
Company history
Cookies began with two visionary founders: grow expert Jai, and entrepreneur Berner, whose Girl Scout Cookies (GSC) remains one of the most sought-after cannabis strains in the world. From the earliest days in a San Francisco garage to global growth, our goal has remained the same: authenticity and innovative genetics. Our control of the entire experience from start to finish, seed to sale, sets us apart. We take pride in our in-house cultivation, global varieties, and full lineup of strain-specific products. Cookies is a lifestyle. Join the community as we take it worldwide.
Mission
Cupcake ipsum dolor sit amet. Fruitcake cake gummi bears brownie apple pie jelly gummi bears. Cookie bear claw donut pie tootsie roll lemon drops muffin cookie.
Locations:
- seattle : 8th Ave S Seattle, Washington(WA)
- tokyo:21-15 Jingumae, Shibuya City, Tokyo 150
- Dubai: The Dubai Mall Upper Level
- paris:72 Rue Legendre, 75017 Paris
- Lima:Jirón de la Unión 272, Cercado de Lima 15001
Store Locations and Open Hours.
- Seattle from 10am to 6pm
- Dubai from 10am to 6pm
- Tokyo from 10am to 6pm
- Paris from 10am to 6pm
- Lima from 10am to 6pm
Contact information :
-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>-<EMAIL_ADDRESS>Get our Shirt for free when you order


The following table describes the OrderResponseErrorCode
enumeration members:
| Member | Value | Description |
|---|---|---|
| EuropeanOptionNotExpiredOnExercise | -33 | Exercise time before expiry for European options (-33) |
| InvalidNewOrderStatus | -32 | Cannot update/cancel orders with OrderStatus.New (-32) |
| ExceedsShortableQuantity | -31 | The order's quantity exceeds the max shortable quantity set by the brokerage (-31) |
| OrderQuantityLessThanLotSize | -30 | Cannot submit or update orders with quantity that is less than lot size (-30) |
| NonExercisableSecurity | -29 | The order's symbol references a non-exercisable security (-29) |
| NonTradableSecurity | -28 | The order's symbol references a non-tradable security (-28) |
| ConversionRateZero | -27 | Need conversion rate to account currency (-27) |
| QuoteCurrencyRequired | -26 | Need quote currency in cashbook to trade (-26) |
| BrokerageModelRefusedToUpdateOrder | -25 | Internal logic invalidated update order (-25) |
| AlgorithmWarmingUp | -24 | All orders are invalidated while algorithm is warming up (-24) |
| RequestCanceled | -23 | Request was canceled by user (-23) |
| InvalidRequest | -22 | Request is invalid or null (-22) |
| MarketOnCloseOrderTooLate | -21 | Below buffer time for MOC order to be placed before exchange closes. 15.5 minutes by default (-21) |
| ExceededMaximumOrders | -20 | Transaction manager's cache is full (-20) |
| SecurityHasNoData | -19 | Should not attempt trading without at least one data point (-19) |
| ForexConversionRateZero | -18 | Need conversion rate to account currency (-18) |
| ForexBaseAndQuoteCurrenciesRequired | -17 | Need both currencies in cashbook to trade a pair (-17) |
| SecurityPriceZero | -16 | Zero security price is probably due to bad data (-16) |
| ExchangeNotOpen | -15 | Some order types require open exchange (-15) |
| MissingSecurity | -14 | Security is missing. Probably did not subscribe (-14) |
| PreOrderChecksError | -13 | Unknown error during pre order request validation (-13) |
| UnsupportedRequestType | -12 | This type of request is unsupported (-12) |
| OrderQuantityZero | -11 | Cannot submit or update orders with zero quantity (-11) |
| UnableToFindOrder | -10 | Missing order (-10) |
| InvalidOrderStatus | -9 | Only pending orders can be canceled (-9) |
| BrokerageFailedToCancelOrder | -8 | Brokerage cancel error (-8) |
| BrokerageHandlerRefusedToUpdateOrder | -7 | Internal logic invalidated update order (-7) |
| BrokerageFailedToUpdateOrder | -6 | Brokerage update error (-6) |
| BrokerageFailedToSubmitOrder | -5 | Brokerage submit error (-5) |
| BrokerageModelRefusedToSubmitOrder | -4 | Internal logic invalidated submit order (-4) |
| InsufficientBuyingPower | -3 | Not enough money to to submit order (-3) |
| OrderAlreadyExists | -2 | Cannot submit because order already exists (-2) |
| ProcessingError | -1 | Unknown error (-1) |
| None | 0 | No error (0) |


Why are contrast response functions linear in fMRI and nonmonotonic in EEG?
04 Oct 2012Contrast response functions (CRFs) describe how a neuron’s firing rate depends on the contrast, or intensity, of a visual stimulus. CRFs are really important for testing theories about how the visual system works, and I’ve spent a lot of time over the past few years trying to indirectly measure them in humans, using EEG and fMRI. The problem, however, is that EEG and fMRI give me very different CRFs.
Typically, individual neurons show sigmoidal CRFs. They don’t fire at all for very low contrasts, but they rapidly increase their firing rate at a middle range of contrast. The midpoint of this range is sometimes called the ‘semisaturation constant’. After that, the firing rate tends to level off, or ‘saturate’.
With fMRI, however, I tend to find that the CRFs are mostly linear, not sigmoidal.
And with EEG, I often find that the CRFs are actually nonmonotonic!
This is weird, and I’m not the first person to notice it. Linear CRFs in fMRI are quite common (e.g. here and here), as are nonmonotic CRFs in EEG (e.g. here, here, here, and here ). While not all papers show these effects, they certainly seem like real trends. How it is possible that an underlying sigmoidal function in neurons could give rise to such completely different functions measured by fMRI and EEG?
To explain the linear fMRI responses, one idea is that fMRI takes an average over many different neurons, each with a different semisaturation constant.
That seems to make sense. But what about the nonmonotonic CRFs in EEG? One idea is that EEG CRFs might reflect the true contrast response functions of individual neurons, many of which are themselves nonmonotonic. While I don’t doubt that this could be a contributing factor, I have trouble believing that this explains all, or even most, of the nonmonotonicity in EEG. Only a small minority of visual cells exhibit this property, and I have seen some _massive _nonmonotonicity in some of my most reliable EEG subjects.
A different hypothesis is that nonmonotonicity is caused by the cancellation of dipoles across cortical sulci or gyri. EEG dipoles are oriented normal to the cortical surface and, since the cortex has so many folds, many of the electrical signals simply cancel each other out.
Here’s where it gets interesting. Different cortical areas (e.g. V1 and V2) have different average semisaturation constants. (They tend to get lower the higher you move up in the visual hierarchy). Imagine that two cortical areas with different semisaturation constants live on opposite sides of a sulcus. At medium contrasts, one area will be active and the other will be mostly silent. But at higher contrasts, both areas will have kicked in, and so the overall signal (due to cancellation) will be actually _lower _that at medium contrast. This isn’t my idea, but it makes a lot of sense and I think it deserves more attention.
But wait, the fMRI explanation makes sense, and the EEG explanation makes sense, but how can they both be true? After all, the EEG cancellation story only works if each area’s average CRF is nonlinear: If the average responses were linear (as demonstrated by the fMRI explanation), cancellation of opposite CRFs would just result in more straight lines, right?
Well, yes and no. Using simulations I have found it quite easy to capture both effects. In the fMRI simulation, a perfectly linear CRF emerges only if I assume that the underlying neural semisaturation constants are uniformly distributed, which is quite an unlikely assumption. With any other reasonable distribution (e.g. normal distribution) I get fMRI CRFs that are mostly linear but with a touch of sigmoid. And critically, that touch of sigmoid will drive the dipole cancellation in a way that results in nonmonotonic EEG CRFs.
Below is some Matlab code showing how this works, just a proof of concept. It makes some very, very simplifying assumptions, and I’m sure that the truth is far more complicated.
And here are the results.
It would be nice if we could go in the opposite direction and reconstruct underlying neural responses from the fMRI and EEG measurements. This seems like a pretty tricky inverse problem, but it might be possible with accurate assumptions about current propagation and the distribution of semisaturation constants.