Eng notes @eng-notes - Tumblr Blog

The future is today. Or not...

When you are software engineer who follows modern trends you might think that Future is already there or may be almost already there. Google assistant, with Alexa, self-driving cars, “it can show me photos with cats!” and all these things. Machine learning, convolutional neural nets, natural language processing, artificial intelligence - all of it is already there in everyday products. Software now might do things that are almost magic, doesn’t it?

Here is the Future that Google Assistant can offer you:

I can ask “what’s playing tonight” and get recommendations! Watch the trailer of “Angry birds”! Learn full name of Picasso! Wow! Endless possibilities!

“Ok, Google”. “What should I do to buy a house in Palo Alto in 2 years?”

Or “Why does Mike always argues with me?”

Ok, how about “Are my symptoms flu or just cold?”?

Well, maybe “Why is my phone slower than it was half a year ago?”. No?

Ok, an easy one: “Snow chains for Dodge Challenger 2014 deliver tomorrow” And please don’t offer me to go to some website and deal with registrations, “your credit card” and all this stuff - just order snow chains with easy setup for my Dodge Challenger at at most $80 that will be delivered tomorrow. Uh...

“What’s playing tonight”...

The only thing from 21 century which really adds significant value to everyday life is that I don’t have to go to bank to pay my bills. Oh, wait, that was done in 90th. And it changed our lives.

Well, that won’t be true to say that nothing happened in last 16 years. Online banking today is way more convenient than it was in 90th. Same for navigation. And not only it became better - it’s now available not only for top 0,5%, but for the majority of people.

But don’t you agree that it’s strange to see this “what’s playing tonight” as an example for “How can I help you?” question? “Help to find the best way to get money for education” will be great help in getting things done, not “how old Taj Mahal is”.

So the real Future with AI that actually brings value to everyday life is tomorrow. It’s not hard to see that it’s true: go to your car (note that you own one) and try to add some feature to it which it lacks right now like rear view camera or even bluetooth. Ask your computer or your phone to fix itself if something isn’t right. Do laundry. The Future, huh?

“Real OOP” vs “Procedural OOP”

I’ve recently been to “How anemic objects kill OOP” meetup which presented quite interesting approach to programming. It’s not fresh and in fact everyone knows it’s name: object-oriented programming. But it’s very unusual to see object oriented programming interpreted in that way. Which, by the way, as of today I find very promising.

I hope it will find to combat what was called “procedural” approach. By this “procedural” approach I mean big classes with logic, services, POJO or JavaBeans and all that stuff.

Key things I hope this approach will help to solve in comparison with “traditional” approach are following:

Any application eventually turn out to be a big ball of mud. It’s just too complex.

Test are verbose and long. Too complex

Designing new component, you have to think hard and to foretell the future: how your service will be used? How it’s going to change?

You are trying to create abstract reusable objects but you have to put “dirty” behavior somewhere. It ends up located in some “Manager” or “Util” classes.

At a closer look it appears that all that is called today “Object oriented programming” is just a way to organize the code of one big procedure. Maybe not one, but a lot of procedures.

The main benefit I’d like to have with this (or any other) approach is to avoid complexity and preserve maintainability. I can’t say that this approach will for sure guarantee this, but I believe it’s worth trying.

“The clean coder” chapter 1

I’ve recently read first chapter of “The clean coder” book and it left some controversial feelings about its contents. Of course my experience is incomparable with author’s but I do have an idea that the explanation of “professionalism” given in that chapter is a little bit mixed up with marketing component. In preface some situation is described where engineers weren’t treated like professionals. I personally don’t see any connection with “professionalism” as a social interaction skill and as a technical skill.

Another thing is that the description sounds like one written by business owner. It’s convenient to business owner to have such professionals as an employees - who work hard whole 8 hours a day on employers’ problems, pays for their mistakes and do overtimes just because they are ought to.

