Kirill Pimenov kirushik

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;

What I Wish I'd Known About Equity Before Joining A Unicorn

Disclaimer: This piece is written anonymously. The names of a few particular companies are mentioned, but as common examples only.

This is a short write-up on things that I wish I'd known and considered before joining a private company (aka startup, aka unicorn in some cases). I'm not trying to make the case that you should never join a private company, but the power imbalance between founder and employee is extreme, and that potential candidates would

Achieving warp speed with Rust

Client-side software update verification failures

Exploitable vulnerabilities in client-side software update mechanisms that could have been mitigated by secure transport (TLS).

Contributions welcome. All text taken from the vulnerability descriptions themselves, with additional emphasis mine.

In scope:

I consider exploitation or privilege escalation of the package tool/system itself (that would have been mitigated by secure transport) to be in scope.
Issues only described as being triggered by malicious mirrors are assumed to also be vulnerable to MITM.
Failure to verify the software update at all is currently provisionally in scope if it could have been mitigated by secure transport, but I'm waffling about it. Most of these are actual signature verification failures, and my original purpose was to highlight cases where claims of "It's OK to be HTTP because verification!" seem to me to be specious.
Software components regularly used to verify integrity in other software pipelines a

	<html>
	<head>
	<title>Checkbox</title>
	<style>
	input[type=checkbox] {
	display:none;
	}

	input[type=checkbox] + label
	{

	package com.willowtreeapps.demo;

	import android.app.Activity;
	import android.os.Bundle;
	import android.view.KeyEvent;
	import android.view.Window;
	import android.webkit.WebView;
	import android.webkit.WebViewClient;

	public class MainActivity extends Activity {

	# Based on idan's script

	function _git_branch_name
	echo (command git symbolic-ref HEAD ^/dev/null \| sed -e 's\|^refs/heads/\|\|')
	end

	function _is_git_dirty
	echo (command git status -s --ignore-submodules=dirty ^/dev/null)
	end

	#!/usr/bin/env ruby
	require 'watir-webdriver'

	def log (message) puts " #{message}" end
	def success (message) puts "+ #{message}" end
	def fail (message) puts "- #{message}" end
	def notify (message)
	success message.upcase
	system 'osascript -e \'Display notification "Bürgerbot" with title "%s"\'' % message
	rescue StandardError => e

	macro_rules! query {
	($db:ident, $query:expr, [$($param:expr),*], {$($out_field:ident: $ty:ty),+ }) => ({
	#[derive(Debug, Clone)]
	#[allow(non_snake_case)]
	struct Output {
	$(
	$out_field: $ty,
	)+
	}

	(define-module (my packages)
	#:use-module ((guix licenses) #:prefix license:)
	#:use-module (gnu packages linux)
	#:use-module (guix build-system trivial)
	#:use-module (gnu)
	#:use-module (guix download)
	#:use-module (guix git-download)
	#:use-module (guix packages))

	(define (linux-nonfree-urls version)

Kirill Pimenov kirushik

What I Wish I'd Known About Equity Before Joining A Unicorn

Achieving warp speed with Rust

Contents:

Client-side software update verification failures

In scope: