В статье описывается подход к реализации на Java шаблона Активный объект, основанный на использовании аспектно-ориентированного расширения Java AspectJ и проекта Zephyr, добавляющего в Java легковесные потоки. Цель подхода — обойти недостатки существующих реализаций данного шаблона и сделать новую реализацию более прозрачной.

Активный объект — шаблон проектирования, который отделяет выполнение метода от его вызова. Шаблон позволяет повысить параллелизм и упростить синхронный доступ к объекту, который живет в собственном потоке.

Элементами шаблона являются Proxy (объект-заместитель), Method Request (запрос), Activation Queue (очередь), Scheduler (планировщик), Servant (обслуживающий объект) и Future.

Объект-заместитель предоставляет интерфейс, позволяющий клиентам вызывать публично доступные методы активного объекта использую стандартные, строго типизированные средства языка программирования вместо передачи слабо типизированных сообщений между потоками. Когда клиент вызывает метод, определяемый объектом-заместителем, создается запрос, который помещается в очередь. Все это происходит в клиентском потоке.

Запрос используется для передачи контекстной информации о вызове определенного метода, такой как параметры вызова, от объекта-заместителя планировщику, работающему в отдельном потоке. Для каждому метода активного объекта, предоставляемого объектом-заместителем, определяется конкретный подкласс абстрактного класса запроса. Экземпляры этих классов создаются объектом-заместителем, когда вызываются его методы, и содержат контекстную информацию, необходимую для того, чтобы выполнить эти методы и вернуть результаты обратно клиентам.

Очередь обеспечивает ограниченный буфер запросов, созданных объектом-заместителем и ожидающих выполнения. Очередь отделяет клиентский поток от потока обслуживающего объекта, поэтому два потока могут работать параллельно.

Планировщик работает в собственном потоке отличном от клиентских потоков и управляет очередью запросов, ожидающих выполнения. Планировщик решает, какой запрос извлечь из очереди следующим, чтобы выполнить его на обслуживающем объекте, реализующем соответствующий метод.

Обслуживающий объект определяет поведение и состояние активного объекта и реализует методы, определенные в объекте-заместителе и соответствующих запросах. Метод обслуживающего объекта вызывается, когда соответствующий запрос выполняется планировщиком, следовательно, обслуживающий объект выполняется в потоке планировщика.

Future позволяет клиенту получить результат вызова метода, после того как обслуживающий объект завершит выполнение этого метода. Когда клиент вызывает метод, Future возвращается клиенту сразу же. Для получения результата вызова клиент опрашивает или блокируется на Future до тех пор, пока результат не будет доступен.

В качестве примера реализации шаблона Активного объекта можно привести следующий код на Java.