It’s seems possible for someone to be concentrated whole 8 hours on employers problems if this one got paid hourly at a very high rate but it doesn’t seem to be possible with regular employee. People are not machines - there will be more productive and less productive days. If independent professional can adjust his schedule to avoid work in non-productive periods that’s not possible for employee.

The statement “What does professional do when his mistake cost $10 000 to company? He writes check for $10 000″. Again, that looks great for business owner. It actually seems to be right thing to do: professional should be certain in his work so that he can give such guarantee. The reason why I think it won’t work is “cynefin framework”. If software is simple enough to be fit into “obvious” or “complicated” such guarantee is possible and beneficial for both sides. On the other hand if software is sophisticated enough to be “complex” according to this framework this unlucky professional is trapped into situation where he pays for his inability to predict the future.

There are some very good points in this chapter - professional delivers high-quality product. But I can’t agree with strict rules defined in this chapter. Is it a problem if someone spends 30 hours a week instead of 40 solving employer’s problems and uses the rest 10 for self-development if things got done? Should professional anticipate every possible system fault scenario to be secured from errors that may cost company money? I think these are more soft skills rather than technical skills. It’s great to posses such skills - but it doesn’t mean that one is not a professional if he doesn’t.

Role of architect

I’m quite sceptical about “Architect” title. It seems to me that it’s just marketing - no real work involved. So if you’d ask architect to explain what he’s doing in 30 seconds he’ll unable to explain it. Well, maybe he will be able to do it but this description will perfectly match software engineer role. So “architect” may be just fancy name for experienced developer (and way to make more money - which isn’t bad it’s just have nothing with tech skills - it’s marketing).

I don’t state that this is absolute truth. I just haven’t met any architect who can demonstrate or at least explain this “architecture” skill. But this "Role of architect” article sheds some light on this possibly-nothing title. The architect’s role is to maintain system flexible. It’s role is to enforce some policies (I imagine it through code review and thorough developers education) that will keep project well-structured and easy changeable.

Still it will be great to talk to someone who don’t just talk from conference scene about his magic achievements but does real architect work done but that “enforcement” is something that “regular” software engineer might not have.

#architecture

Странности javascript

Пост, вероятно, очень типичный для тех, кто изучает javascript имея опыт работы с Java. В javascript есть интересная особенность: базовая структура данных (т.е. object) - это map. Несколько ограниченный map, так как ключами могут быть только строки, но все же map. Он же set. Т.е. если в java для создания map нужно воспользоваться collection framework (например new HashMap<>()), то в javascript для этих целей можно создать пустой объект {}.

Здесь сразу же возник вопрос: а сколько стоят операции вставки и чтения из объекта? Если предположить что мы решаем на javascript алгоритмическую задачу, то хотелось бы знать ответ на этот вопрос. Удивительно, но ответ найти не так-то просто. Всюду попадаются ссылки о том как объекты использовать, как их можно наследовать и т.д. но нет ни слова о том как, собственно, объект реализован. Итогом тщательного поиска стала ссылка с лекцией одного из разработчиков работающих над spidermonkey (javascript движок). В лекции рассказывается непосредственно о реализации объекта, правда ответ на первоначальный вопрос (сложность вставки и чтения) - все равно не ясен.

Спросил так же у коллег есть ли у них знания по этому вопросу. Из знающих javascript откликнулся один и он не очень понял вопрос. Я пояснил: map может быть реализован как хэш-таблица или как дерево. Вероятнее всего это не дерево т.к. операции с деревом дороже. Плюс к тому свойства не упорядочены (в таком случае если это дерево - то как происходит поиск? Путем обхода всего дерева? Врядли, это неэффективно).

Т.е. наверное это хэш-таблица. Если так, то как в ней разрешаются коллизии? В Java, например, это метод цепочек: в каждой ячейке массива лежит связный список. В python dictionary это открытая адресация с псевдорандомным пробированием. Какой метод выбран в javascript? Коллега снова не понял вопроса и привел следующий пример кода:

var array = [];console.log(array.length); // 0; array[999] = 1; console.log(array.length); // 1000

Выглядит разумно. Массив - это просто список значений и каждый индекс - это просто порядковый номер элемента. Если мы добавили 999-ый элемент то 999 элементов до него (включая 0) должны существовать. Даже если они пустые. Но:

console.log(Object.keys(0)); // 1

Т.е. на самом деле массив в javascript - это специфичный объект, который имеет number в качестве ключа и своеобразную функцию length. Это кажется очень необычным, т.к. в Java массив воспринимается как примитив, встроенное средство языка, а map - как библиотечный класс. В python врдое как map и list (массив) равноправны - они не используют друг-друга в своей реализации и одинаково интегрированы в язык.

Узнав такую особенность массивов в javascript стало немного понятнее про свойство arguments - это “псевдомассив”. Воспринимая массивы как в Java это совершенно непонятно. Это нужно постараться чтобы сделать массив который на самом деле не массив. В javascript это просто - достаточно создать объект и позволить его ключам быть Number.

Accessibility: увеличение и уменьшение шрифта на сайте

Никогда толком не понимал кто и когда пользуется кнопками увеличить или уменьшить шрифт в браузере (в хроме это ктрл + “+” или ктрл + “-”). Оказалось есть очень простой но периодически возникающий use case: при презентации чего-либо на сайте удобно увеличить шрифт чтобы было видно издалека.

#ux

UI: Editable label

Существует такой компонент, как editable label. Или его другая разновидность: editable table. Этот компонент - это просто текст, который при клике оказывается input, в котором можно отредактировать то, что написано.

По какой-то причине достаточно многие разработчики таких компонентов совершенно не заботятся об эстетической части компонента.

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

Сравните

и исправленный вариант:

Казалось бы это достаточно очевидная вещь. Но бегло просмотрев editable label плагины не удалось найти ни одного, который бы эту очевидную вещь практиковал. Даже плагин, гордо декларирующий поддержку bootstrap и имеющий кроме этого момента весьма симпатичный вид:

Смотрелось бы куда более приятно, если бы текст не дергался:

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

#ui

Javascript и строка вместо массива.

Представьте что у вас есть javascript класс, который из данного ему json (а в нем - список) генерирует таблицу. Каждый элемент из списка (из json) - 1 строка в таблице. Вы написали класс, протестировали, все работает прекрасно. Затем вы подключили backend и внезапно вместо ожидаемых 4 строк с данными страничка подвисает на пару секунд и выдает под 1000 строк безо всяких данных.

Причина этого в том, что полученный JSON был воспринят не как JSON, а как строка. Чиниться это простым вызовом JSON.parse(<ваша строка>).

#javascript

Immutable objects в Java

Существует концепция immutable объектов. Самый известный ее представитель - класс String. Суть концепции: после создания объекта его никак нельзя изменить, т.е. по сути объект - это константа. Если мы все же хотим что-то изменить (к примеру, вызываем someString.replace(’a’, ‘b’)) - нам возвращается новый объект.

Immutable объект реализуется путем объявления всех полей как final. Соответственно, значения всех полей необходимо передать в конструктор. Если полей много и хочется дать больше удобства при создании объекта - можно создать внутренний класс Builder, у которого будут все те же поля, что у объекта, только не final. И кроме полей - set-методы следующего вида:

public Builder setProtein(String proteinA) { this.proteinA = proteinA; return this; }

Возвращать this удобно потому что в этом случае объект можно создавать в одну строку:

ProteinSequence = ProteinSequence.newBuilder() .setProteinA(”AACG”).setProteinB(”ACCG”).setProteinF(”CCA”).build();

Есть так же и спорный момент: нужно ли декларировать класс как final? С одной стороны в этом есть смысл. Без final возможно создать наследника класса, у него объявить свою не-final переменную и переопределить getProteinA() чтобы он возвращал объявленную ранее переменную (а заодно и добавить метод setProteinA(String proteinA)). С другой стороны для предотвращения этого сценария достаточно сделать метод getProteinA() final.

#java

О интерфейсах

Очень хорошая статья о том, на что обратить внимание при создании новой странички/виджета: http://scotthurff.com/posts/why-your-user-interface-is-awkward-youre-ignoring-the-ui-stack

#UI

О проектировании функциональности

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

В реальности же у нас редко бывает такой дар видеть будущее. В одном из споров о том как должна быть реализована какая-то функциональность прозвучала интересная фраза:

“Разумно делать наиболее простым способом. Если потом необходимо что-то изменять или дополнять - то нужно изменить или дополнить. Первый раз и второй раз. Если такая необходимость появляется в третий раз - нужен рефакторинг”.

#архитектура

Задачи на интервью

1. Есть шахматная доска 8х8 и есть фигура в клетке (0,0). Фигура может двигаться или вправо или вниз. Задача: вывести на экран все возможные способы которыми фигура может прийти в клетку (7,7). Сколько всего таких способов?

2. Мы - авиакомпания и у нас есть сайт, который дает возможность купить билет, но нет возможности выбрать место. Разработать API сервиса, который даст такую возможность (т.е. API возвращает план самолета с сидениями и можно на UI отрисовать сидения, дать пользователю возможность выбрать их и сохранить свой выбор)

3. Есть дерево (для начала двоичное, но вообще - любое). Написать метод сериализации этого дерева в файл и десериализации его из файла.

4. У нас есть онлайн-магазин. Разработать функцию “предложения для поиска”: когда пользователь печатает, например “la” у него появляется дропдаун с вариантами: “laptop”, “laser printer”, “laundry basket” и т.д. Т.е., по сути, разработать autocomplete.

#technical interview questions

Patch API

Есть, оказывается, такой HTTP метод как PATCH. Есть GET, POST, PUT, DELETE, а есть еще PATCH.

Более того можно объявить метод patch, например, в интерфейсе Repository. Может возникнуть вопрос: а как же update? На самом деле это другой метод. При вызове update в БД будет записан объект, который передан. В то время как patch применит изменения, которые были сделаны в объекте (diff). Т.е. patch на вход принимает не объект, но изменения, которые нужно применить к объекту (diff).

С помощью такого подхода можно реализовать интересную user-friendly функциональность - когда пользователь заполняет форму каждый раз, когда он заполняет поле мы шлем patch запрос для объекта. Таким образом мы сохраняем промежуточное состояние объекта, не передавая сам объект (что в случае сложных структур может быть трудоемким).

Но есть и сложности - не совсем ясно каким должен быть API для таких патчей. Принимать на вход String fieldName, String newProperty? Это не кажется хорошей идеей.

#архитектура

Autoboxing

Представьте себе следующую ситуацию:

public void addRule(String title, Rule rule) { // implementation... } public void addRule(String title, Rule... rule) { // implementation... }

Нет ли здесь неоднозначности какой метод будет вызван при addRule(”Rule”, someRule): с одним параметром или со многими (varargs)?

Ответ: нет. Потому что при вызове метода JVM сначала будет искать методы аргументы которых совпадают с переданными параметрами. Если он их не найдет он обернет аргументы в массив и попробует найти метод c varargs. Т.е. произойдет autoboxing.

#java

Два способа подождать другой поток

Представьте ситуацию: вы хотите узнать во сколько раз быстрее будут 10 параллельных записей в сравнении с 10 последовательными. Для этого вы пишете программу, которая, соответственно, запускает 10 параллельных процессов записи и 10 последовательных (к примеру, в цикле for). Запоминается время начала выполнения и оно отнимается от времени, когда операция завершена.

В случае с циклом for это работает хорошо. Мы записали 10 записей и посчитали сколько прошло времени. В случае же с запуском потоков все не так гладко: если использовать ту же стратегию, то мы узнаем сколько времени понадобилось чтобы запустить 10 потоков, а не чтобы эти 10 потоков выполнились.

Для того, чтобы узнать желаемое, нам нужно сначала 10 потоков запустить и затем подождать пока они все выполнятся. Есть несколько способов это сделать. Вот два из них:

1. Использовать join(). Мы создаем 10 потоков, запускаем их, а затем для каждого из них делаем join(). Затем измеряем сколько прошло времени.

List<Thread> threads = new LinkedList<>(); long startTime = System.currentTimeMillis(); for (int i = 0; i < 10; i++) { Thread t = new Thread() { @Override public void run() { for (int i = 0; i < 10; i++) { dao.write(); } } }; t.start(); threads.add(t); } for (Thread t : threads) { t.join(); } long endTime = System.currentTimeMillis();

2. Использовать CountDownLatch - класс, специально разработанный именно для этой задачи. Он работает следующим образом - при создании мы указываем count. Затем объявляем потоки и в конце каждого из них делаем countDownLatch.countDown(). Затем запускаем их. После запуска добавляем countDownLatch.await() и после этого считаем время.

final CountDownLatch countDownLatch = new CountDownLatch(1000); long startTime = System.currentTimeMillis(); for (int i = 0; i < 1000; i++) { Thread t = new Thread() { @Override public void run() { for (int i = 0; i < 10; i++) { dao.write(); } countDownLatch.countDown(); } }; t.start(); } countDownLatch.await(); long endTime = System.currentTimeMillis();

Конечно это не далеко не единственные способы решить поставленную задачу и несколько странно использовать подход с join(). Тем не менее оба этих способа работают и выполняют задачу.

#concurrency

Сколько нужно интерфейсов чтобы загрузить страницу?

Ситуация следующая: есть веб-приложение, состоящее из нескольких (меньше 10) страниц. Несколько страниц имеют “ленивую” загрузку (т.е. делают какие-то запросы когда их открывают), одна страница требует спросить пользователя “а ты уверен, что хочешь уйти со страницы не сохранив данные” когда пользователь намеревается уйти со страницы не сохранив данные.

Переключение страниц происходит так: создается событие “идти туда-то”, затем обработчик (единственный) смотрит куда же нужно идти и делает видимой нужную страницу.

Как лучше поступить:

- Сделать один интерфейс Page в котором будут методы beforePageOpened и beforePageClosed

- Сделать два разных интерфейса LazyLoadedPage и actionOnClosePage в каждом из которых, соответственно, два метода.

Ответ: второй вариант лучше. Т.к. в этом случае мы не будем иметь пустые методы для классов, к которым не относятся эти дополнительные “фичи” ленивой загрузки и действия при закрытии.

#архитектура

Substitution principle?

Задача: реализовать простейший Blocking Queue. Интерфейс содержит методы get, add. Какие методы вы бы добавили в интерфейс?

Решение: Blocking Queue это структура данных, которая по add добавляет значение и по get возвращает его (как очередь). Но если очередь пустая - клиент ждет пока что-то не появится и когда появляется - отдает этот элемент. (простейшая реализация - while(true) цикл)

Можно придумать вот такой дополнительный метод: avgWaitingTime(). Возвращает соответственно среднее время ожидания. Однако это не очень хорошая идея.

Причина того - substitution principle (вроде как), а если понятным языком, то дело вот в чем: интерфейс объявляет методы, которые должны реализовывать все имплементирующие его классы. Среднее время ожидания это дополнительная функциональность, которая в большинстве случаев не нужна. Соответственно добавлять этот метод в базовый интерфейс не стоит.

Вместо этого можно рассмотреть такой метод: get(long time) который ждет максимум указанное время а затем возвращает null или кидает Exception.

#архитектура

Trending Blogs

Recently Viewed Blogs

Eng notes