Rinat Abdullin abdullin

React Native

Set of components to allow describing native widgets as React components and rendering them natively. It allows to wrap native APIs (imperative mutative) with declarative immutable APIs of React.

React Native replaces the DOM renderers with native renderers which allows people to render platform <View>/<ScrollView>/<NativeWhatever> instead of <div>/<span>. Other than that, you get to use the exact same React API that you already know (even down to the event bubbling). You can bridge to things that are only available on the platform, and can in general make higher performance granular building blocks that cannot be accomplished with web technology (such as components that decode images more efficiently or with different concurrency models). As with everything, JSX is not required to take advantage of this - and you can use any of the compile-to-js languages that you use with React today.

It includes:

Go: The Good Parts

Go is a programming language initially developed by Google in 2007. It is a statically typed language with a simple syntax, resembling C or JavaScript. It features garbage collection, type safety and large standard library.

Go can be statically compiled into a single executable binary, which could target a large number of operating systems (from Linux and

I think, I heard term "Serving Architect" from a ThoughtWorks presentation. It can be described this way.

Somebody with an experience works with a team, eliminating bottlenecks and helping them to move forward in the project. Ideally he or she would have experience of multiple roles in a software project: architect (software designer), developer, tester, lead and manager; with technical hands-on expertise covering stacks used by the team. This way a serving architect can help and share experience with any role in the team, without interfering with the team dynamics.

Summary of the last argument at HappyPancake team about iPhone vs Google Nexus with @pjvds.

This discussion, unlike last discussions about Facebook Flux or JSON assertions, was over in 10 minutes.

iPhone is a product with premium design and polish. It is more expensive.
Google Nexus is a good product with similar hardware specs but less polish. It is less expensive.
Recent iOS updates make iPhones feel outdated slightly faster than recent Android changes.
App ecosystems of iPhone and Android are comparable. iPhone has a few more exclusive apps and apps are generally more expensive and polished. Android has more apps with lower quality on the average.

This is a response to Bill Fisher regarding experience with Flux:

@abdullin Also, can you clarify what you mean by "solution structure"? I am thinking about revising the examples soon.

Currently all flux samples (that I've seen) group files into folders based on technical similarity. For example, stores go with stores, action creators reside in the same folder shared with the other action creators.

This pattern works quite well for smaller projects. It feels especially good for the sample projects of various MVC frameworks, when you have just a bunch of controllers, models and views.

However, as we discovered on some production projects, such approach doesn't scale well. At some point you end up with dozens of technically similar files per folder and logically messy solution.

This is my response to an email asking about Domain-Driven Design in golang project.

Thank you for getting in touch. Below you will find my thoughts on how golang works with DDD, changing it. This is merely a perception of how things worked out for us in a single project.

That project has a relatively well-known domain. My colleagues on this project are very knowledgeable, thoughtful and invested in quality design. The story spelled out below is a result of countless hours spent discussing and refining the approach.

Conclusions could be very different, if there was a different project, team or a story-teller.

Short story

План моих докладов на ufa42conf в этот четверг 19:00 (updated)

Зарегистрироваться

30m : 5 Event-driven лайфхаков

Intro : Event-driven или reactive принципы
BDD и тестирование кода
Пусть код документирует себя
Простое масштабирование (latency + throughput)

	public sealed class RedirectToDynamicEvent
	{
	public readonly IDictionary<Type, List<Wire>> Dict = new Dictionary<Type, List<Wire>>();

	public sealed class Wire
	{
	readonly MethodInfo _method;
	public Type ParameterType;
	readonly object _subject;
	readonly bool _includeVersion;

	var client = require("shared/client");
	module.exports = function(context, payload, done) {
	if (payload.login === undefined) {
	throw new Error("Login must be defined");
	}
	if (payload.password === undefined) {
	throw new Error("Password must be defined");
	}

	context.dispatch("event:LoginStarted");

	"use strict";

	var createStore = require("fluxible/utils/createStore");


	var client = require("../client");
	var cookies = require("cookies-js");
	var debug = require("debug")("ClientTokenStore");
	var ClientTokenStore = createStore({
	storeName: "ClientSessionStore",