public class NormalClass {      private double val = 0.0;      public void doSomething() {         val = 1.0;     }      public void doSomethingElse() {         val = 2.0;     } }  public class MyTask {      private double val;     private final BlockingQueue<Runnable> dispatchQueue = new LinkedBlockingQueue<>();      public MyTask() {         new Thread(new Runnable() {             @Override             public void run() {                 while (true) {                     try {                         dispatchQueue.take().run();                     } catch (InterruptedException e) {                         // okay, just terminate the dispatcher                     }                 }             }         }).start();     }      public void doSomething() throws InterruptedException {         dispatchQueue.put(new Runnable() {             @Override             public void run() {                 val = 1.0;             }         });     }      public void doSomethingElse() throws InterruptedException {         dispatchQueue.put(new Runnable() {             @Override             public void run() {                 val = 2.0;             }         });     } } 

В данном примере класс NormalClass преобразован в класс MyTask, который реализует активный объект, объединяя функциональность объекта-заместителя и обслуживающего объекта. Код методов оригинального класса перенесен в классы запросов, реализующих интерфейс Runnable, экземпляры которых помещаются в очередь при вызове методов активного объекта. Класс потока, играющий роль планировщика, извлекает запросы из очереди и выполняет их.

Один из недостатков данной реализации — необходимость переписывать классы, добавляя однотипный служебный код в конструкторы и методы, для того чтобы «превратить» эти классы в активные объекты. Другим недостатком является то, что каждому активному объекту соответствует отдельный поток Java. При росте числа активных объектов в приложении потоки, соответствующие этим объектам, будут иметь значительные суммарные накладные расходы на занимаемую память и процессорное время, связанное с их созданием и переключением контекстов.

Примером другой реализации шаблона является модуль Typed Actors (типизированные акторы) из инструментария Akka. Двумя составляющими типизированных акторов являются публичный интерфейс и внутренняя реализация. Типизированные акторы обеспечивают реализацию публичного интерфейса, которая делегирует вызовы методов внутренней реализации для асинхронного выполнения.

public interface Squarer {      void squareDontCare(int i); //fire-forget      Future<Integer> square(int i); //non-blocking send-request-reply      Option<Integer> squareNowPlease(int i); //blocking send-request-reply      int squareNow(int i); //blocking send-request-reply }  public class SquarerImpl implements Squarer {      @Override     public void squareDontCare(int i) {         int sq = i * i; //Nobody cares :(     }      @Override     public Future<Integer> square(int i) {         return Futures.successful(i * i);     }      @Override     public Option<Integer> squareNowPlease(int i) {         return Option.some(i * i);     }      @Override     public int squareNow(int i) {         return i * i;     } }  public class Main {      public static void main(String[] args) throws Exception {         ActorSystem system = ActorSystem.create();          Squarer mySquarer = TypedActor.get(system).typedActorOf(new TypedProps<>(Squarer.class, SquarerImpl.class));          mySquarer.squareDontCare(10);          Future<Integer> fSquare = mySquarer.square(10);          Option<Integer> oSquare = mySquarer.squareNowPlease(10);          int iSquare = mySquarer.squareNow(10);          assert Await.result(fSquare, Duration.create(3, TimeUnit.SECONDS)).intValue() == 100;          assert oSquare.get().intValue() == 100;          assert iSquare == 100;          TypedActor.get(system).stop(mySquarer);          system.shutdown();     } } 

Модуль скрывает детали реализации шаблона, но в то же время создание и уничтожение типизированных акторов осуществляется с помощью специальных средств библиотеки. Другой особенностью является то, что, если типизированному актору необходимо передать вовне ссылку на самого себя, вместо this требуется использовать ссылку на объект-заместитель, получаемую через вызов TypedActor.self().

Хотя типизированные акторы не имеют таких проблем с потоками как в предыдущей реализации, благодаря тому, что в их основе лежит система акторов Akka, использование блокирующих операций во внутренних реализациях ограничено, даже если это вызовы методов других типизированных акторов. Это обязывает проектировать публичные интерфейсы таким образом, чтобы их методы не были блокирующими. Это в свою очередь может, во-первых, нарушить совместимость с существующими клиентами, во-вторых, усложнить код из-за использования обратных вызовов.

В данной статье предлагается другой подход к реализации на Java шаблона Активный объект, основанный на использовании аспектно-ориентированного расширения Java AspectJ и проекта Zephyr, который добавляет в Java легковесные потоки. Цель описываемого подхода заключается в том, чтобы обойти недостатки существующих реализаций данного шаблона и сделать новую реализацию более прозрачной.

Пример

Проблема обедающих философов является классическим примером, используемым при разработке параллельных алгоритмов для иллюстрации проблем синхронизации и способов их решения.

Пять безмолвных философов сидят вокруг круглого стола, перед каждым философом стоит тарелка спагетти. Вилки лежат на столе между каждой парой ближайших философов.

Каждый философ может либо есть, либо размышлять. Приём пищи не ограничен количеством оставшихся спагетти — подразумевается бесконечный запас. Тем не менее, философ может есть только тогда, когда держит две вилки — взятую справа и слева.

Каждый философ может взять ближайшую вилку (если она доступна), или положить — если он уже держит её. Взятие каждой вилки и возвращение её на стол являются раздельными действиями, которые должны выполняться одно за другим.

Суть проблемы заключается в том, чтобы разработать модель поведения (параллельный алгоритм), при котором ни один из философов не будет голодать, то есть будет вечно чередовать приём пищи и размышления.

Данный пример позволяет продемонстрировать применение описываемого подхода.

@Active public class Philosopher {      private final String name;     private final Fork leftFork;     private final Fork rightFork;      public Philosopher(String name, Fork leftFork, Fork rightFork) {         this.name = name;         this.leftFork = leftFork;         this.rightFork = rightFork;     }      @Oneway     public void start() {         while (true) {             Fork.Handle left = leftFork.take();             if (left == null) {                 continue;             }              Fork.Handle right = rightFork.take();             if (right == null) {                 left.put();                 continue;             }              System.out.println(name + " starts to eat");             sleep(5000);              left.put();             right.put();              System.out.println(name + " starts to think");             sleep(5000);         }     }      private static void sleep(int millis) {         try {             Thread.sleep(millis);         } catch (InterruptedException ignored) {         }     } } 

Класс Philosopher, моделирующий философа, обозначен аннотацией Active и является активным объектом. Класс имеет ссылки на левую и правую вилки, поля leftFork и rightFork соответственно. Метод start, реализующий поведение философа, обозначен аннотацией Oneway, которая означает, что такой метод ничего не возвращает, и клиент, вызвавший этот метод, получает управление сразу же после вызова.

В начале цикла каждый философ пытается завладеть левой вилкой, вызывая метод take класса Fork. Если попытка неудачная, то возвращается null, и философ переходит к началу цикла. В случае успеха возвращается ссылка на экземпляр класса Fork.Handle, и философ переходит к попытке завладеть правой вилкой. В случае неудачи философ кладет кладет левую вилку, вызывая метод put класса Fork.Handle, и возвращается к началу цикла, иначе он переходит в режим ожидания. По окончании времени ожидания философ кладет обе вилки и опять ждет, после чего возвращается к началу цикла.

@Active public class Fork {      private boolean taken;      public Handle take() {         if (taken) {             return null;         }         taken = true;         return new Handle();     }      @Include     private void put() {         taken = false;     }      @Active     public class Handle {          private boolean used;          private Handle() {         }          public void put() {             if (used) {                 throw new IllegalStateException();             }             used = true;             Fork.this.put();         }     } } 

Класс Fork — это активный объект, моделирующий вилку. Поле taken указывает на то, свободна ли вилка или занята. Если вилка свободна, то есть значение поля taken равно false, метод take, реализующий взятие вилки, устанавливает это поле в true и возвращает экземпляр класса Fork.Handle, иначе возвращает null.

Класс Fork.Handle также является активным объектом, но в отличие от классов Philosopher и Fork создается динамически при вызове метода take. Освобождение вилки реализуется методом put данного класса, который отмечает объект Fork.Handle как использованный, устанавливая поле used в true, и делегирует вызов методу put класса Fork.

Аннотация Include, которой обозначен приватный метод put класса Fork, указывает на то, что этот метод должен выполняться в потоке активного объекта. Использование данной аннотации необходимо в связи с тем, что в классах, реализующих активные объекты, по умолчанию только публичные методы выполняются в потоке активного объекта.

public class Main {      public static void main(String[] args) throws InterruptedException {         Fork fork1 = new Fork();         Fork fork2 = new Fork();         Fork fork3 = new Fork();         Fork fork4 = new Fork();         Fork fork5 = new Fork();          Philosopher philosopher1 = new Philosopher("Descartes", fork1, fork2);         Philosopher philosopher2 = new Philosopher("Nietzsche", fork2, fork3);         Philosopher philosopher3 = new Philosopher("Kant", fork3, fork4);         Philosopher philosopher4 = new Philosopher("Hume", fork4, fork5);         Philosopher philosopher5 = new Philosopher("Plato", fork5, fork1);          philosopher1.start();         philosopher2.start();         philosopher3.start();         philosopher4.start();         philosopher5.start();          Thread.sleep(60000);     } } 

Из приведенного примера видно, что создание активных объектов не требует использования специальных средств и выполняется с помощью оператора new. При вызове методов активного объекта не используется ссылка на внешний объект-заместитель, и вызовы осуществляются по this. Также реализация шаблона подразумевает, что динамическое создание активных объектов не вызывает утечек памяти, так как уничтожение этих объектов, включая остановку потоков, происходит автоматически.

Реализация

Использование AspectJ дает нам возможность обойти такие недостатки существующих реализаций шаблона Активный объект, как необходимость в использовании объекта-заместителя и ссылок на него, специальных средств создания и уничтожения активных объектов, а также изменения интерфейсов существующих классов. Кроме того AspectJ позволяет сделать реализацию шаблона более прозрачной, скрыв детали в аспектах.

Начнем реализацию с добавления в аспект очереди запросов. Для этого нам понадобится объявить inter-type поле, содержащее ссылку на очередь. Делается это с помощью конструкции declare parents. Так как мы собираемся использовать аннотацию для обозначения активного объекта, то применим соответствующий шаблон типа для declare parents.

@Retention(RetentionPolicy.RUNTIME) @Target(ElementType.TYPE) public @interface Active { }  public aspect ActiveObjectAspect {      public interface ActiveObject {     }      declare parents: @Active * implements ActiveObject;      private BlockingQueue<Runnable> ActiveObject.queue = new LinkedBlockingQueue<>(); } 

В качестве планировщика будем использовать класс потока Java, в который передадим ссылку на очередь

final class ActiveObjectThread extends Thread {      private final BlockingQueue<? extends Runnable> queue;      ActiveObjectThread(BlockingQueue<? extends Runnable> queue) {         this.queue = queue;     }      @Override     public void run() {         while (true) {             Runnable task;             try {                 task = queue.take();             } catch (InterruptedException ignored) {                 continue;             }             task.run();         }     } } 

Далее необходимо стартовать поток, и делать мы это будем в конструкторе активного объекта. Для этого добавим соответствующий advice.

public aspect ActiveObjectAspect {      ...      after(ActiveObject obj) returning: initialization((ActiveObject+ && !ActiveObject).new(..)) && this(obj) {         new ActiveObjectThread(obj.queue).start();     } } 

Методы активных объектов в нашей реализации принадлежат двум типам: обычные и one-way методы. Обычные методы, как правило, имеют возвращаемое значение, и при их вызове клиент блокируется до завершения выполнения метода. One-way методы не имеют возвращаемого значения, и клиент получает управление сразу же после вызова, а метод продолжает выполняться асинхронно.

Общая идея реализации advice методов активного объекта заключается в применении так называемого шаблона worker object, суть которого состоит в переносе вызова proceed в анонимный класс, что позволяет выполнять метод асинхронно.

Ниже приведена реализация advice для one-way метода. Анонимный класс, реализующий интерфейс Runnable, играет роль класса запроса.

@Retention(RetentionPolicy.RUNTIME) @Target(ElementType.METHOD) public @interface Oneway { }  public aspect ActiveObjectAspect {      ...      void around(final ActiveObject obj): execution(@Oneway void ActiveObject+.*(..)) && this(obj) {         Runnable task = new Runnable() {             @Override             public void run() {                 try {                     proceed(obj);                 } catch (Throwable e) {                     e.printStackTrace();                 }             }         };          boolean interrupted = false;         try {             while (true) {                 try {                     obj.queue.put(task);                     break;                 } catch (InterruptedException ignored) {                     interrupted = true;                 }             }         } finally {             if (interrupted) {                 Thread.currentThread().interrupt();             }         }     } } 

Все исключения, возникающие в one-way методах, просто логируются, так как нет возможности вернуть их клиенту.

Обычные методы активных объектов в отличие от one-way возвращают значения, поэтому в реализации advice для таких методов вместо Runnable используется класс FutureTask и анонимный класс, реализующий интерфейс Callable.

public aspect ActiveObjectAspect {      ...      Object around(final ActiveObject obj): execution(!@Oneway * ActiveObject+.*(..)) && this(obj) {         RunnableFuture<?> task = new FutureTask<>(new Callable<Object>() {             @Override             public Object call() throws Exception {                 return proceed(obj);             }         });          boolean interrupted = false;         try {             while (true) {                 try {                     obj.queue.put(task);                     break;                 } catch (InterruptedException ignored) {                     interrupted = true;                 }             }         } finally {             if (interrupted) {                 Thread.currentThread().interrupt();             }         }          try {             interrupted = false;             try {                 while (true) {                     try {                         return task.get();                     } catch (InterruptedException ignored) {                         interrupted = true;                     }                 }             } finally {                 if (interrupted) {                     Thread.currentThread().interrupt();                 }             }         } catch (ExecutionException e) {             throw e.getCause(); // ошибка компиляции         }     } } 

В результате выполнения методов могут возникать исключения, которые будут выброшены при вызове метода get класса FutureTask. Так как в общем случае это проверяемые исключения, которые объявлены в методе активного объекта, но не в advice, выбрасывание таких исключений из advice приведет к ошибке компиляции. Для того чтобы обойти данное ограничение, можно использовать особенность реализации generics в Java, позволяющую выбрасывать проверяемые исключения из методов, в которых эти исключения не объявлены.

public aspect ActiveObjectAspect {      ...      Object around(final ActiveObject obj): execution(!@Oneway * ActiveObject+.*(..)) && this(obj) {         ...          try {             ...         } catch (ExecutionException e) {             throw ActiveObjectAspect.<RuntimeException>throwException(e.getCause());         }     }      @SuppressWarnings("unchecked")     private static <E extends Throwable> E throwException(Throwable exception) throws E {         throw (E) exception;     } } 

Активные объекты как и любые объекты Java автоматически удаляются из памяти сборщиком мусора, когда становятся недостижимыми. Но даже после сборки активного объекта его поток остается жить, так как работающие потоки не считаются недостижимыми, и, соответственно, не удаляются сборщиком мусора.

Поскольку мы не хотим останавливать поток активного объекта вручную, необходимо каким-то образом связать остановку потока с удалением активного объекта. Один из способов сделать это — поместить код остановки потока в метод finalize активного объекта, правда есть серьезные аргументы против использования finalize, связанные с производительностью. Поэтому мы будем использовать фантомные ссылки, которые предоставляют более гибкий и безопасный способ очистки ресурсов.

public interface Disposable {      void dispose(); }  public final class Disposer {      private final ReferenceQueue<Object> referenceQueue = new ReferenceQueue<>();     private final Map<Object, Disposable> disposables = new ConcurrentHashMap<>();      public Disposer() {         DisposerThread thread = new DisposerThread(referenceQueue, disposables);         thread.setName(Disposer.class.getSimpleName());         thread.setDaemon(true);         thread.start();     }      public void register(Object obj, Disposable disposable) {         Objects.requireNonNull(obj);         Objects.requireNonNull(disposable);         disposables.put(new PhantomReference<>(obj, referenceQueue), disposable);     }      private static final class DisposerThread extends Thread {          private final ReferenceQueue<?> referenceQueue;         private final Map<?, ? extends Disposable> disposables;          DisposerThread(ReferenceQueue<?> referenceQueue, Map<?, ? extends Disposable> disposables) {             this.referenceQueue = referenceQueue;             this.disposables = disposables;         }          @Override         public void run() {             while (true) {                 Reference<?> reference;                 try {                     reference = referenceQueue.remove();                 } catch (InterruptedException ignored) {                     continue;                 }                 Disposable disposable = disposables.remove(reference);                 try {                     disposable.dispose();                 } catch (Throwable e) {                     e.printStackTrace();                 }             }         }     } } 

Класс Disposer позволяет регистрировать ссылку на объект, в результате уничтожения которого будет вызван метод dispose интерфейса Disposable. В нашем случает регистрируемым объектом является активный объект, а ресурсом, реализующим метод dispose, — поток активного объекта.

final class ActiveObjectThread extends Thread implements Disposable {      ...      volatile boolean running;      @Override     public void run() {         while (running) {             ...         }     }      @Override     public void dispose() {         running = false;         interrupt();     } } 

Регистрацию ссылка на активный объект поместим в advice конструктора.

public aspect ActiveObjectAspect {      ...      private static final Disposer disposer = new Disposer();      after(ActiveObject obj) returning: initialization((ActiveObject+ && !ActiveObject).new(..)) && this(obj) {         ...         disposer.register(obj, thread);         thread.start();     }      ... } 

В связи с тем, что активный объект может иметь поля, которые не являются final или volatile, а конструктор и методы активного объекта выполняются в разных потоках, необходимо обеспечить видимость значений этих полей потоке активного объекта. Для этого можно использовать поле running класса ActiveObjectThread, сделав запись в это поле в advice конструктора. Это гарантирует, что значения полей активного объекта, заданные в конструкторе, будут видны в потоке активного объекта.

public aspect ActiveObjectAspect {      ...      after(ActiveObject obj) returning: initialization((ActiveObject+ && !ActiveObject).new(..)) && this(obj) {         ...         thread.running = true;         thread.start();     }      ... } 

В результате применения аспектно-ориентированного подхода мы получили реализацию шаблона Активный объект, лишенную многих недостатков существующих реализаций. Нерешенной остается проблема использование потоков Java, которую мы устраним с помощью проекта Zephyr, реализующего подключаемые потоки.

Один из модулей Zephyr реализует легковесные потоки, которые можно подключить к приложению, не меняя исходного кода. Необходимо только изменить процесс сборки приложения.

Добавим в исходный POM-файл несколько плагинов.

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"          xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">     <modelVersion>4.0.0</modelVersion>      ...      <build>         <plugins>             ...             <plugin>                 <groupId>org.jvnet.zephyr.maven</groupId>                 <artifactId>remapping-maven-plugin</artifactId>                 <configuration>                     <outputDirectory>${project.build.directory}/remapping-classes</outputDirectory>                     <testOutputDirectory>${project.build.directory}/remapping-test-classes</testOutputDirectory>                     <mappingEntries>                         <mappingEntry>                             <oldName>java/lang/Thread</oldName>                             <newName>org/jvnet/zephyr/jcl/java/lang/Thread</newName>                         </mappingEntry>                         <mappingEntry>                             <oldName>java/util/concurrent/FutureTask</oldName>                             <newName>org/jvnet/zephyr/jcl/java/util/concurrent/FutureTask</newName>                         </mappingEntry>                         <mappingEntry>                             <oldName>java/util/concurrent/LinkedBlockingQueue</oldName>                             <newName>org/jvnet/zephyr/jcl/java/util/concurrent/LinkedBlockingQueue</newName>                         </mappingEntry>                     </mappingEntries>                 </configuration>                 <executions>                     <execution>                         <goals>                             <goal>remapping</goal>                             <goal>testRemapping</goal>                         </goals>                     </execution>                 </executions>             </plugin>             <plugin>                 <groupId>org.jvnet.zephyr.maven</groupId>                 <artifactId>javaflow-maven-plugin</artifactId>                 <configuration>                     <classesDirectory>${project.build.directory}/remapping-classes</classesDirectory>                     <testClassesDirectory>${project.build.directory}/remapping-test-classes</testClassesDirectory>                 </configuration>                 <dependencies>                     <dependency>                         <groupId>org.jvnet.zephyr.thread</groupId>                         <artifactId>thread-api</artifactId>                         <version>${zephyr.version}</version>                     </dependency>                     <dependency>                         <groupId>org.jvnet.zephyr.jcl</groupId>                         <artifactId>jcl-jdk7</artifactId>                         <version>${zephyr.version}</version>                     </dependency>                 </dependencies>                 <executions>                     <execution>                         <goals>                             <goal>javaflow</goal>                             <goal>testJavaflow</goal>                         </goals>                     </execution>                 </executions>             </plugin>             <plugin>                 <artifactId>maven-jar-plugin</artifactId>                 <executions>                     <execution>                         <id>javaflow</id>                         <goals>                             <goal>jar</goal>                         </goals>                         <configuration>                             <classifier>javaflow</classifier>                             <classesDirectory>${project.build.directory}/javaflow-classes</classesDirectory>                         </configuration>                     </execution>                 </executions>             </plugin>         </plugins>     </build> </project> 

Плагин remapping-maven-plugin переназначает используемые в реализации классы Thread, FutureTask и LinkedBlockingQueue на соответствующие классы с поддержкой подключаемых потоков. Плагин javaflow-maven-plugin добавляет в методы поддержку продолжений из проекта Commons Javaflow, которая требуется модулем Zephyr, реализующим легковесные потоки.

Теперь при запуске приложения достаточно добавить в classpath соответствующие библиотеки, для того чтобы активные объекты начали использовать легковесные потоки вместо обычных.

Полную версию реализации шаблона Активный объект, поддерживающую включение и исключение методов, наследование классов активных объектов, различные типы очередей и таймауты, а так же пример использования, можно найти здесь и здесь.

ссылка на оригинал статьи http://habrahabr.ru/post/256705/

Привет! Мы SplitMetrics и хотим рассказать о сервисе для тестирования визуальных элементов и копирайта страниц мобильных приложений в апп сторах. Мы прогнали через тесты уже более 1 млн. пользователей и начали понимать, какие элементы на страницах важны и какие фишки работают…

Наша история началась с того, что Apple прислал запрос на Promotional Art Work для фичеринга нашего приложения. Мы долго не могли выбрать вариант, который бы устраивал всех и привел бы максимальное количество скачек. Часы обсуждений привели к тому, что мы залили некий компромисный вариант, не понимая насколько он будет эффективным. Фичерение дало нам хорошее число установок, но мы чуствовали, что не максимальное. Ответ пришёл сам собой: наша страница в App Store просто не смогла “продать” приложение. Изучив рынок, мы поняли, что никто не готов нам помочь и выдать готовый сервис для предварительного тестирования различных вариантов страниц в App Store или Google Play. Тогда мы решили сделать такой сервис для себя и всех, кто любит считать конверсию.

Зачем проводить a/b тесты для App Store и Google Play?

В вебе a/b тестированием сегодня мало кого удивишь. Любой уважающий себя сайт тестирует варианты посадочных страниц, форм и тд. С мобильными приложениями всё намного сложнее: чтобы заменить любой графический элемент на странице, нужно перезаливать билд и около 7 дней ждать одобрения от команды App Store. SplitMetrics упрощает процесс и позволяет протестировать элементы дизайна и копирайта без того, чтобы заливать их прямо в App Store и проверять в боевых условиях.

У команд мобильных разработчиков всегда есть множество идей, как должны выглядеть странички в App Store: какие могут быть иконки, скриншоты, описания и прочие элементы. Каждый из этих элементов влияет на конверсию, которая зависит от того, насколько хорошо удалось рассказать и показать, зачем нужен продукт и что он собой представляет. Увеличение конверсии поднимет приложение в поисковой выдаче App Store и Google Play, поможет существенно снизить затраты на трафик и увеличить количество органического трафика.

Что можно тестировать?

Сейчас можно проводить эксперименты со страничками приложений для iPhone, iPad и Android. Можно проверять, как влияют на конверсию следующие элементы:

• иконку продукта
• варианты скриншотов или их порядок
• описание приложения
• название
• стоимость приложения
• видео превью
• рейтинг приложения и число отзывов
• наличие или отсутствие ярлыка внутриигровых покупок (Offers in-app purchases)
• необходимость делать перевод на локальный язык
• интеграция с Apple Watch (в разработке)

Можно выяснить, насколько важно наличие видео на странице вашей игры. Либо какое описание более эффективно “говорит” с пользователем. Проверить, меняет ли показатели конверсии порядок и визуальна составляющая скриншотов. Успешные производители мобильных приложений, например, оптимизируют иконки ещё до их запуска в апп стор.

Как это работает?

Простота использования позволяет пользоваться веб-приложением как разработчикам, так и маркетологам, специалистам по user acquisition. Процесс занимает всего пару минут. SplitMetrics загружает страницу по ссылке из апп стора. С помощью простого конструктора можно создать альтернативные версии страничек, отличающиеся одним элементом. За пару секунд система сгенерирует посадочные страницы — точные копии страниц в апп-стор. Остаётся направить трафик и ждать результатов. Приложение собирает аналитику пользовательского поведения и показывает, какая версия приложения работает лучше.

Интуиция или данные экспериментов?

Сегодня для любого продукта, в т.ч. и мобильного, важно суметь выделиться и донести свою идею до аудитории. Есть всего 3-4 секунды на то, чтобы убедить пользователя выбрать конкретное приложение: иконка, название, скриншоты и общее впечатление должны “говорить” на его языке и быть кристально понятными. SplitMetrics предоставляет уникальную возможность принимать эффективные решения на основании данных экспериментов — ещё до запуска продукта узнавать, что действительно “зацепит” представителя целевой аудитории, и оптимизировать существующий продукт, чтобы добиться максимальной прибыли.

Пока мы находимся в бета-версии и пользоваться платформой можно бесплатно. Регистрируйтесь на splitmetrics.com, а в комментариях пишите вопросы. Будем очень благодарны за обратную связь.

ссылка на оригинал статьи http://habrahabr.ru/post/256711/

С приходом каждого нового кризиса в современной России вспоминают об импортозамещении. Однако, сегодня, к уже характерному признаку тяжёлых времён — обвалу рубля, добавились ещё и западные санкции. Они угрожают добыче нефти не только на шельфе, но и на традиционных месторождениях. С учетом скрытого импорта, при оказании услуг российскими «дочками» зарубежных компаний, доля импортного оборудования и технологий достигает 80%, а по отдельным проектам может превышать 90%.
“Уже в среднесрочной перспективе существует риск снижения производства” — признал Минпромторг и постановил снизить эту зависимость к 2018–2020 хотя бы до 50-60%, а к совсем близкому 2035 и вовсе довести до 10 процентов. Всё это хорошо, но причём же здесь IT скажете вы? А вот посмотрите на диаграмму.

Это удивительно, но если верить Минпромторгу, наибольшая доля западного продукта наблюдается далеко не в трубах и даже не в оборудовании для шельфового бурения. Сильнее всего нефтяники зависят от импорта насосно-компрессорного оборудования, оборудования для геолого- и сейсморазведки, программно-аппаратных комплексов и систем автоматизации, оборудования и технологий для морского бурения…
Наши власти понимают опасность такой ситуации и даже начали принимать превентивные меры ещё до наступления кризиса. В результате сегодня общий объём ежегодной государственной поддержки гражданских исследований и разработок, по словам господина Медведева, составляет более 370 млрд рублей. В рамках этого процесса началось выполнение целого ряда «дорожных карт» по приоритетным направлениям, которые носят межотраслевой характер. Напомню, что на почётном шестом месте списка этих направлений расположились “высокие технологии в топливно-энергетическом комплексе”. Значит есть шанс на взрывной рост высокотехнологичных стартапов в стратегической нефтяной промышленности?
В данной статье я попробую разобраться в этом подробнее, взглянув на сложности внедрения высоких технологий в нашу нефтяную отрасль через призму своего восьмилетнего опыта разработки электроники для стартапов в данной сфере и даже рискну дать несколько непрошенных советов тем, кто готов попытать счастья на этом поприще.

Ещё пару вёдер мёда в нашу бочку!

Ещё немного магии речей высших лиц и денежных потоков:
Дворкович утверждает, что за достаточно ограниченные сроки в России удалось создать в целом базовую инфраструктуру поддержки разработок по приоритетным направлениям. Помимо «Сколково» поддержкой инновационных проектов у нас занимаются и Российская венчурная компания, и «Роснано», и Внешэкономбанк в части своей компетенции, и Фонд содействия инновациям, и целый ряд других институтов.

На продукцию, которую ещё предстоит разработать, для машиностроительных предприятий ТЭК должен быть направлен объем инвестиций в 2,5 трлн долл. к 2035 году. Уже сегодня 60 компаний с государственным участием реализуют программы инновационного развития с объёмом финансирования более 1 трлн 300 млрд рублей. Задача, которую они пытаются решить такой ценой, — обеспечить рост инвестиций в исследования и за счёт этого повысить производительность труда.
Лично у меня уже закружилась голова от количества нулей. Цифры выделяемые у нас на инновации оказываются сравнимы со святая святых — военным бюджетом! Дело за малым — освоить их с пользой для Родины, ну и себя не забыть… Начать, наверное, стоит с поиска задач, ожидающих решений?

Всё ли уже придумали до нас?

Для того чтобы начать разработку надо как минимум найти актуальную проблему, которую есть шанс решить затратив разумное количество сил и средств. Понятно, что спроектировать буровую для добычи в Арктических льдах до 2018 года с бюджетом в несколько сотен миллионов вряд ли получится. Но не стоит отчаиваться, далеко не всё так плохо, ведь даже на стадии первичной обработки нефти, где мне пришлось поработать, для ITшника и электронщика до сих пор имеется масса нерешённых задач. Либо существующие решения весьма ненадёжны.

Вот всего три серьёзные проблемы с которыми приходится сталкиваться:
Как известно уже даже нашим прокурорам, (помните как Ходорковский демонстрировал в суде трёхлитровку с загадочной жидкостью) из подавляющего большинства скважин извлекается не чистая нефть, а некая субстанция, представляющая из себя смесь как минимум трёх компонентов — солёной воды, газа и собственно самой нефти. В зависимости от специфики, в этой скважной жидкости может наблюдаться большое количество других примесей (вплоть до песка), которые сильно осложняют процесс нефтепереработки. На большинстве активных сегодня отечественных месторождениях содержание нефти находится в пределах от 85 до 15 процентов. Если скважина находится в легкодоступном месте и нефть содержит мало вредных примесей, то разработка может вестись вплоть до 8 процентного содержания, но это можно скорее считать исключением из правил. Как правило, скважины не стоят одиноко в чистом поле, а формируют куст. Трубопроводы от нескольких близкорасположенных скважин объединяются в один, и через него продукт поступает на первичную переработку. Эффективность и длительность работы скважины достаточно сильно зависит от режима её работы, а для того чтобы правильно его настроить очень желательно знать процентное содержание газа, нефти и воды на выходе КАЖДОЙ из скважин. Так вот, как это не удивительно, но проблема определения этого соотношения “на лету”, то есть в режиме он-лайн, до сих пор не имеет удовлетворительного решения. А ведь большинство скважин работают автономно и ставить около каждой лабораторию или даже постоянно отливать пробы в пробирки и возить их в лабораторию крайне неприятное и не дешёвое занятие. Кстати, эту задачу пытался решить первый мой стартап.
Пойдём по цепочке дальше. Скважная жидкость, в большинстве случаев, из трубы попадает в отстойники, цель которых отделить нефть от газа, снизить содержание воды процентов до двух или ниже и уменьшить солёность до приемлемого значения. И вот тут мы сталкиваемся с новыми проблемами.
Во-первых, утилизация попутного газа. Просто сжигать в факелах нерачительно и очень неэкологично, а применить в полезных целях оказывается совсем непросто! Мешает большая влажность и зловредные примеси, большую и дорогостоящую установку при таких объёмах ставить нерентабельно.
Во вторых, казалось бы уже совсем тривиальная задача – определить границу раздела фаз в отстойнике. То есть границы, выше которых находится нефть с нужным нам содержанием воды и ниже которой относительно чистая вода, которую можно сливать. Казалось бы, чего может быть проще, но несмотря на то, что существуют сотни приборов, основанных на совершенно разных принципах работы, с этим постоянные проблемы. В большинстве установок до сих пор вынуждены применять в качестве чувствительных элементов архаические поплавки! С этим связаны огромные проблемы, особенно в месторождениях с повышенной вязкостью или большим количеством вредных примесей. Поплавки быстро обрастают отложениями, из за которых нарушается их баланс. Временами их элементарно начинает заклинивать. Данную проблему мы решали во втором моём проекте.
Продолжать можно долго, но надеюсь, я уже успел убедить вас в том, что есть ещё чем заняться инноваторам даже в самой что ни наесть традиционной нефтяной отрасли, про сланцевую добычу я вообще молчу.

Лучшая стратегия — правда?

Итак, допустим первый этап пройден, вы нашли себе актуальную задачу, которая Вам по плечу и уже понимаете, что способны её решить. Следующий шаг естественно показать потенциальным инвесторам и клиентам какими неоспоримыми преимуществами будет обладать ваш прибор по сравнению с уже существующими на рынке аналогами. Ну вот мы и добрались до первых проблем!
Когда вы покупаете на радиорынке копеечный китайский тестер, то во многих случаях точность его показаний является даже выше паспортной, по крайней мере пока батарейки свежие, гнёзда для щупов сохраняют контакт и он не начал разваливаться как почти любое китайское барахло. Естественно стоит ожидать, что в такой зарегулированной сертификатами отрасли, как промышленная автоматизация всё гораздо серьёзнее… Я тоже так считал поначалу. И… сильно заблуждался.
Как это не удивительно, совершенно в порядке вещей следующие истории:

• Инновационный израильский ультразвуковой трёхмерный сканер за десяток тысяч долларов жутко глючит, а процесс передачи данных от него зависает чаще, чем мобильный интернет в Усть-Урюпинской электричке если она конечно до сих пор не оптимизирована.
• Американский газогенератор, который стоит ещё на порядок дороже, при сжигании попутного газа выходит из строя с периодичностью раз в несколько месяцев.
• Американский сенсор для определения обводнённости нефти, от фирмы, которая если верить рекламным проспектам уже 20 лет является лидером в этой области, не только не даёт обещанной точности в 1 процент во всём диапазоне, а даже не годится в качестве датчика раздела фаз – толком не может определить где кончается эмульсия, а где начинается вода для большинства месторождений.

Наиболее честными производителями на мой взгляд являются немцы. Однако даже надпись “Made in Germany” не гарантирует от того, что супер навороченный радар, стоимостью превышающий десятку тысяч евро, настроенный летом на определение верхней границы каменноугольной смолы, зимой, когда уровень пара в ёмкости значительно повышается, не сойдёт с ума. Кстати, это ещё одна казалось бы простейшая нерешённая задача. На Губахинском коксохиме проблема эта решается до сих пор чрезвычайно инновационным образом — на высоченный бак периодически залезает “дядя Вася” и опускает в ёмкость на длинном тросе кусок трубы с примотанной к нему мощной лампочкой. Потом поднимает и измеряет расстояние до полученной на трубе метки рулеткой.
Для меня остаётся загадкой — каким образом все эти приборы проходят сертификацию? Честно говоря, считал раньше, что у буржуев этот процесс намного строже нашего, но судя по тому, насколько порой заявленные характеристики приборов отличаются от реальных, это не так. Возможно они проводят сертификацию исключительно в идеальных лабораторных условиях. Возможно, как у нас зачастую, необходимость всесторонних испытаний заменяют толстой пачкой приятно шуршащих купюр и залихвацким банкетом.
Не стоило бы тратить на эти нюансы столько печатных знаков, если бы у данного факта не было нескольких неприятных следствий:
Во-первых, столкнувшись с подобными историями и выбросив кучу денег в трубу, руководители крупных компаний становятся прожжёнными консерваторами. По их настоянию создаются списки доверенных поставщиков и компании не включённой в этот пул практически невозможно осуществлять продажи.
Во вторых, лично для меня совершенно не ясно какие характеристики заявлять у разрабатываемого тобой прибора? Допустим, он даёт точность не 1, а 5 процентов, но устойчиво работает в таких экстремальных условиях, в которых другие не способны обеспечить сколь-нибудь вменяемого результата. Eсли ты честно упоминаешь в презентации своего прибора про эти 5 процентов, то вызываешь гнев своих маркетологов и недоумение инвесторов. Да и потенциальные клиенты удивляются, зачем им предлагают приборы, которые по характеристикам на порядок хуже уже существующих аналогов? Если же обещать невыполнимое, то уже на этапе “полевых испытаний” можно получить отрицательный отзыв от клиента.
Как решается эта дилемма я не знаю.

Сертификация взрывозащиты. Тут всё по взрослому!

Создавая приборы для нефтянки всегда нужно помнить о том, что в подавляющем большинстве случаев ваше устройство будет находиться во взрывоопасной зоне, а это значит, что в числе других ОБЯЗАТЕЛЬНО потребуется сертификат взрывозащиты. С получением этого документа наблюдается картина совсем отличная от сертификации на средство измерения или электромагнитную совместимость, где бал правит золотой телец. Никому не хочется быть крайним в ситуации, когда на воздух взлетает буровая, а тем более нефтехимический завод. Халтура не пройдёт. Это не значит, что у вас не будет возможности потратить на этот процесс дополнительные деньги. Добрые самуретяне из сертифицирующей организации с удовольствием помогут внести необходимые изменения в корпус или подобрать правильную искрогасящую цепь, разумеется не бесплатно.

Если вы с самого начала не определили в какой взрывоопасной зоне будет работать ваш прибор и не начали вести разработку с учётом подходящего типа взрывозащиты, в большинстве случаев вас ждут серьёзные дополнительные финансовые затраты на этапе когда “почти всё уже готово”. В отдельном случае может потребоваться просто переделывать весь проект с чистого листа. Поверьте, это очень серьёзно!

Кадры решают всё.

Крайне желательно иметь в команде двух-трёх человек с опытом разработки или хотя бы работы в данной отрасли, знающих нюансы. А их будет очень много, поверьте. Так электронщику придётся пытаться подогнать своё устройство под жёсткие требования искрогасящих цепей, а если это невозможно, то стараться вписаться в рамки, обусловленные применением корпусов со взрывонепроницаемой оболочкой.
Ещё большим камнем преткновения может стать корпус для конструкторов. Так у меня случилось в первом стартапе. Несмотря на то, что его у нас разрабатывали опытные конструкторы, когда дело дошло до сертификации на взрывозащиту, прошлось пройти пять итераций испытаний взрывом, после каждой из которых проводились доработки согласно предложениям опытных экспертов. На это ушло огромное количество времени и денег. Если бы при проектировании изначально была учтена конструкция аналогов со сходными габаритами, то вряд ли потребовалось бы более двух итераций.
Если существует возможность, лучше всего подобрать корпуса из стандартного ряда и уже с учётом их размеров проектировать электронику, но даже в этом случае возникнет масса проблем, например, с подбором кабельных вводов и типа кабеля… Герметичный корпус требует применения особых мер по борьбе с возникновением конденсата и его последствиями. Эксплуатация в условиях северных территорий заставляет крайне ответственно отнестись к надёжной работе в условии низких температур. Кстати, серьёзной проблемой может стать не только переохлаждение, но и перегрев под действием прямых солнечных лучей.
Проект разработки нового высокотехнологического оборудования для нефтепереработки весьма затратное занятие, по сравнению со стартапом в области IT… Нужны большие деньги на многочисленные сертификаты, организацию опытных испытаний и, наконец, налаживание производства. Поэтому не стоит экономить на опытных специалистах со специальным образованием. Впрочем, и молодёжь в качестве инъекции свежей крови, конечно, не помешает.

После того как закончены лабораторные испытания на масле, ваш прототип ждёт следующий этап. Испытание на специально созданном лабораторном стенде с реальной скважной жидкостью всеми правдами и неправдами вывезенной с объекта. И вот, когда вы пытаетесь довести качество определения нужного вам параметра до совершенства, а инвестор окончательно теряет терпение, дело непременно дойдёт до этапа опытной эксплуатации. Это очень ответственный и сложный момент.
Бывает совсем не просто уговорить людей на местах поставить ваш прибор на испытания пока вы не имеете, по крайней мере, сертификата взрывозащиты. А получить его можно уже на законченное изделие. Если же вы затрачиваете массу времени и денег сертифицируя образец, то в случае внесения изменений придётся проходить процедуру повторно! Замкнутый круг. Реальная жизнь очень сильно отличается от экспериментов в лаборатории и преподносит много неожиданных сюрпризов.

“Дядя Коля” может сковырнуть клемник при подключении кабеля к прибору, может сорвать резьбу. Соединительный кабель может оказаться длиннее чем вы рассчитывали или совсем не того типа. В отстойниках обеднённых месторождений и месторождений с высоким содержанием нефти могут происходить весьма отличные друг от друга процессы. Имеющийся в наличии источник питания номиналом 24 вольта может выдавать все сорок при небольшом токе нагрузки… Неожиданные крупные и мелкие пакости поджидают вас буквально на каждом шагу. В такой ситуации очень важен человеческий фактор.
Скорее всего, в командировке самое непосредственное участие придётся принимать разработчику оборудования. Это огромный стресс для людей технического склада ума и характера. Очень сложно днём проводить эксперимент за экспериментом под надзором любопытных аборигенов и их нетерпеливого начальства, а вечером лихорадочно править ошибки в коде, ставя заплатки невилирующие неожиданные процессы в резервуаре. Нужно сделать всё возможное чтобы наладить хорошие отношения с местными КИПовцами. Разговоры по душам на технические и отвлечённые темы, а также мелкие, но полезные в повседневной деятельности подарки, типа японских бокорезов или карманного RLC метра очень помогают налаживать взаимоотношения, что с лихвой окупится впоследствии.
Командировки имеют обыкновение затягиваться, при этом приходится более недели проводить в ужасном режиме – днём искать причину некорректной работы и пытаться подручными средствами устранять физические неисправности, а по ночам править код зачастую в условиях далёких от идеальных. Самое экстремальное, что мне пришлось испытать — проживание в комнате, предназначенной для отдыха рабочей смены. Проходной двор, лица меняются каждые два часа. Кому то хочется посмотреть телевизор, кому поболтать, кому портянки посушить… И так всю ночь. А рано утром вставать и на объект, при том, что дорога от Москвы до объекта заняла почти сутки и у тебя едет крыша от разницы во времени.
Если уж никуда от этого не деться, нужно хотя бы постараться минимизировать ущерб. В командировку желательно ездить минимум вдвоём. Один человек при этом решает технические вопросы, а второй организационные. Договаривается о доступе на объект, отвлекает местное начальство разговорами, выбивает бумажки для взятия проб в лаборатории или разрешения на временную остановку системы управления или изменения параметров на близкие к критическим, чтобы проверить реакцию прибора на серьёзные отклонения…
Ну и хороший совет – не жалеть средств на поощрение сотрудников, участвующих в пусконаладочных работах, особенно в случае удачного исхода. Иначе их будет крайне трудно заслать туда в следующий раз.

Национальные особенности.

Энергодобывающая отрасль сейчас живёт в условиях госкапитализма. С одной стороны, это понижает уровень конкуренции, с другой, теоретически может помочь с выходом на рынок.
В последние годы ведущие в области нефте-газодобычи компании, такие как Роснефть, Лукойл, Башнефть, Газпром имеют разнарядку на внедрение инноваций. На практике это выражается в том, что на местах имеются лица, ответственные за инновации. Они пытаются побудить рядовых сотрудников к внесению разного рода рацпредложений и оказывают содействие для их последующего внедрения. Самые перспективные, с их точки зрения, идеи направляются выше по служебной лестнице, где на основе их пытаются организовать разработку нового оборудования. Система сильно забюрократизирована и работает с большим скрипом, тем не менее можно попытаться воспользоваться этим механизмом чтобы наладить партнёрские отношения для продвижения своего проекта.
Мы пытались, но получили неожиданный результат. Выяснилось, что в недрах Лукойла родился проект решения той же задачи над которой работали мы. Их вариант выходил более дорогим и менее надёжным, но в него была уже вложена энная сумма денег и не смотря на то, что работы по нему фактически зашли в тупик, принять участие в финансировании нашего проекта они уже не имели возможности.
В последнее время в регионах как грибы на дрожжах растут различного рода технопарки для организации частно-государственного партнёрства, однако на практике воспользоваться их услугами для развития серьёзного проекта весьма сложно. Во-первых, получить серьёзную сумму весьма сложно. Во вторых, условия на которых деньги предлагаются нельзя назвать особо привлекательными. Разговор ведётся примерно в таком ключе:
Нужны деньги? Дадим пару-тройку миллионов на сертификацию опытного образца и проведения испытаний, но при условии, что ты сам вложишь столько же. Да, и мы хотим за это половину твоего бизнеса. Ах ты уже вложил 5 миллионов на разработку и ещё миллионов 10 потребуется на организацию производства. А нас это не касается. Кому вообще деньги нужны тебе или нам. Раз тебе, то это твои проблемы.
Таких аппетитов однако не имеют самые зубастые акулы венчурного бизнеса на Диком Западе. Но это было бы ещё пол беды, если бы не наши славные органы. Они бдительно наблюдают за тем, чтобы деньги были возвращены в срок, а производство изделия было запущено не позже назначенного часа икс. У тебя не получилось? Значит ты мошенник братец и место тебе в казённом доме, а не в рядах стартаперов…

Угроза Великой Китайской Экспансии.

Импортозамещение дело хорошее, но это дело будущего, пусть даже ближайшего, если верить самым оптимистичным прогнозам. На то чтобы довести изделие до промышленного образца в этой отрасли тратится несколько лет, а оборудование нужно уже сегодня, чтобы завтра мы не получили, ко всем нашим бедам в придачу, ещё и сокращение нефтедобычи.
На сегодняшний день Минпромторг подготовил перечень зарубежных компаний, которые могли бы заменить американских и европейских поставщиков. В нем упоминаются три компании из Южной Кореи Daewoo, LHE и KwangShin (компрессоры и пластинчатые теплообменники), по одной компании из Индии (Indore Composite, реагенты), Белоруссии («Нафтан», присадки) и Сингапура (NuStar, подводное оборудование).
По большинству же позиций в качестве альтернативных поставщиков называются китайские производители: в общей сложности несколько десятков компании, в том числе CNPC, China National Logging Corporation, Shanghai Electric Heavy Industry, Huawei.
Российские нефтяники торопятся и их можно понять. Уже сейчас они договариваются с новыми поставщиками. «Роснефть» обсуждает с CNPC возможность объединения усилий в области нефтесервисных услуг, производства оборудования и R&D. Из-за санкций альтернативных поставщиков, в том числе в Азии, ищет и «Газпром нефть».
Китайские производители уже несколько лет поставляют на российский рынок мобильные и стационарные буровые установки небольшими партиями, но к серьёзным проектам их пока не подпускали.
Стоит отметить что в настоящее время до 80 процентов продукции именитых западных брендов производится в Китае. Речь идёт о материалоёмких и энергоёмких частях оборудования. Затем всё это оснащается высокотехнологичной составляющей — электроникой, компьютерными системами, ПО и поступает на рынок под маркой именитых компаний.
В идеале, российские компании для быстрой организации импортозамещения должны пойти аналогичным путём — организовывать сборочное производство китайского оборудования в России, а «мозги» делать самостоятельно. У нас подобное совместное производство сейчас пытается организовать в Уфе небезызвестный Уралвагонзавод, у которого с госинвестициями всё в порядке.
Однако Китайцы стремятся совсем к другому. Они долго ждали и сегодня хотят воспользовавшись моментом завоевать наш рынок с нашей же помощью. Так компания Huawei объявила одним из своих наиважнейших приоритетов разработку комплексных решений в области коммуникационных технологий для нефтегазовой отрасли. Пока у неё в России совсем немного реализованных проектов, но уже полным ходом идёт процесс активного тестирования её решений самыми крупными компаниями. Конечных заказчиков представитель Huawei не раскрывает, но утверждает, что предложения Huawei они начали рассматривать еще до введения санкций и компания готова их предоставить «уже сейчас».
Российские производители опасаются, что разворот нефтяников на Восток помешает развитию отечественного производства. Существует серьёзная опасность, что россиянам придется конкурировать за заказчика с китайскими поставщиками в неравных условиях, в первую очередь финансовых. Китай с 2015 года прекращает программу господдержки субсидирования своей промышленности в области ТЭКа, но ещё долго будут действовать связанные кредиты китайских банков, которые они охотно выдают под нефтегазовые проекты, предполагающие поставку китайского оборудования. Для нефтяников сейчас проще будет работать с китайскими производителями, но в долгосрочной и среднесрочной перспективах это опасность новой зависимости от импорта: Китай попросту может начать диктовать свои условия и по поставкам техники, и по цене.
Кстати цена на китайское оборудование будет не намного дешевле западного, а по качеству оно уступает. С одной стороны, наверху понимают, что нужно ориентироваться на локализацию производства нефтегазового оборудования в России, во‑первых, из‑за того, что отрасль стратегическая, во вторых, чтобы создавать рабочие места внутри страны и здесь же получать налоги. Но российские производители не смогут справиться с требуемыми сроками разработки. Итак, сегодня наша страна стоит на очень серьёзной развилке. Чиновники решают кто будет спасать нашу нефтяную отрасль Китайские поставщики или Российские производители и разработчики.

Картина со стороны инвесторов.

А как же оценивают ситуацию инвесторы? Посмотрим на результаты одного из опросов “Российской венчурной компании”.
69% проектов в России относятся к стратапам низкого качества (17% очень низкого качества), доля проектов среднего качества, по их мнению, составляет 24%, выше среднего — 7%. Но даже та небольшая часть российских проектов, которая признается инвесторами успешной, не видит перспектив дальнейшего развития бизнеса в России. Государство не создает достаточно комфортной среды для развития инновационного предпринимательства, констатируют участники инновационного рынка. Лишь 16% респондентов считают, что эффективность госрасходов за последние 10 лет выросла. Оставляет желать лучшего и эффективность налоговых стимулов и льгот, которыми могут воспользоваться российские инноваторы. Большинство участников рынка (45%) считают такие меры недостаточными. Еще 16% их оценивают как «очень низкие». На высокую эффективность преференций указали лишь 6% респондентов. Малокомфортен и правовой режим инновационной деятельности в России. Негативно его оценивают 55% респондентов. 38% опрошенных считают уровень развития правового регулирования инновационной деятельности «недостаточным и требующим дополнительных усилий государства» и лишь 7% — «комфортным». Совокупность проблем приводит к тому, что российский инновационный бизнес разочаровывается в отечественной бизнес-среде. Почти 60% респондентов считают, что стимулов для сохранения российской юрисдикции недостаточно, и лишь 7% полагают, что их хватает.

Что будем делать?

Как же наши чиновники собираются избежать перспективы монополизации рынка Китаем?

• Актуализировать программы инновационного развития госкомпаний путём ввода соответствующих индикаторов в систему показателей эффективности. В ручном режиме состыковывать госкомпании с ведущими научными и исследовательскими центрами, как академическими, так и университетскими.
• В сфере госзакупок, планируется определить статус реестра инновационных продуктов, технологий и услуг, которые рекомендуются к использованию в Российской Федерации в качестве закупок компаний с госучастием.
• В развитии финансовой инфраструктуры предлагается расширение объёмов финансирования инновационных проектов через фондовое финансирование и создание корпоративных венчурных фондов.
• Опыт пилотных проектов, таких как московский проект «Сколково», татарстанский «Иннополис», томский инновационный кластер, распространить на другие регионы. Планируется поиск новых форм способов поддержки инновационной активности.
• Наконец приступить к созданию системы поддержки технического, научно-технического творчества детей и молодёжи, которая была одним из главных достоинств Советского Союза. Разработать и начать реализацию поддержки талантливых детей и молодёжи.

На словах всё правильно и красиво, но что мы имеем сегодня на практике?

• Госкомпании и госкорпорации очень инертные структуры. Их иерархическая структура не самое подходящее место для взрывного роста инноваций
• Финансовые схемы взаимодействия с частными инвесторами, на свой страх и риск начинающими разработку, не продуманны.
• Силовые ведомства не слишком отличают в своей деятельности мошенничество от рисков, свойственных развитию высокотехнологичных проектов.
• Кредитные ресурсы на сегодня непомерно дороги.
• Зарплата профессорско-преподавательского состава до смешного низка. Финансирование науки сокращается, а огромную часть ещё существующих грантов получают структуры аффилированные с Курчатовским центром, находящимся под контролем господина Ковальчука.
• Преобразования в сфере среднего образования ведут к уничтожению специализированных школ для одарённых детей. Они годами и даже десятилетиями создавали особую среду и преподавательские коллективы, которые теперь уничтожаются.

И главное.Кто будет осуществлять описанные выше прорывные преобразования? Ровно те, кто довёл ситуацию до сегодняшнего положения? А других кадров в системе, с напрочь закупоренными социальными лифтами, нет и быть не может.

Безумству храбрых поём мы песни.

Ну что же, будем делать что можем и надеяться на будущее. Не хочется заканчивать статью на минорной ноте. Постараюсь для поднятия духа сделать дайджест и анализ Российских стартапов, связанных с нефтяной отраслью. Несмотря на все трудности из ТОП-50 российских, по версии Russian Startup Rating, целых пять тесно связаны с разработками в нефтяной сфере.

P.S. А ещё у меня в запасе есть несколько поучительных историй попыток осуществления прорывов в проектах с разными источниками финансирования. Один развивался под крылышком Фонда Бортника и Транснефти. Второй в рамках частно-государственного партнёрства с Газпромом и Роснано. Третий финансировал БизнесАнгел. Уверен, что знакомство с ними будет интересным, найти бы только время!

ссылка на оригинал статьи http://megamozg.ru/post/14842/

В 2009 Тим Бернерс-Ли в своем выступлении на TED говорил об открытых данных и будущем интернета. На 10 минуте он вместе с залом скандирует «Raw data, now!» (сырые данные, сейчас же). Рекомендую всем, кто этого еще не сделал, посмотреть это выступление.

21 февраля 2014 года студенты заняли здание Министерства образование и науки Украины с требованиями перемен. Вместе с политическими требованиями, они выдвинули требования открытой бухгалтерии. Уже 24 марта новый министр подписал указ №85-а о ежедневной публикации всех бухгалтерских проводок за день на сайте министерства. Само по себе открытие данных не должно было занять время, но оказалось, что в МОН фактически не было учетной системы, и, например, главная книга велась на бумаге.

Сегодня данные доступны на сайте министерства, а под катом короткая инструкция как обрабатывать данные, кабель на миллион гривен (около 50 тыс. долларов), и почему пока открытая бухгалтерия не так эффективна.

Получение данных

Проводки за каждый день лежат в CSV файле, для их анализа файлы надо скачать, сцепить и конвертировать из Windows 1251:

wget --accept=TXT --recursive --level=1  --no-directories http://www.mon.gov.ua/ua/public_information/vidkr_buch/ rm robots.txt  cat *.TXT > all.txt enconv -L ukrainian -x UTF-8 all.txt  

Теперь можно поискать нецелевое использования средств. Сразу оговорюсь, что министр хоть и согласился публиковать данные, но, в итоге, доступны только данные аппарата МОН, а это только 1% бюджета министерства.

Кабель на миллион гривен

В документе с идентификатором 867957e5-d454-11e3-aa1c-00304832dd80 видно, что на складе у них лежит «Кабель UTP категорії 5е» стоимостью более миллиона гривен:

Командировочные

6 сентября кто-то получил на командировку 300 грн., а кто-то 14 тысяч:

Проценты казначейству

Оказывается, министерство платит казначейству проценты за пользование кредитом, а это около 1,7 млн. гривен за отчетный период:

Выводы

Открытые данные могут стать хорошим средством для общественного надзора, и логично что чиновники сопротивляются. Возможно, принятие закона о «Об открытости использования публичных средств» изменит отношение к открытым данным в министерствах и других государственных организациях.

ссылка на оригинал статьи http://habrahabr.ru/post/257069/

Стоимость Avito по итогам 1-го квартала 2015 года увеличилась. По мнению основного инвестора компании Avito, фонда Kinnevik, стоимость сервиса сейчас составляет почти $1 млрд. Фонд провел оценку в шведских кронах, получив сумму в 8,3 млрд крон, это примерно $984 млн, сообщает «РБК». В прошлом году аналогичный показатель составил 7,3 млрд шведских крон, то есть $883 млн.

Методика проведения квартальной оценки Avito основана на мультипликаторах, которые применялись к EBITDA, это группа сравнимых с Avito публичных компаний. Эксперты отмечают, что увеличение оценки тесно связано с ростом курса рубля, а также с отличными результатами работы, которые демонстрирует компания.

Выручка компании за период январь-март выросла примерно на 42%, до 1,2 млрд руб. Год назад рост компании составил 115%, с абсолютным показателем в 852 млн руб. EBITDA Avito в первом квартале составила 560 млн руб., при рентабельности по этому показателю в 46,4%. К сожалению, в отчетности не раскрыта прибыль.

По мнению аналитика Goldman Sachs Александр Балахнина, некоторое замедление роста доходов Avito объясняется сложной макроэкономической ситуацией, которая влияет на рынок баннерной рекламы. При этом Avito зарабатывает около 25% своей выручки на продаже рекламы.

ссылка на оригинал статьи http://megamozg.ru/post/14840/