trhura

(defn combinations [lst k]
  (letfn [(combinator [x xs]
            (if (= (count x) k)
              [x]
              (when (not (empty? xs))
                (concat (combinator (concat x [(first xs)]) (rest xs))
                        (combinator x (rest xs))))))]
    (combinator nil lst)))

;; user> (combinations (range 1 6) 2)

mateuszwenus

create table deps_saved_ddl
(
  deps_id serial primary key, 
  deps_view_schema varchar(255), 
  deps_view_name varchar(255), 
  deps_ddl_to_run text
);

create or replace function deps_save_and_drop_dependencies(p_view_schema varchar, p_view_name varchar) returns void as
$$

EddyF

#FOR MULTIPLE REDIS INSTANCE INSTALLATION ON RHEL7+ USE THE FOLLOWING PATHS AND SETUP PROCESS:

• create a new redis .conf file

$ cp /etc/redis.conf /etc/redis-xxx.conf

• edit /etc/redis-xxx.conf, illustrated as below

stevegrossi

#!/usr/bin/env ruby

require 'ruby-jmeter'

test do

  defaults domain: 'beta.stevegrossi.com'

  cookies clear_each_iteration: true

joyrexus

Nice answer on stackoverflow to the question of when to use one or the other content-types for POSTing data, viz. application/x-www-form-urlencoded and multipart/form-data.

“The moral of the story is, if you have binary (non-alphanumeric) data (or a significantly sized payload) to transmit, use multipart/form-data. Otherwise, use application/x-www-form-urlencoded.”

---

Matt Bridges' answer in full:

The MIME types you mention are the two Content-Type headers for HTTP POST requests that user-agents (browsers) must support. The purpose of both of those types of requests is to send a list of name/value pairs to the server. Depending on the type and amount of data being transmitted, one of the methods will be more efficient than the other. To understand why, you have to look at what each is doing

lewisd32

echo "Flipping tables! (╯°□°）╯︵ ┻━┻"

num_rules=3

real=3    # exposed to the ELB as port 443
test=4    # used to install test certs for domain verification
health=5  # used by the ELB healthcheck

blue_prefix=855
green_prefix=866

trungv0

# install haproxy
yum install -y haproxy

# config haproxy for rabbitmq
cat > /etc/haproxy/haproxy.cfg << "EOF"
global
  log 127.0.0.1 local0 notice

  maxconn 10000
  user haproxy

dialogbox

SELECT  MAX(FCT_CODE)           KEEP(DENSE_RANK FIRST ORDER BY FNL_UPD_DT desc, PRODC_MAGT_NO desc) AS FCT_CODE,
       MAX(PLANT_CODE)         KEEP(DENSE_RANK FIRST ORDER BY FNL_UPD_DT desc, PRODC_MAGT_NO desc) AS PLANT_CODE,
       MAX(PRODC_MAGT_NO)      KEEP(DENSE_RANK FIRST ORDER BY FNL_UPD_DT desc, PRODC_MAGT_NO desc) AS PRODC_MAGT_NO
FROM    TBM_PM_PRODC_PRGS A
WHERE   1 = 1
  AND  (A.FCT_CODE, A.PLANT_CODE) IN (('C100A', 'P105'))
  AND  (A.PRODC_MAGT_NO = '0F5PH3AH700007H' OR A.PRODC_MAGT_NO LIKE '0F5PH3AH700007H'||'_')
  AND  ROWNUM = 1
-- ==>  
  

alekseykulikov

Recently CSS has got a lot of negativity. But I would like to defend it and show, that with good naming convention CSS works pretty well.

My 3 developers team has just developed React.js application with 7668 lines of CSS (and just 2 !important). During one year of development we had 0 issues with CSS. No refactoring typos, no style leaks, no performance problems, possibly, it is the most stable part of our application.

Here are main principles we use to write CSS for modern (IE11+) browsers:

• SUIT CSS naming conventions + SUIT CSS design principles;
• PostCSS + CSSNext. Future CSS syntax like variables, nesting, and autoprefixer are good enough;
• Flexbox is awesome. No need for grid framework;
• Normalize.css, base styles and variables are solid foundation for all components;

dcode

GitHub Flavored Asciidoc (GFA)