The Hardcoded Blog

Now working at GridGain

2022-03-19T07:02:10+00:00

About 2 month ago I’ve left Yandex for working at GridGain Rus.

Spending almost 2 years in Yandex was an interesting experience, but I cannot name it fruitful or delighting. Somewhere in the middle of this journey I’ve fallen into a “big tech cultural trap” that was perfectly preparated by Dan Luu. Instead of fighting it or adapting myself, I’ve decided to leave.

Now, I’m a SDET at GridGain. I feel the best opportunities to apply my skills, my knowledge, and my passion here.

Please stay tuned: this blog is not abandoned, and I plan to post more thoughts from time to time.

Peace to y’all!✌️

Lists vs. Fractals

2021-11-24T14:38:00+00:00

TLDR: I have a hypothesis that problems in programming often have fractal-like nature. This causes delays in work and makes the management of tasks more complicated. Our task-management tools cannot properly handle fractal tasks because they are based on the linear concept and treat task dependencies as a second-class citizen. If we take into account the fractal nature of tasks, such management may become easier.

I also propose an example of tool for such kind of task management. You may take a look at it, but it’s not obligatory.

Welcome to the fractal trap!

Let’s explore an imaginary (but quite typical) situation. Say you have a “software project”:

a big pile of code,
and some kind of “task tracker” used to plan a work upon this code.

At the beginning of a new week, you choose a single “task” from this tracker and start to work on it. This task has already been “estimated” and split into a simple, straightforward-looking checklist.

Then you simply start moving through this list. At the first glance, these steps appear to be simple, but when you dig into the first one, it suddenly grows in size.

There might be a blocker or significant subtask for almost every simple step in your software project. Your “first subtask” grows more and more, becoming comparable in size to the whole original task.

Finally, you’ve found that your code to be changed is not covered with tests. Much bad, need to fix it!

Of course, this isn’t a rant against refactoring or tests! They are truly needed, especially in complex and aged code bases. I rant against the way we’ve used to deal with tasks.

Sierpiński triangle, image from Wikipedia

Like a fractal, a software development task could easily hide other subtasks with comparable size and/or complexity. They could be invisible to you until you face them. That’s why I call this “a trap”. Fractal traps usually come from different sources: code coupling, leaky abstractions, requirements shift, and so on. They are almost unavoidable. I think it wouldn’t be wrong to claim that most developers have to deal with them at least sometimes.

But how do we usually deal with such a kind of problem?

A classical approach

The most naive approach to handling this problem is simply ignorance. Is each task growing in size? OK, let’s deal with it. Just keep going until the final goal is achieved.

Alas, by keeping all substeps in the same task we make them quite opaque. Something is happening in the task, and it will be finished someday.

Depending on your working environment and team agreements, this situation could or could not harm your performance. In most cases, I’m afraid, it does. There are thousands of words written that could explain better than me why large tasks decrease your productivity.

Of course, this is a common problem, and there is a solution already! Let’s proceed to it.

Divide and conquer

Once you get tired of big tasks, you start splitting them into smaller pieces. In your new working process, each subtask is only allowed to become a full-fledged task in your tracker once you notice that it’s big enough. Like this:

Oh, wait!.. Much more often you’ll see it like this:

Ticket      Label                       Assignee
----        ----                        ----
#321        An original task            You
#322        Config migrations           You
#323        Code cleanup                You
#324        Add more tests              You

When splitting your task into subtasks, you usually have to pay a new tax: the tax of manual dependency management. Starting from now, your every decision about what subtask to take next gains an additional cost. When you ask a question about relations between tasks, you have to visit one or several of them to find an answer:

Is there anything that prevents us from starting work on task #N? Well, dig into it and check whether there is any “blocker task” on the card.
Which tasks have no blockers? Visit all of them and take a look.
Which task has the highest priority? Use priorities you’ve assigned to them manually. Of course, you should better ignore the fact that your “super-duper critical” task could easily be blocked by another task that looks like “senseless crap” in isolation.

Is it possible to reduce this tax? Let me introduce a possible way to do it.

Respect the structure

Because of the task-oriented nature of most task-tracking tools, the relations between these tasks are second-class citizens. How could you ever spot the fractal structure when the only thing you get is a big unstructured pile of tickets? To make this happen, we should try to visualize this tree and introduce our dependencies as first-class citizens. But I believe that we deserve to have good task-management tools that could help us to handle with complex and tangled nature of software development.

How could a task workflow look like in such a tool? This vision is primarily inspired by ideas taken from a brilliant “The Mikado Method” book by Ola Ellnestam and Daniel Brolund.

At the beginning of a new day, you choose a single goal from this tracker and start to work on it. Several days ago you’ve already thought about this goal and preliminarily split it into three subtasks.

The tool highlights non-blocked tasks for you making them easier to spot. So you simply choose to start from the first one. To improve your focus, you hide other subtasks - they are not needed at the moment.

At the first glance, this step appears to be simple, but when you dig into it, it grows in size. You reflect these changes in your tracker by adding new subtasks. In your task tracker, it’s a quick and easy operation.

A count of subtasks still grow, but you’re prepared for that. No matter how deep you dig in, your tool always allows you to control the complexity of your current working context. You could split your tasks into parts to focus on a single chosen part. You could draw relations between subtasks to provide an order of execution. You could remove these relations when you see that two tasks do not depend on each other. All these operations allow you to keep the number of your next actions small.

From time to time you may switch from “working mode” into “planning mode”. Instead of “zooming in” into a single subtask, the tool lets you “zoom out” to see a whole picture. It may look like this, for example:

Now let’s imagine that you decide that one of your refactorings could be performed later since it doesn’t actually block your work. The only thing you need to do is to insert a new subgoal between an original task and this refactoring.

Then let’s zoom into the “Preliminary refactoring” again. It’s become simpler than before because the “Migrate config files” subtask doesn’t block it anymore.

You may simply take the topmost subtask and solve it. After you’ve ordered your small steps, all of them could be taken one after one.

Is it better?

This process may look scary when you’re unfamiliar with such kind of task management. At first glance things seem worse: not only have more subtasks to manage right now, but also many more explicit dependencies between them. The total amount of “items” has been increased compared to previous approaches.

But when you look at how does it behave in dynamics, things do change. With such a tool, you could easily change the scale of thinking and planning.

In the “global view” mode, you usually don’t work on any single task. Instead, you look at relations between tasks, reorganize them, spot patterns, and think about the big picture. It’s very similar to the “mind mapping” technique which is used to organize connections between ideas. You only need to decide what is relatively more important, and what is relatively less important. The tool takes responsibility for the absolute ordering. Every line in this graph becomes the record of your decision. And after returning to the “close view” mode, you don’t need to keep these decisions in your mind.

The only thing you need to focus on is how to finish a simple “top” subtask. When it’s done, another subtask will become unblocked. This allows new tasks to become “top” ones. This process strictly follows the order you’ve defined earlier. Now your task tracker works not like mind mapping but like a TODO-list. But it’s still the same tool!

Does it have drawbacks?

Of course, there are several issues.

Tree trimming takes time. Almost obviously, when you manage many small pieces of your task and relations between them, it requires a larger part of your time. On the flip side, detailed and flexible planning often allows one to foresee and avoid traps before falling into them.

And it saves the time you might lose when escaping from these traps.

It requires skill. Here’s a less obvious but more important point. Without experience in decomposition, you often don’t know how to split your tasks properly. But to gain experience, you need to do it regularly. Even after ~5 years of using my tool I still find new ideas to improve my techniques. As an example, I still don’t know how to work with structureless tasks like writing big pieces of text (especially this one).

Risk of context loss. Alas, this happens regularly. Say you have two big subtasks of your current task (A and B). Each one has several nested subgoals (A.1, A.2, A.3, B.1, B.2, and so on). While working on subtask A you notice that A.2 is a prerequisite for B.1 and place a dependency between them. After some time you switch from A to B and A.2 (a blocker for B.1) suddenly becomes unclear for you. Because it’s described in several simple words like “Do X” which are clear in the context of A but not in the context of B. Solution? You need to always keep some additional context together with a single subtask.

Observability issues. Also pretty obvious: when you have a lot of small subtasks, at some moment they become difficult to find.

Risk of task duplication. As a consequence of the two previous issues, duplicated subtasks appear periodically. On the other hand, this could happen to any task tracker, right?

All of these issues could be mitigated with a good tool. Here we go to the last drawback!

Lack of good tools. I’ve looked at tens of the most popular task management tools, and none of them is close enough to the described functionality. I’ve even had to create one by myself. It allows for understanding the concepts described here but still lacks a lot of important features. But if you only need to evaluate the ideas I’ve described here, it may help you.

The same diagram as above, implemented in SiebenApp

~~There's definitely at least one TODO app for MacOSX with similar functionality, but I've lost a link on it. I'm sorry.~~

UPD (2022-03-18): Here I’ve found a reference to a similar MacOSX tool TaskHeat. But I’m a Linux-boy without MacOS, so I couldn’t check it by myself. This is an excercise left to a reader.

Is it Gantt diagram?

The one who has enough experience in development may feel suspicious after my claim: “we have lack of tools”. Of course, there is a whole class of tools for “management of tasks and dependencies” we have to live with for decades.

Source: Wikipedia

Often, it’s too far from a symbiosis. The following short story perfectly illustrates the problem:

When I first started contracting in London, I worked as the only developer on a team that had TWO project managers - one in Leeds and one in Swindon. Every week I dropped working software, they tested it, and the plan changed.
— Jason Gorman (only, more indoors than usual) (@jasongorman) August 17, 2021

Every Friday I had to travel up to Leeds and then down to Swindon to help them update their project plan. That was a day out of every week for 3 people to change a Gantt chart that was out of date by the following Tuesday.
— Jason Gorman (only, more indoors than usual) (@jasongorman) August 17, 2021

I've believed ever since that detailed long-term planning in s/w is a waste of time. If you iterate working software fast enough, you can deal in reality, not guesswork.
— Jason Gorman (only, more indoors than usual) (@jasongorman) August 17, 2021

And, yes, that means they spent 20% of their entire development budget (i.e., me) maintaining a Gantt chart.
— Jason Gorman (only, more indoors than usual) (@jasongorman) August 17, 2021

I have to draw a line between the two approaches. Why do I distinguish a “fractal-oriented” approach from the well-known Gantt-chart approach? I’d like to point on the following difference. Gantt tools are oriented towards managers, not programmers. They’re mostly focused on very different things (duration, “resources”, “materials”, large scope) and provide a relatively heavyweight workflow.

Things should change when a planning tool lies in the hands of perfomer. When it doesn’t have any distracting or heavyweight concepts. When it could simply be used in parallel with the work itself without interrupting the flow. Then complex problems would become much easier to solve.

Yet at this point, I still have more questions than answers. How many programmers actually face such kinds of issues (and how often)? Did I overcomplicate it? Wouldn’t my remedy be worse than the original disease?

Let’s leave them open for now.

Acknowledges

This article wouldn’t exist without the influence of the following people:

Jessica Kerr in her “Code is a coastline” have inspired me to write my own thoughts about the fractal nature of software tasks. It’s only my fault that it took several months to formulate an answer!
Ola Ellnestam and Daniel Brolund with their “The Mikado Method” book have changed my way of thinking about tasks. After several years of practicing, I find it way more natural, easy and practical than the classical big-ticket-oriented approach.
Sergey Tselovalnikov, my Russian ex-colleague, gave me much enough courage to start writing in English. He has also given many useful comments on the draft version of this essay. Please check out his blog.

Additional links

In case you want to take a look at the herd of task trackers, take a look here or here.

Mr. Michael “GeePaw” Hill has also posted interesting thoughts on similar topic here and here.

Comments

Sorry, comments are currently disabled here. Once I’ve tried to use Disqus, but it was a kind of mess that I don’t want to be repeated.

But any kind of feedback is highly appreciated! Please leave your comments under the following tweet:

New blog: Lists vs Fractals https://t.co/xt2IsC8YLE
List-based task-management tools and thinking vs the Fractal nature of programming tasks
— Andrey Hitrin (@ahitrin) November 24, 2021

Back to Jekyll defaults

2021-02-06T00:00:00+00:00

Hi there!

I’ve been down for few months - probably because of being overloaded of so much stuff to publish. Fortunately, this dark period comes to its end.

But first I want to reset visual blog style. It’s become too 2012-ish. It was hard to read, especially on mobile devices.

Just compare new (left) and old (right) styles of the same page taken from the same device.

Which one is better?

Interesting, but resetting theme to default was not so trivial. I’ve tried it several times, but failed. Jekyll has a tool to aid migration from other publishing systems, but not from the old version from itself! The only working way was a total “rewrite from scratch”:

Delete all old Jekyll files (_config.yml, _includes, _layouts, assets and few others)
Copy new ones created by the jekyll new command
Fix all important issues and deal with others

Now it’s time to back to more interesting content. I’ll be back soon. Please stay tuned.

A model of small decisions

2020-11-03T00:00:00+00:00

Would you like to walk here at night? Photo: Andrey Hitrin

Sometimes thoughts of our human nature makes me sad. Our attempts to share own thoughts to others can be compared with attempts to find a way out from the dense forest during a moonless night aimed only with a laser pointer. The only thing you could show to others is a little spot of light randomly jumping back and forth, appearing and disappearing spontaneously. How could you find a trail with such a weak tool? How could you convince your party to follow it? How could you understand if this trail should take you out of the forest?

That’s why people try to invent new and new words to explain same conceptions. Everyone hopes that his/her explanations will be good enough to make other understand “the inner nature of things”. Most of the time it’s worthless: others don’t see more than chaotically jumping light spot.

Nevertheless, here is my own attempt. Words written here are not the truth, they are nothing more than my biased reflection of it, based on my limited experience. I don’t know if they are contains some wisdom, or just a bunch of useless commonplace. That’s you who will judge.

The quest for mastery

As usual, I want to speak about programming.

There is an idea that programming has many similarities with martial arts or musical performing. In all of these areas you could show some results after relatively little amount of practice, but it requires years of studying and training if you want to achieve truly significant level. Often you even have to perform at the edge of your own abilities.

And when you want to perform at such level, you must be aware of all aspects of your profession. Today I want to speak about small and often invisible decisions that guide you through your everyday work.

Small decisions

In our job, you need to do a lot of small decisions every day. Just watch after yourself during work process, and soon you will be able to notice them.

Imagine you’ve just started to work on some feature. Small decisions appear instantly. How will you start you work? By reading documentation, or by checking code out, or by asking your colleagues? Change some code first, or think about test cases? Implement straightforward change, or roll out few refactorings beforehand?

How will you deal with “bad code” challenging your way: ignore it, or try to fix right now, or defer a fix for a “better time”? How will you act when feeling struck: ask your teammate (and which one, when you have several of them), google your problem, stackoverflow it? Or maybe simply wait until an answer forms inside your head (also known as ‘procrastinating’)? Or maybe wait until someone asks you about the progress?

That’s what I mean by the “small decisions” term. A lot (tens, or even hundreds per day) micro-choices you make in your work. Sometimes you make this choice consciously, but often not! You choose your path without even thinking about it, without even noticing the fact of choosing.

Does this matter? I think it does.

Choose/move dichotomy

Let’s draw your way through the imaginary “work task”. I like to draw graphs, so it’s depicted as a graph.

Every node here is a small choice you’ve made. Arrows represent the “movement” between them. A number of intermediate steps is arbitrary and depends on your own definition of “small decision”. When you zoom out, they almost disappear. When you zoom in, a single decision could be even as small as “which finger should hit the given keyboard button?”. Here I choose something intermediate.

And now let’s imagine more possible moves that also could solve your task.

Here we see a whole net of possible decisions. What would happen if you choose another step at the start? Some of alternative ways could be shorter (containing less hops), some of them could be much, much longer! Of course, here I simplify the problem a lot. But I need this simplification to show you few important things. Here are following key points:

You have to make a lot of decisions. There are points in almost every task that requires your decision. For example, you need to ask yourself at least once: “have I reached my goal?”. And then either get done with it or continue to work.
Even small decisions may have big impact. When you choose the wrong path at start, it may lead you far away from the goal. You have to move along the non-optimal path or return back to the start.
Every decision takes your time and energy. Usually delay on decision come from one of two or three sources. The first source is delay between a question and an answer. Say you’re struck and don’t know where to move next. You try to ask your colleague via IM for help. But currently he/she is busy, and only can answer you in 20 minutes. This delay is the cost of your decision. The second source is delay on choosing by itself. It may happen when you see two or more alternative paths and hesitate which one should be followed on (maybe a “frustration” word is suitable here). The third one is a need to remember a known, but currently forgotten solution (more on this in the next chapter).

All of these make me conclude that it’s important to consider the impact of decision making to our work. Low-quality decisions reduce your productivity every day. They make you stray in the dark without help.

Surprisingly, even after reading a lot of books and articles on programmer’s productivity, I haven’t found enough much attention to this theme (please correct me if I’m wrong!). That’s the main reason why I’ve started to write this article.

A table of decision rules

OK, maybe quality of decisions is important. But how could we ever manage them? Here I suggest a simple model. As any other model, it doesn’t describe things as they are, but uses simpler (and more manageable) view on it instead. The main power of modeling is its ability to predict effects of our actions, but we should never forget about its boundaries. Outside boundaries, our model will be wrong - and I don’t know where they are. I sincerely hope that your feedback could help determine them.

The model is heavily inspired by the work [1]. Think for a minute: this paper is already 40 years old! Why no one still haven’t developed it into the similar direction as I did? I don’t know (or maybe I’m just wrong - please let me know in that case).

This prelude was necessary - but now let’s proceed to the model. So, suppose each of us have some kind of table in the head (I warned you, it’s a simplified view). It contains two columns:

Trigger. An external stimulus that could activate current “table row” or rule. For example: a piece of code you’re looking at; a letter from CI server; a message from your colleague; your current thoughts about your task; and so on.
Acton. A thing you do when the rule is being activated.

It may look like this:

Trigger		Action
You need to find the source of a bug	→	Run `git bisect` to find a commit where it was introduced. Then analyse the code
You want to check if your code is ready to deploy	→	Push changes to remote repository and run CI service
You want to check if your code is ready to deploy	→	Push changes to remote repository and ask someone to review it
You have detected the "smell of ugly code"	→	Try to refactor it out immediately
You have detected the "smell of ugly code"	→	Ignore it: we don't have time to refactor
Selenium test on CI server has failed	→	Look at screenshot to check where is the problem
Selenium test on CI server has failed	→	Look at job logs
Selenium test on Ci server has failed	→	Launch that job again: maybe it's just flaky test?
You're struck and don't know what to do next	→	Ask your teammates for help
You're struck and don't know what to do next	→	Wait until someone asks you what's going on
...	→	...

This table has important properties:

It changes over time, depending on your own experience and knowledge. When you discover new tricks, they have a chance to hold in the table. In other hand, even the best practices without repetition pass away from your memory. Of course, they do not always being erased completely. Rather, they are removed from “the cache”, the fastest part of your memory. And you’ll have to make an effort of remembering to bring it back.
It has limited size. You cannot know literally everything. You cannot have the best solution for every possible situation you may face.
It may have several rules for one situation. In that case your final choice may depend on current context. Sometimes you may even need to spend additional time and effort to make a choice between alternative actions (“resolve a conflict”).
It models only small decisions. Only little choices that often even pass your spotlight and perform automatically could be modelled that way. In terms of “Thinking, Fast and Slow” [2], it relies to the “System 1” only.

There could be different sources where these rules come from:

Your previous successful and unsuccessful experience.
Observations of your teammates: how do they behave in different situations.
Direct rules of the project you’re working on (like “use ./gradlew check to verify correctness of your code”).

I hope to write more on it in following articles, but the current one has grown big enough. Seems like I have to go to conclusions.

Any benefits?

What benefits could the awareness about these rules bring to you?

First of all, you should take into consideration the limited size of your memory. In order to make better decisions, you need to consciously “tune” your rule table. How could it be done?

Remember your good (effective) decision rules. Practice them from time to time so they don’t leave your working memory. Write them down in known place so they could be remembered effectively when needed.
Try to free your memory from unneeded decision rules. If they aren’t needed, forget them. If they still may be useful, keep them in an external place. For example, imagine you have a complex task management ceremony consisted of 7-8 steps that needs to be performed once a week. You should not try to keep this ceremony in your memory. Writing it in a form of simple instruction or checklist is much better. Now, you need to remember the only one thing: a place where your checklist lies.
Try to avoid multitasking. Different tasks require different decision rules. When you switch back and forth from one task to another, these rules fight for a place in your working memory. There is no guarantee they all could fit inside altogether. It’s highly likely they couldn’t.
Review your working habits regularly. Are they effective enough? Have some of them become obsolete? Circumstances change over time, and your habits that were effective a year or two ago, now could pull your performance down.
Check out how much time to you spend on conflict resolving between several possible actions. Try to extract strict and distinct rules which action in which case you should prefer. This should decrease your waste of time and energy the next time you face similar dilemma.

And, if we back for a while to the first part of the model (“choose/move”):

Try to minimize amount of decisions you need to take during one task. Split big tasks into smaller and well defined steps, so you need to make few small decisions between them. Remove obstacles that pulls you or your teammates away from the streamline (dirty code, small but noisy bugs and so on).
Increase speed of your tools. The faster they give feedback, the less time you waste on waiting.
Remember: there is another way almost everywhere. When you feel struck and cannot see any good next move toward your goal, think for a while. Maybe there is a way for you, but your thought patterns prevent you to spot it?

An important role both in professional music and in martial arts plays the concept of “minimizing waste of energy”. Fingers of a guitar master don’t flicker spontaneously, they are fully controlled. A kung fu master doesn’t hit randomly. Neither should you.

Look at the real master of small decisions!

Bruce Lee. Image from Wikipedia

Watch after his movements from tournament records. He seems to move slow and even lazy, but no one can beat him - because he performs no excess movement, no excess small decision.

The final words

For me, the described model have become surprisingly fruitful. It very well “describes” many effects and problems observed in the IT field. I’m curious why does it happen: either because it’s really good and predictive or because it’s way too fuzzy and allows to gain any answer you want (e.g. it’s actually useless). That’s why I want to provide it onto your court.

What I’d like to cover next:

Gaining and losing experience. Is it always good to know a lot?
Empathy. How could this model help you understand others’ behavior and improve communication?
Team performance. So called “10x programmers”, pair and mob programming, an effect of diversity.
Clean code, dirty code, legacy code. How to deal with entropy.
Maybe something more…

If you like, try to apply the model to given themes for yourself. Will our conclusions match?

I will be very glad to receive your feedback on this topic! Is this model useful for you? Does it provide wrong results? Is this article way too abstract? Is it filled with obvious things?

Comments on this blog are not available yet (sorry!), so I’d like to ask you leave comments under the following tweet:

My new blog on programmer productivity: "A model of small decisions" https://t.co/Pq5ErHztk6
— Andrey Hitrin (@ahitrin) November 3, 2020

References

“Models of Competence in Solving Physics Problems”. Jill H. Larkin, John McDermott, Dorothea P. Simon, and Herbert A. Simon
“Thinking, Fast and Slow”. Daniel Kahneman.

A restart in English

2020-09-30T00:00:00+00:00

Well, this blog seems to stay abandoned for a while. But now I want to launch a new experiment.

My native language is Russian, but the most interesting things in IT happens in English-speaking community. Writing in Russian means writing only for 1% of potential readers. But I have ideas to share, and I want them to be published.

Starting from this moment, I will try to publish new posts in English! For me, it should be a new motivating challenge, for community, new interesting thoughts (hope so).

A quick overview of further plans:

Q: What kind of content do you want to publish?

Mostly new thoughts and ideas (I do have some), and maybe few translations of old posts in Russian (only for the best ones).

Q: What about comments? Will they appear?

It’s quite possible!

Q: New posts in Russian?

Not sure.

Q: Will you separate Ru and En parts?

Not sure. Only in case it’s requested.

Я перешёл в Яндекс

2020-04-28T00:00:00+00:00

Собственно, вся новость в заголовке.

Я 9 лет работал в Naumen. Было там много хорошего, были и плохие моменты, но в целом итог положительный. Тем не менее, 9 лет на одном месте (даже с учётом неоднократных внутренних переходов) - это достаточно для того, чтобы наработаться.

Я решил двигаться дальше, искать новый опыт и новые челленджи. И сейчас оказался в команде Яндекс.Маркет. Посмотрим, что будет дальше!

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

SiebenApp: мой персональный проект

2018-01-24T00:00:00+00:00

Вот уже больше года я потихоньку развиваю свой pet project. Свободного времени на него находится не так уж много, но постепенно проект всё же почти дозрел до уровня бета-версии.

Это персональный десктопный менеджер задач, написанный на Python+Qt. В наши дни менеджеров задач для GTD можно найти в интернете сколько угодно, но у моего есть свои киллер-фичи. Ради них я и взялся за разработку, хотя на это раскачивался очень долго, стараясь использовать существующие решения. В чём же его главная особенность?

Работая программистом, я постоянно сталкиваюсь с сложными задачами. Эта сложность складывается из разных факторов:

Большое количество подзадач: написать кусок функциональности, провести некоторый рефакторинг, проверить гипотезу, обсудить с кем-то вопрос, и так далее.
Непредсказуемая глубина задач. Не так уж редко оказывается, что простой, на первый взгляд, этап оборачивается отдельной крупной задачей с десятками подзадач.
Нетривиальные зависимости между этими подзадачами. Не все из них можно выполнять в произвольном порядке. Часто бывает так, что один шаг блокирует несколько других. Типичный пример - TODO-решение в коде, когда вместо “правильного” решения ставится “костыль” (потому что для “правильного” решения не хватает времени или информации). В этом случае мы не планируем вводить “правильное” решение, пока не получим нужную информацию, или пока не завершим более приоритетные шаги текущей задачи.
Исследовательский характер многих задач. Заранее неизвестно, какой путь к цели является правильным. Приходится пробовать несколько вариантов решения, прежде чем найдётся подходящий.

За фасадом типичных современных таск-менеджеров (по крайней мере, тех, что попадались мне) прячется простая абстракция: плоский список задач. Чтобы немного облегчить жизнь, эти списки можно некоторым образом группировать. Например, карточка в Trello может служить контейнером для нескольких списков. Это достаточно неплохо работает для небольших задач, но и только.

Как, например, работать в том же Trello с задачей, которая из нескольких начальных шагов разрастается до нескольких десятков и длится несколько недель (да пусть даже несколько дней)? Я пробовал применять разные подходы. Если держать всё в одной карточке, то она надолго застревает в списках “Делается”, чем сильно демотивирует. Плюс, становится неудобно работать с подзадачами. Если разбивать задачу на несколько карточек, то теряется связь между ними. Сложнее становится понимать, сколько сделано, а сколько осталось.

В какой-то момент я решил перестать обманывать себя и не пытаться превращать граф подзадач в список. А вместо этого стал работать с ним именно как с графом.

Вдохновением для этого послужила книжка про Mikado Method, который я пробовал применять для рефакторинга. Хорошее описание на русском есть, к примеру, здесь. А начальным инструментом для рисования графа задач стал прекрасный graphviz. Собственно говоря, сам SiebenApp в режиме работы по-умолчанию до сих пор использует graphviz для рендеринга. Хотя это уже скоро изменится.

Мои главные успехи последней недели - это появление более-менее приемлемого “нативного” рендеринга (т.е., средствами Python+Qt, без использования сторонних программ). Для этого пришлось продраться через пару книг по отрисовке графов и как следует поломать голову на практике. Математика там не самая тривиальная, шаг влево или вправо - и ты уже будешь решать NP-полную задачу. Поэтому приходится пробовать разные варианты, опытным путём находить правильный порядок решения задачи, закрывать десятки плодящихся мелких подзадач, а что-то откладывать на потом.

В общем, делать именно то, для чего мне был нужен SiebenApp. Не лишним будет добавить, что управление его развитием я вёл в нём же буквально с первой недели, как взялся за работу. Dog fooding - это реально полезная вещь! Позволяет лучше понимать, в какую сторону следует развивать проект.

Думаю, в ближайшие несколько недель я улучшу нативный рендеринг, и тогда можно будет окончательно отказаться от использования graphviz. Ещё пара улучшений - и приложение можно будет считать готовым для комфортного бета-тестирования. Хотя, по факту, смельчаки могут пробовать его уже сейчас!

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

Надеюсь, он окажется полезным не только мне :)

Корректная работа с PostgreSQL в Docker

2017-10-02T00:00:00+00:00

Интересную проблему удалось решить вчера.

Вот уже несколько месяцев мы в Naumen Phone используем Docker для создания окружения для сборки и тестирования приложений. Технология для этих целей подходит отлично, экономит кучу времени и нервов по сравнению с тем, что было раньше. Образ контейнера создаётся на билд-сервере по рецепту из репозитория (с код-ревью и историей изменений). Он получается по-настоящему иммутабельным - а значит, гарантируется воспроизводимость поведения при локальных запусках и на билд-сервере. Он запускается практически мгновенно, а значит, контейнер не жалко убить и пересоздать заново. На него можно довольно легко писать автотесты (например, на Testinfra), которые тоже выполняются быстро.

Но, как и везде, возникают свои нюансы.

Так как мы перешли на Docker с виртуализованного окружения (Virtualbox/KVM/Vagrant), то многие вещи делаем по старинке, как привыкли на виртуалках. В частности, мы используем для интеграционных автотестов большой “сборный” образ, в котором установлена и СУБД, и пачка наших собственных сервисов, и даже целый systemd (через который запускается всё это хозяйство). Конечно, это далеко от тех же принципов 12 factor app, но в целом в подход each container should have only one concern вписывается. Да и User Experience для разработчиков остаётся почти такой же, как был на VBox+Vagrant, что немаловажно.

Но вот была одна странная проблема, которая долго пила нам кровушку. Почему-то при первом запуске контейнера далеко не сразу становился доступен сервис PostgreSQL. Он, вроде бы, и запускался быстро, и соединения принимал - но затем клиенты отбивались на этапе аутентификации. И сообщение об ошибке мало что говорило нам:

    ВАЖНО:  система баз данных запускается

Это безобразие продолжалось порой по несколько минут, после чего сервер наконец-то становился паинькой и соглашался работать. Вот только далеко не все клиенты были к этому времени готовы работать с ним. То один, то другой сервис не дожидался старта СУБД и отваливался по таймауту. Приходилось ставить костыль в виде shell-скрипта, который дожидается полного запуска PG и после этого перезапускает наши сервисы. При запуске в Vagrant это выглядело сурово:

Однако, как ни странно, если контейнер после работы не удалялся, а просто останавливался (через vagrant halt), то при повторных его запусках проблема уже не повторялась. Старт проходил быстро, и сервисы подключались к базе без проблем.

Это наводило на мысль, что можно попытаться заставить СУБД сделать при создании что-то такое, что она делает во время работы контейнера, чтобы при следующем запуске быстро подняться. Только было непонятно, что же именно делать. Гуглёж по сообщению об ошибке не находил ничего, что наводило бы на суть проблемы.

Пришлось расчехлять strace и смотреть, чем заняты процессы СУБД. Оказалось, что они открывают и закрывают большое количество файлов, в которых СУБД, собственно, и хранит все свои данные. Я включил фантазию и начал гуглить всякие конструкции типа “postgresql slow startup”, “postgresql startup base files” и т.п. По ссылкам встречалось упоминание recovery mode, так что я начал шерстить мануалы на эту тему.

И внезапно нашёл в документации pg_ctl это…

pg_ctl stop [-W] [-t seconds] [-s] [-D datadir] [-m s[mart] | f[ast] | i[mmediate]]

In stop mode, the server that is running in the specified data directory is
shut down. Three different shutdown methods can be selected with the -m
option.  “Smart” mode waits for all active clients to disconnect and any
online backup to finish. If the server is in hot standby, recovery and
streaming replication will be terminated once all clients have
disconnected.  “Fast” mode (the default) does not wait for clients to
disconnect and will terminate an online backup in progress. All active
transactions are rolled back and clients are forcibly disconnected, then
the server is shut down.  “Immediate” mode will abort all server processes
immediately, without a clean shutdown. This will lead to a crash-recovery
run on the next restart.

Если перевести на русский, то у PostgreSQL есть три режима завершения работы:

smart: дожидаться завершения работы всех клиентов, а затем делать бэкап
fast: отбивать всех клиентов, а затем делать бэкап (режим по-умолчанию)
immediate: отбивать всех клиентов и завершаться без бэкапа

Ключевая фраза оказалась в самом конце абзаца: “this will lead to crash-recovery run on the next restart”.

Если запустить PG на “железной” машине или внутри обычной виртуалки, то при корректном завершении работы машины СУБД получит от init соответствующий сигнал и остановится в режиме fast. Но в docker работа завершается через брутальное убийство всего дерева процессов, начиная с контейнерного init. Разумеется, в этой ситуации PG не имеет возможности сделать бэкап. Поэтому мы и получаем “crash-recovery run” при следующем запуске. И пока СУБД не проверит полностью всё своё добро на диске, пока не убедится в корректности данных (или не починит некорректные данные), ни одному клиенту не позволительно подключаться к серверу. Но после прогона этого восстановления база оказывается в консистентном состоянии, поэтому следующие запуски осуществляются быстро.

Значит, чтобы ускорить самый первый запуск контейнера, мы должны дать PostgreSQL возможность сделать online backup при сборке образа.

Проверить эту гипотезу оказалось совсем несложно, так как контейнер создаётся из исходного кода. Я просто добавил одну команду в самом конце скрипта:

su - postgres -c '/usr/pgsql-9.6/bin/pg_ctl stop'

Собрал образ локально, запустил его через Vagrant, и - о чудо! - теперь всё запускается моментально!

Полученные уроки

Очевидный вывод из этой истории может звучать так: know your tools. Не думаю, что наша проблема показалась бы сложной для эксперта по PG. Но… мы не волшебники, мы только учимся. И в том числе на таких вот ошибках - довольно эффективный способ, между прочим :)

Ещё один показательный пример: в проблеме помог разобраться strace. Хотя он и не указал на источник проблемы явным образом, но задал правильное направление для дальнейших поисков. Это безусловное преимущество открытой инфраструктуры GNU/Linux: ни один процесс, запущенный на машине, не является “чёрным ящиком”. Используя правильные инструменты, можно увидеть, чем именно он занят, даже не используя исходники. Хотя, если надо, качай исходники и их тоже используй - красота же!

Ну и не удержусь, порадуюсь ещё раз, что мы наводим порядок в своей инфраструктуре, используя подход infrastructure as code. Я уже наелся за прошлые годы проблем с мутабельными, настраиваемыми вручную виртуалками, проблемы с которыми вопроизводятся ненадёжно, так что нынешнее положение дел радует меня очень и очень.

Чего и вам желаю, мои уважаемые читатели!

P.S.: а мы пойдём вычищать из кода костыли…

Профайлинг нагруженных Python-программ: печальная история со счастливым концом

2017-05-29T00:00:00+00:00

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

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

cProfile и его друзья

Как мы все знаем, в Python есть встроенный профайлер в лице модуля cProfile. Он существует давно, поставляется вместе с интерпретатором, прост в обращении. Разве не это ли нужно для счастья?

Всё было бы славно, если бы не один нюанс. Дело в том, что cProfile - детерминированный профайлер (deterministic profiler). Это значит, что он профилирует все методы. И на вызов каждого метода накладывается некоторое дополнительное время. Достаточно часто это не является проблемой. Но, если мы тестируем приложение, работающее под серьёзной нагрузкой, возникают неприятные спецэффекты.

На днях, запустив профайлер на нагруженный сервис, созданный на основе фреймворка Twisted, я обнаружил странный результат: при вычислении итогового времени работы методов получалось, будто бы больше всего времени (90%) сервис проводил внутри… epollreactor.doPoll. Вот какую картинку показывает grpof2dot (цифра 88.37% справа внизу):

Почему это странно? Потому что системный вызов epoll_wait работает быстро! Приложение не может проводить в нём так много времени. Это подтверждается и независимой проверкой через strace. Обращений к epoll_wait происходит много, но суммарное время, которое тратится на эти обращения, весьма мало.

Но не в том случае, когда мы запускаем программу под детерминированным профайлером! Профайлер добавляет свой overhead на вычисление времени работы метода, сумма этих overhead-ов накапливается и становится больше, чем время работы всех остальных методов. Проблемы тут возникает сразу две:

Приложение начинает работать под профайлером совсем не так, как без него. Оно действительно больше времени тратит на тупление внутри реактора, а на рабочую логику может выделять меньше времени. Соответственно, у него заметно проседает производительность.
Результаты профилирования не соответствуют поведению приложения без профайлера. Из его отчёта совершенно неясно, где же на самом деле тратится время.

Конечно, далеко не все Python-программы используют Twisted с его реактором, поэтому данная проблема может быть для них слабо актуальна. Но мне-то что со своим сервисом делать?

Помимо cProfile, в Python-мире существует ещё несколько разномастных профайлеров, неплохой обзор которых есть на хабре, но они нам тоже ничем не помогут: тоже детерминированные, тоже добавляют существенный overhead, да ещё и требуют модификации исходного кода сервиса, т.к. профилируют только участки, помеченные специальными декораторами.

Какие ещё есть варианты? Есть смысл поглядеть в сторону статистических профайлеров.

(Почти) универсальный солдат perf

Это классический представитель семейства статистических профайлеров. Работает по такому принципу: N раз в секунду снимает текущий стек у приложения и запоминает его. Затем из всех собранных стеков можно сформировать общую картину: какие методы попадаются чаще, какие реже. Такой подход не даёт видеть редкие вызовы методов, но зато достаточно хорошо показывает, где происходят основные задержки, а также меньше влияет на производительность профилируемого сервиса (и меньше искажает картину). Я использую для этого FlameGraph, выходит очень наглядно и удобно.

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

Казалось бы, идеальный инструмент! Но тут возникает новый нюанс: если мы пробуем натравить perf на Python-программу, то увидим не стеки своей программы, а стеки самого интерпретатора Python. perf работает тупо, но честно: “коли мне сказали профилировать интерпретатор, я буду профилировать интерпретатор, а что за код он крутит внутри себя, мне не важно”. Вот только нам от такой информации немного пользы. Разве что можем дополнительно убедиться, что cProfile сильно врёт: показания perf говорят нам, что на epoll тратится вовсе не 90% времени, а какие-то единицы процентов.

Есть ли инструмент, который работает как perf, но при этом позволяет видеть методы Python-сервиса? Как оказалось, есть.

Новая надежда: pyflame

Инженеры из Uber сделали для нас такой инструмент. Он присоединяется к Python-программе с помощью вызова ptrace, считывает состояние из структур интерпретатора и выводит данные в формате, пригодном для построения FlameGraph-ов. Профилирование тоже производится статистически, его частоту можно варьировать. Это именно то, что мне нужно!

Хотя свои недостатки у этого инструмента тоже есть.

Во-первых, готовые бинарники есть только под Ubuntu и Arch. Если Вы используете другой дистрибутив (например, любой RPM-based), придётся расчехлять компилятор и собирать приложение вручную. Но это почти тривиально! Сначала ставим нужные для сборки пакеты:

autoconf automake libtool gcc-c++

Затем можно собрать приложение:

./autogen.sh
./configure
make

Если сборка прошла успешно, то в папке src появится файл pyflame, который и будет работать профилировщиком.

После этого можно присоединяться к запущенному приложению и добывать из него стеки!

./src/pyflame -s 60 -r 0.01 <pid> > my_service.flame

Показал бы тут и итоговый flamegraph, но, боюсь, это уже будет нарушать NDA :) Лучше посмотрите примеры из самого PyFlame или попробуйте построить их сами. Просто скажу, что мы здесь получаем именно то, что было нужно: нормальные питонические стеки с указанием частоты попадания в каждый отдельный из них. Чем шире строчка для функции, тем чаще мы в неё попадали, а значит, тем больше времени уходит на её выполнение.

Есть ещё пара важных особенностей, про которые надо знать, применяя pyflame.

В итоговом графе значительную часть времени может занимать строчка “(idle)”. Как разработчики пишут в документации, это время соответствует тем семплам, когда никакой Python-код не держит GIL (т.е., не выполняется). В это время может происходить другая работа в соседнем потоке, но для pyflame она не видна. Её можно сделать видимой, если при запуске указать флаг --threads, но на относительно старых ядрах Linux это может приводить к зависаниям профилируемого приложения. Либо включаем опцию на свой страх и риск, либо миримся с наличием (idle), либо отключаем статистику по нему с помощью флага -x.
В некоторых ситуациях, как мне показалось, pyflame не выводит никаких данных. Скорее всего, это происходит, если профилируемое приложение внезапно завершилось (например было перезапущено). Либо, если профилирование было очень коротким. Отсюда вытекает рекомендация: период профилирования должен быть достаточно длинным (как минимум, несколько десятков секунд). Впрочем, для статистического профайлера это в любом случае необходимо - иначе его результаты будут не особо точными.

Подводя итоги

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

Но есть и ещё один полезный урок: даже если кажется, что подходящий инструмент найден, совсем не лишней будет проверка корректности его показаний. Именно такая проверка показала, что cProfile не подходит конкретно в моём случае, и вынудила меня искать альтернативы. Посмотрим, насколько правдив окажется и сам pyflame. Время покажет!

Комментарии Disqus отключены

2017-04-26T00:00:00+00:00

Я порядком устал за прошедшие годы от возни с настройкой комментариев через Disqus. Старые комментарии пропали, с новыми непонятно, появляются ли.

А ещё на Хабре пишут про нехорошее поведение сервиса: тотальная слежка за пользователями, сильное замедление загрузки, перехват кликов и т.п.

Вот я и подумал - зачем оно мне нужно?

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

Для связи со мной можно использовать любой канал со страницы “Кто я такой”.

Рабочий дневник программиста

2017-03-25T00:00:00+00:00

wikipedia.org

Хочу немного рассказать про полезную рабочую практику, которая уже не первый год здорово помогает мне. Как ни странно, далеко не все разработчики этим пользуются. Наверно, большинству просто не приходило в голову. Заполним пробел, проведём сеанс ликбеза.

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

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

В общем, стараюсь сохранять всё более-менее полезное.

Выглядит это обычно как-то так:

Как именно это помогает

Разгружаем голову! Чем больше мыслей нужно держать в памяти одновременно, тем меньше ресурсов остаётся на сами размышления. Записывать все планы и задачи - базовый принцип техники GTD. Для разработчиков это особенно актуально: обычно нам приходится иметь дело с очень сложными задачами, которые сложно загрузить в голову целиком. Скидывая мысли и идеи в дневник, мы освобождаем голову для размышлений.

Проще вспомнить подробности решения задачи. Для многих программистов (и для knowlege workers в целом) самым продуктивным режимом работы является “поток” - полное погружение в одну задачу. Длительная концентрация внимания на одной цели без переключений на другие. Тем не менее, рано или поздно приходится делать перерыв и заниматься чем-то другим (хоть даже домашними делами), а к текущей задаче возвращаться спустя некоторое время. С помощью дневника можно быстрее вспомнить, на чём мы остановились в прошлый раз, и куда надо двигаться дальше. Экономится время и силы на возврат в поток.

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

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

Формализуем непонятную проблему - так её легче решать. Многие знают так называемый “метод утёнка”, который помогает решать непонятные вопросы. Подробно рассказываешь свою проблему слушателю (в роли которого может выступать даже простая игрушка), и нередко получается так, что пока формулируешь проблему, мозг находит её решение.

Такой подход замечательно работает и без слушателя! Достаточно лишь взять и подробно расписать свою проблему в дневнике, чем подробнее, тем лучше. И это классно, особенно для интраверта: тихо что-то сам себе печатаешь и сам находишь решение. Ни с кем разговаривать не нужно - красота!

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

Недостатки дневника (или нет?)

Несложно увидеть и слабые стороны этого подхода. Впрочем, не такие уж они и страшные!

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

С другой стороны, авральное состояние - вещь достаточно противоестественная для интеллектуального работника. В таком режиме сложно делать вещи качественно, очень возрастает риск где-нибудь ошибиться. Ошибки приводят к новым авралам, а там недалеко и до сваливания в смертельный штопор!

В такие моменты бывает лучше притормозить, немного подумать, чётко осознать причины проблемы - и сделать всё правильно. Не так уж редко оказывается, что первое пришедшее в голову решение правильным вовсе не является :) Думаю, вы уже поняли, к чему я веду: замедляться при решении задач бывает не только не-вредно, но и полезно. И дневник в этом только поможет!

К слову, ничто не мешает описать сделанную работу в дневнике сразу после аврального фикса.

Alice Sleeping

Дублирование работы. Уверен, у многих читателей к этому времени уже созрел такой вопрос: “У нас ведь уже есть командный таск-трекер, разве его недостаточно для журналирования?”

Однозначного ответа на этот вопрос у меня нет. Обстоятельства у всех разные, и было бы неправильно подходить ко всем с одной меркой. Могу сказать лишь за себя самого. В дневник я позволяю себе записывать абсолютно что угодно. Самые мелкие напоминалки для себя, вопросы “эту штуку сделал, что делаем дальше?”, ключевую фразу “я туплю” и так далее. Порой это десятки записей в день! Если всё это писать в таск-трекер, коллеги взвоют из-за объёмов спама и навечно забанят меня :)

Поэтому в трекер уходят только отфильтрованные записи. Copy & paste, copy & paste… Дублирование усилий получается, но не настолько уж большое. Суммарные преимущества дневника всё равно перевешивают.

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

Бывали и у меня периоды, когда я сдавался и временно отступал от ведения дневника. Но всё же неизменно раз за разом возвращался к этой практике, слишком уж велики её преимущества!

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

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

Полезные приёмы

Упомяну также несколько дополнительных хитростей, которые помогают в работе над дневником.

Выбираем формат дневника. Простого plain text не всегда бывает достаточно, когда мы работаем с кодом. Сам я использую markdown и вполне им доволен: синтаксис поддерживается всеми популярными редакторами, удобно визуально выделять заголовки, код, цитаты и т.п. Но остерегусь навязывать Markdown читателю. У этого формата есть альтернативу, например: Restructured Text, Wiki, Orgmode. Главное, что требуется от формата - не вызывать раздражения при чтении и записи - ведь иначе дневник долго не проживёт!

Используем сниппеты. Некоторые операции приходится чаще других при работе с дневником. Например, я привык начинать очередную запись с отметки времени, чтобы потом проще было ориентироваться. Довольно очевидно, что вводить дату каждый раз руками слишком утомительно (порой десятки раз в день!). Здесь стоит обратиться к возможностям текстового редактора, чтобы облегчить себе труд. Я привык работать в Vim, а для него есть отличный плагин Snipmate. Теперь мне достаточно написать слово time, нажать Tab - и отметка времени генерируется автоматически! Аналогичные примочки есть, пожалуй, у каждого продвинутого текстового редактора.

Храним бэкапы. Чем дольше вы ведёте дневник, тем большую ценность начинает представлять сохранённая в нём информация. Не лишним будет позаботиться о её сохранности! Я настроил автокоммит в git и бэкап в bare-репозиторий внутри Dropbox по cron-у. Теперь можно спать спокойно и не бояться, что дневник пропадёт вместе со сдохшим диском.

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

Представим, что мы работаем над веб-приложением, и натыкаемся в нём на ошибку. Много ли будет пользы от дневника, который ведётся так?

Я что-то нажал, и всё сломалось :(((((

Куда полезнее будет, если в запись попадёт и конкретная страница приложения, и проблемная кнопка на ней, и текст ошибки.

В заключение

wikipedia.org

Я не претендую на лавры первооткрывателя этого метода. Прошаренные товарищи с успехом используют его уже не одну сотню лет.

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

Эта же статья на хабре.

Автоматический поиск ошибок в Java-коде через генерацию тестов

2015-12-10T00:00:00+00:00

Почитал с утра пару статей по delta debugging. Не могу теперь выкинуть из головы идею.

Простой и автоматический поиск ошибок

Допустим, у нас есть большой унаследованный класс GodlikeEnterpriseStaffController, который хочестя покрыть тестами. Но так как он большой и унаследованный, сделать это сложно, долго и трудно.

Однако, представим, что у нас есть некая библиотека. Мы говорим ей “протестируй-ка нам класс GodlikeEnterpriseStaffController, вот тебе ссылка на объект”. Та что-то шурудит у себя в кишках, а потом выдаёт примеры тест-кейсов типа:

Вызываем метод GodlikeEnterpriseStaffController.createFoo()
 * тот создаёт файл new File(...)
 * создание файла падает с исключением из-за отсутствия прав доступа
 * метод createFoo() падает с неожиданным IOException, хотя не должен

Как бы такая библиотека работала под капотом?

Реализация

Используя Reflection, мы можем получить список методов класса, а также их параметры. Используя этот набор данных, библиотека может сгенерировать произвольную цепочку вызовов к данным методам, используя произвольные параметры. Если во время вызова с классом происходит что-то непотребное, то данный набор вызовов обрабатывается с помощью delta debugging, чтобы превратиться в минимальный падающий тест-кейс. Который и показывается пользователю.

Однако тут возникает вопрос - что делать с зависимостями? Как правило, классы не живут в изоляции (а наш GodlikeEnterpriseStaffController тем более). Что делать с различными обращениями к зависимостям?

Ответ прост и брутален: все зависимости заворачиваются в моки. Для каждого метода мы снова можем определить через Reflection набор параметров и возвращаемые значения - и снова генерируем для них произвольные возвращаемые значения. В итоге, когда тестируемый класс делает вызовы других классов, то он получает полный ушат случайных значений в ответ. Либо, если в сигнатуре вызваемого метода прописана возможность выкинуть исключение, получает это исключение. Либо что-то ещё неприятное.

Профит

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

Более того, такой подход, на первый взгляд, намного привлекательней, чем обычный TDD или, тем более, property-driven testing. Программисту не нужно ни придумывать тест-кейсы, ни формулировать инварианты - просто брать и скармливать тест системе. Шикарно ведь, правда?

Почему это не будет работать

В теории это всё хорошо, но на практике реализация подобной системы, скорее всего, столкнётся с рядом серьёзных вызовов.

Невозможность проверять бизнес-логику. Конечно, с помощью такой системы можно достаточно легко находить всякие NullPointerException, но такие находки могут оказаться максимумом, на что она способна.
Нереалистичные тест-кейсы. Созданные системой кейсы могут не отражать реальность, в которой выполняется код. Например, не учитывать, что одна из завимостей тестируемого класса является синглтоном (два разных обращения к зависимости создадут два разных мока). Или не учитывать неявный контракт класса: в метод передаётся интерфейс, который внутри кастуется в конкретную реализацию этого интерфейса (да, это bad practice само по себе; однако без учёта подобной специфики мы упадём на первой строчке тестируемого метода с ClassCastException, а с учётом смогли бы пройти дальше). Как результат, все генерируемые тест-кейсы малополезны для реального применения.
Возможно, какие-то зависимости чисто технически сложно превращать в моки.

Конечно, несложно придумать способы борьбы с такими проблемами. Например, мы можем добавить настройку окружения, в которой прописываем некоторые предположения относительно того, как следует генерировать варианты для зависимостей. Или указывать, что надо тестировать не один класс в изоляции, а некоторую группу классов (т.е., не заменять часть зависимостей на моки). Однако всё это компрометирует изначальную идею “просто скормил класс системе и получил результат”.

Итого

Я подозреваю, что идея далеко не нова, и кто-то её уже давно высказывал. Возможно, даже какая-то из существующих систем работает подобным образом (какой-нибудь Quviq QuickCheck или Conjecture; трудно об этом судить, не попробовав их в деле). Всё, что у меня пока что есть, - это мысленный эксперимент. Пускай пока в таком виде и остаётся.

Facebook Infer

2015-06-18T00:00:00+00:00

На днях Facebook выпустил новую утилиту для статического анализа кода на Java/C. Не смог пройти мимо, решил натравить его на ServerAccess.

В целом, делается это довольно тривиально: качаем, запускаем…

ahitrin@ahitrin:~/projects/ServerAccess$ ./gradlew clean
:clean

BUILD SUCCESSFUL

Total time: 2.756 secs

Если не сделать clean, то ленивый Gradle ничего не будет компилировать, и Infer не найдёт никаких ошибок. А после очистки сразу что-то нашёл!

ahitrin@ahitrin:~/projects/ServerAccess$ ~/opt/infer-linux64-v0.1.0/infer/infer/bin/infer -- ./gradlew build
Starting analysis (Infer version v0.1.0)
Analysis done

77 files analyzed


/home/ahitrin/projects/ServerAccess/src/main/java/ru/naumen/servacc/HTTPProxy.java:96: error: RESOURCE_LEAK
   resource acquired by call to accept() at line 95 is not released after line 96

/home/ahitrin/projects/ServerAccess/src/main/java/ru/naumen/servacc/HTTPProxy.java:99: error: RESOURCE_LEAK
   resource acquired by call to ServerSocket(...) at line 92 is not released after line 99

/home/ahitrin/projects/ServerAccess/src/main/java/ru/naumen/servacc/settings/PropertiesFile.java:56: error: RESOURCE_LEAK
   resource acquired by call to FileOutputStream(...) at line 52 is not released after line 56

/home/ahitrin/projects/ServerAccess/src/main/java/ru/naumen/servacc/settings/PropertiesFile.java:60: error: RESOURCE_LEAK
   resource acquired by call to FileOutputStream(...) at line 52 is not released after line 60

/home/ahitrin/projects/ServerAccess/src/test/java/ru/naumen/servacc/test/settings/FileUtils.java:34: error: RESOURCE_LEAK
   resource acquired by call to FileWriter(...) at line 32 is not released after line 34

/home/ahitrin/projects/ServerAccess/src/test/java/ru/naumen/servacc/test/settings/FileUtils.java:46: error: RESOURCE_LEAK
   resource acquired by call to FileReader(...) at line 40 is not released after line 46

Завёл баг, буду на досуге копаться.

Что бы ещё теперь проверить?

UDP: а вот ещё что обнаружилось…

Оказывается, что, в отличие от других средств анализа (FindBugs, PMD,..) у infer есть интересный режим работы: показ целого трейса, где происходит утечка. Это что-то новенькое!

ahitrin@ahitrin:~/projects/ServerAccess$ ~/opt/infer-linux64-v0.1.0/infer/infer/bin/inferTraceBugs --select 4 --max-level max
/home/ahitrin/projects/ServerAccess/src/test/java/ru/naumen/servacc/test/settings/FileUtils.java:34: error: RESOURCE_LEAK
   resource acquired by call to FileWriter(...) at line 32 is not released after line 34

Showing all 5 steps of the trace

/home/ahitrin/projects/ServerAccess/src/test/java/ru/naumen/servacc/test/settings/FileUtils.java:29: start of procedure write(...)
27   public class FileUtils
28   {
29 >     public static void write(File file, String contents) throws IOException
30       {
31           file.createNewFile();

/home/ahitrin/projects/ServerAccess/src/test/java/ru/naumen/servacc/test/settings/FileUtils.java:31:
29       public static void write(File file, String contents) throws IOException
30       {
31 >         file.createNewFile();
32           PrintWriter writer = new PrintWriter(new FileWriter(file));
33           writer.print(contents);

/home/ahitrin/projects/ServerAccess/src/test/java/ru/naumen/servacc/test/settings/FileUtils.java:32:
30       {
31           file.createNewFile();
32 >         PrintWriter writer = new PrintWriter(new FileWriter(file));
33           writer.print(contents);
34           writer.flush();

/home/ahitrin/projects/ServerAccess/src/test/java/ru/naumen/servacc/test/settings/FileUtils.java:33:
31           file.createNewFile();
32           PrintWriter writer = new PrintWriter(new FileWriter(file));
33 >         writer.print(contents);
34           writer.flush();
35       }

/home/ahitrin/projects/ServerAccess/src/test/java/ru/naumen/servacc/test/settings/FileUtils.java:34:
32           PrintWriter writer = new PrintWriter(new FileWriter(file));
33           writer.print(contents);
34 >         writer.flush();
35       }
36

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

О темпоральной логике

2015-06-05T00:00:00+00:00

Давеча позволил себе немного пожаловаться в твиттер:

Человеческий мозг крайне плохо умеет работать с темпоральной логикой - вот причина многих ошибок в #IT
— Andrey Hitrin (@ahitrin) June 2, 2015

Особенно, если изменения затрагивают несколько систем
— Andrey Hitrin (@ahitrin) June 2, 2015

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

Пускай у разработчика есть система А и система B. Они каким-то образом друг с другом взаимодействуют. И в один прекрасный момент возникает необходимость что-то поменять в одной из этих систем (пускай, A → A’).

Окей, говорит себе разработчик, тыжпрограммист! Система A меняется, значит, надо поменять и систему B, чтобы она знала про эти изменения. Берёт и адаптирует систему B к новым изменениям (B → B’), и думает, что молодец.

А затем, в продакшене, оказывается, что системы могут обновляться по отдельности, и наша система A’ встаёт рядом с необновлённой B. Или, наоборот, B’ пытается ужиться со старой A.

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

И это, разумеется, приводит к появлению самых разнообразных отказов и фейлов, про которые никто не подумал заранее.

Мораль у сказа до тупости простая: разработка ПО - это не та область деятельности, где годится применять экономию мышления, столь любимую нашим ленивым мозгом. На любое изменение полезно смотреть не только в статике (“как есть сейчас” vs. “как должно быть”), но и в динамике (“как пройти из A в A’ и ничего не сломать по дороге”). Можно называть этот подход хоть “темпоральной логикой” (по определению: учёт причинно-следственных связей в условиях времени), хоть системным анализом, хоть continuous delivery, хоть горшком - но только ~~в печку не ставить~~ не забывать.

MindMapping в графовых базах данных

2014-06-01T00:00:00+00:00

В голове уже очень долго созревала одна идея, и вчера она наконец-то материализовалась в своего рода озарение.

Наверняка многие знакомы с концепцией Mind Mapping’а (не перевожу, потому что устоявшийся перевод мне не по душе). Я тоже давно и с удовольствием использую эту методику, когда мне нужно проанализировать сложный вопрос.

Однако существующие инструменты (например, Freemind, XMind, mindmup), хоть и хороши, оставляют желать лучшего в некоторых случаях. Например, порой хочется довольно странных вещей: вводить разные категории для узлов, разные категории для связей, фильтровать их по различным условиям, добавлять развёрнутые описания и т.п. Существующие инструменты этого, как правило, не позволяют (либо позволяют, но не дают желаемой гибкости и удобства).

Но стойте, у нас же есть целый класс инструментов, которые предназначены именно для того, чтобы хранить самые разнообразные графы любых форм и цветов! Имя им - “графовые базы данных”. Что будет, если мы возьмём такую базу данных и начнём строить наш mind map в ней? Вот я вчера и решил это попробовать.

Чтобы не ходить далеко, взял первую же БД, про которую вспомнил: Neo4J. В качестве рабочего примера решил расписать схему проблем, с которыми я сталкиваюсь при работе над ServerAccess. В этом проекте большое количество унаследованного, тесно связанного кода, и при добавлении новых фич значительную часть времени приходится тратить просто на то, чтобы не превратить код в свалку костылей. Есть хороший метод (Mikado Method), позволяющий разбирать такие кучи, но он требует аккуратного составления карты проблем. Так что, я решил убить сразу несколько зайцев: и опробовать Neo4J в деле, и составить схему проблем SA.

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

Однако, некоторые интересные выводы можно сделать уже сейчас.

Первое чёткое впечатление: скорость работы пользователя через СУБД заметно ниже, чем в специализированных инструментах для MindMapping’а. Это вызвано тем, что для заведения узла требуется набить руками кусок кода приличного размера, а не просто лупцануть по Enter. Думаю, даже когда у меня будет больше опыта в Cypher, скорость работы вряд ли достигнет сравнимых показателей. Поэтому для простых и быстрых карт графовая БД однозначно не подходит, и следует без колебаний выбирать специализированный инструмент.

Тем не менее, возможности БД по работе с графами внушают оптимизм. Чувствуется, что база данных не ограничивает тебя, а, наоборот, позволяет настроить себя под твои нужды максимально точным образом. Можно ввести произвольные “типы” для узлов (в Neo4J это называется Labels), добавлять им произвольные свойства, создавать между ними связи разных типов (и тоже со своими свойствами), превращать свойства в новые узлы, превращать узлы в свойства, фильтровать сущности произвольным образом…

Веб-интерфейс Neo4J - это вообще шедевр, который заслуживает отдельной похвалы. Пожалуй, стоило поставить себе эту СУБД, чтобы хотя бы поглядеть, как следует работать с современным вебом. Совершенно не ожидал такого изящества от “обычной базы данных”.

Впрочем, посмотрим, как дело пойдёт дальше. Справится ли Neo4J с моими потребностями, и справлюсь ли я сам с Neo4J. Будет ли удобно поддерживать и развивать базу данных по мере её роста. Хватит в работе ли веб-морды, или потребуется создавать собственные дополнительные инструменты. Поживём - увидим!

Braindump

2014-03-16T00:00:00+00:00

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

Со всей GTD-шной организацией задач у меня давно была одна неувязка: куда и как записывать? Вот сижу я за компом, и надо по-быстрому избавиться от мысли в голове. И каждый раз это целая проблема. Проблема выбора.

Записать её куда-то на локальный диск? А как потом найти то, что записал? Как найти эту запись на другом компьютере?

Записать в веб-сервис? Какой? Открывать браузер и открывать какую-то страницу? Долго и неудобно.

Куча вопросов, и все отвлекают от главной задачи: сбросить текущие мысли из головы. Ведь это всё, что на самом деле нужно в данный момент.

Каждый решает эту проблему по-своему, и я тоже, в конце-концов, нашёл рабочий вариант. Всё делается сурово и по-программистски.

Брэйндамп!

Шаг первый: пишем труъ-скрипт:

% cat ~/bin/braindump
#!/bin/bash
now=`date +"%Y-%m-%d-%H-%M"`
cd ~/opt/Dropbox/braindump/
find . -name \*.md -size 0 -delete
gvim -c "set spell" -c "call system('wmctrl -i -b add,fullscreen -r'.v:windowid)" ${now}.md

Что он делает:

запускает GVim в полноэкранном режиме и с проверкой правописания
настраивает редактор на запись в Markdown-файл в специальной папке
а перед этим чистит все пустые файлы в этой папке

Шаг два: создаём desktop-файл для запуска этого скрипта:

% cat ~/.local/share/applications/braindump.desktop
#!/usr/bin/env xdg-open
[Desktop Entry]
Version=1.0
Type=Application
Terminal=false
Exec=~/bin/braindump
Name=Braindump
Icon=/usr/share/pixmaps/vim.svg

Шаг три: используем Synapse для реактивного запуска новоиспечённого инструмента braindump.

Конечно, Synapse не идеален, но для меня он стал самым удобным и быстрым способам запускать любые десктопные программы. Пальцы легко запоминают нужные комбинации клавиш и запускают любую программу за доли секунды. В том числе и мой Braindump.

Что имеем в итоге

Самое главное - это выработать в себе привычку разбирать записи. После этого Braindump начинает работать как часы.

Возникла мысль, которую надо срочно записать? Быстрая пробежка по клавиатуре - и практически сразу открывается окно, в котором можно начинать писать. Не надо думать о том, где сохраняется запись - просто записал её и вышел из редактора. Не надо думать о синхронизации записей - обо всём позаботится Dropbox. В полноэкранном режиме ничего не отвлекает от мысли. Работает привычное Markdown-форматирование - можно сделать всё красиво.

Появилось свободное время, которое можно потратить на разбор задач? Снова открываем Braindump, а в нём - это же обычный Vim! - список сохранённых файлов (я использую для этого удобнейший плагин NerdTree). Разбираемся со всеми записями (чаще всего у меня они уходят в Trello) и просто удаляем их из файла. Сам файл нет нужды трогать - он уйдёт при следующем запуске Braindump. Даже если я ещё не придумал, куда девать очередную запись, она может некоторое время пожить. Но в целом стараюсь не запускать ситуацию. Нет ничего лучше пустого inbox-а.

После изобретения этого велосипеда жизнь моя стала легче (а волосы мягче и шелковистей). Приятно, что удалось обойтись существующими и привычными инструментами, а не городить что-то новое. По сути, я не решил проблему выбора “куда поместить идею из головы”, а всего лишь отделил её от сохранения самой идеи. Оно и правильно.

Всем прочитавшим хорошего дня и шикарных идей (которые никуда не теряются)!

Новогодний шоппинг

2014-01-05T00:00:00+00:00

Перед Новым Годом удалось закупиться некоторым количеством книжек. Для удобства обзора разбил их по категориям.

Управление проектами

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

Психология

Крайне полезная категория. Управление проектом под названием “я сам”.

The Naked Presenter, чтобы эффективнее выступать с презентациями.
Are Your Lights On?, чтобы мозги работали как надо.
Ментальные ловушки, чтобы не попадаться в эти ловушки.

Прочее

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

ATDD. Разработка программного обеспечения через приемочные тесты

Благодарности

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

При выборе книг по Lean я ориентировался на вот этот список от месье Юргена Аппело. За что ему хочется послать огромное виртуальное “спасибо”.

И спасибо Юре Антонову, который попросил меня рассказать о покупках. Без него этого поста и не было бы!

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

The Joy Of Fireplace

2013-12-19T00:00:00+00:00

Я давно присматривался к замечательному языку Clojure, но никак не мог начать строить с ним хорошие отношения. Проблема банальная: никак не мог найти удобную среду разработки, в которой чувствовал бы себя комфортно и понимал, что происходит. Исторически, самая лучшая поддержка LISP-языков “из коробки” встроена в великий и ужасный Emacs. Но с ним не дружат мои пальцы.

Первые попытки подружить Clojure и мой любимый Vim я осуществлял ещё пару лет назад, но все они потерпели крах. Выбор был невелик. Либо скрепя сердце переходить на пальцеломный Emacs, либо заниматься бесконечной обезъяньей копипастой из редактора в REPL и обратно. Либо пинать страшный, тяжеловесный, мышевозный, недоделанный LightTable.

Но страдания наконец-то закончились, раз и навсегда!

Теперь, чтобы эффективно работать на Clojure в Vim, достаточно знать всего два слова: Lein и Fireplace. Первый и так является стандартом де-факто в Clojure-разработке (насколько мне известно). А второй, видимо, станет любимой игрушкой кложуристов-вимеров. Плагин подкупает удобством и лёгкостью освоения. Достаточно просто запустить lein repl, зайти vim-ом в папку проекта и открыть любой .clj-файл. После этого любой его кусок можно отправлять в REPL, вычислять любые выражения, обрабатывать код почти со скоростью мысли. Вырастать из штанишек упражнений и начать создавать свои маленькие проекты.

Самое главное: использовать Lein версии не ниже 2.0. Т.е., если в репозитории используется более старая его версия (привет, Ubuntu!), просто используйте инсталлятор с официального сайта.

Пишите на Clojure и радуйтесь!

Trello Checklists

2013-07-09T00:00:00+00:00

Trello - бесплатный и очень удобный инструмент для управления задачами. Я раскидываю в нём свои задачи, рабочие и личные. А недавно нашёл ещё одно применение.

При запуске очередной итерации в скраме требуется выполнять целый ряд бюрократических операций. Чтобы ничего не забывать, я завёл отдельный чеклист, в котором перечислил все задачи. Теперь этот процесс стал куда менее напряжным (хотя и по-прежнему занимает довольно много времени). Не нужно каждый раз напрягать память и вспоминать, всё ли ты сделал. Более того, сейчас я могу легко тюнить процесс: менять очерёдность шагов, добавлять новые, убирать ненужные.

Даже немного удивительно, что решение было под носом, а искать его пришлось несколько месяцев.

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

Jenkins Copy Artifact Plugin

2013-06-22T00:00:00+00:00

Допустим, у вас есть несколько задач в Jenkins, и между ними надо передавать параметры. Например, номер версии.

Макс Захаров в своё время зарекомендовал мне плагин под названием Jenkins Parameterized Trigger plugin. Вот его подробная статья про автоматизацию тестирования, кстати.

Но есть более удобный способ делать это. Просто используйте Copy Artifacts Plugin. Первая задача может создавать небольшой текстовый файл, в который записывается номер версии. В конце сборки заархивируйте этот файл. А в следующие задачи добавьте шаг Copy artifacts from another project, чтобы они забирали этот файл.

Плюсы этого подхода:

Это естественный для jenkins способ связывать задачи друг с другом. Если вы хотите отслеживать взаимосвязь, то всё равно придётся передавать какие-то файлы
Это удобнее, чем текстовый параметр. Опечататься невозможно.
При ручном запуске задачи будет нужно жать на кнопку всего один раз :)

Важные нюансы:

Не забывайте про архивирование. Чтобы файл можно было использовать в других задачах, его предварительно надо заархивировать.
Будьте внимательны к правилам, которые используются у вас для удаления старых сборок. Если есть риск того, что сборка головной задачи может исчезнуть до того, как запустится самая последняя задача в цепочке, то более безопасно будет копировать артефакт с одной задачи на другую (и архивировать на каждой). Это получается не так изящно, зато более надёжно.

Eclipse 4.3 Changelog

2013-02-13T00:00:00+00:00

Из твиттера пришла очень весёлая ссылка, вот я и решил сделать перевод на скорую руку.

Приятно чувствовать что я далеко не одинок в нелюбви к Eclipse.

К сожалению, пару моментов в конце недопонял.

Eclipse 4.3 changelog

В словарь добавлено слово “Eclipse”
Исправлена ситуация, в которой Eclipse не мог беспричинно упасть
Усилена насыщенность иконки приложения
Все пункты меню распечатаны на бумаге, бумага разрезана на полоски, полоски развеяны по ветру. Меню Eclipse изменено в соответствии с новой конфигурацией
Добавлена шестисекундная задержка к автодополнению кода
Добавлена восьмисекундная задержка к реакции на клавиатуру
Изменён размер изображения на сплэш-скрине
Добавлена десятисекундная задержка к сплэш-скрину
Вызовы malloc( переопределены на malloc(2*
Исправлена необычная ситуация, когда окно редактора кода отзывается на действия пользователя
Удалён пункт меню “Проверить обновления”; его функциональность перемещена в отдельную гигантскую тяжеловесную панель, потому что не пойти бы вам…
Исправлена ситуация, в которой парсер XML мог обнаруживать ошибки, не завесив при этом Windows
Удалены и исправлены несколько интуитивных, юзабельных диалоговых окон
Начато использование системы контроля версий
Почуствовал себя достаточно хорошо, чтобы закрыть ящик с оружием на целых десять минут (?) - Felt good enough to lock the gun drawer for ten whole minutes
~~Переписали всё на C/С++~~
(Неудачно) попытался пересечь церковную ограду (?) - Triead and failed to cross the threshold of church

I hope you enjoy it too.

Три Новых Консольных Утилиты Для Счастья

2012-12-15T00:00:00+00:00

В последнее время я добавил в свой арсенал консольных утилит три новые штучки, которые приносят заметную пользу. Захотелось написать про них пару слов.

Всё написанное ниже стоит рассматривать через призму “я линуксоид, который уйму времени проводит в консоли”. Если для Вас это не верно, то мой опыт вряд ли окажется полезным.

Tmux

Первым на сцену выходит terminal multiplexer. Я давно уже слышал о великом противостоянии Screen vs. Tmux, и всё хотел попробовать их в деле и определиться со своей стороной. Когда же наконец решился, выбор оказался до безумного прост.

Всего два дня на #tmux, и я уже не понимаю, как жил без него раньше ;(
— Andrey Hitrin (@ahitrin) November 20, 2012

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

Теперь есть табы даже в банальном xterm, и, что важнее, рабочая сессия доступна и с планшета, и с ноута из дома - был бы только ssh-доступ
— Andrey Hitrin (@ahitrin) November 20, 2012

Но ещё более приятным оказалось возможность открывать несколько терминалов в одном табе. Если они связаны единой задачей, то такой способ размещения оказывается наиболее естественным и удобным. Вся необходимая информация оказывается на одном экране. В каком-нибудь gnome terminal в этом случае всё равно пришлось бы скакать между разными вкладками (и ещё всё время вспоминать, на какую конкретно надо перейти).

Не обошлось и без маленькой ложки дёгтя. Мои пальцы теперь стали иногда вызывать хоткеи tmux в vim. Неприятный сайд-эффект, но, думаю, я с ним разберусь.

t

Я использую несколько разных таск-трекеров, каждый для своей цели. Официальный рабочий инструмент - это Redmine, главный личный инструмент - это Google Tasks. Но они оказываются слишком громоздкими, когда ты разбил большую задачу на много мелких частей и пытаешься быстро добавлять и удалять их в ходе работы.

Покопавшись в памяти, я внезапно нашёл решение и опробовал его в деле.

t stevelosh.com/projects/t/ отлично подходит для управления кучей мелких текущих задач, которые нет смысла трекать в серьёзных менеджерах
— Andrey Hitrin (@ahitrin) November 30, 2012

Всё очень просто и удобно. Пришла мысль в голову - тут же записал её, не отрываясь от консоли: t какая-то задача. Самое крутое в том, что не надо ничего дополнительно открывать, ничего дополнительно запускать, не надо думать, куда отправится задача. Ты её просто записал, и она просто сохранилась.

Затем смотрим список всех задач, выбираем ровно одну и доводим её до конца. Вычёркиваем из списка и выбираем новую. В процессе работы возникает важная мысль - просто кидаем её в t. Разберёмся потом. В общем, стандартный GTD-процесс :)

Одной из фич t является то, что список задач никак не упорядочен. Честно говоря, иногда хочется чего-то более упорядоченного. Например, во время рефакторинга кода с применением Mikado Method, когда все цели зависят друг от друга. Было бы круто найти (или, на крайний случай, сделать) что-то подобное для mikado. Будет удобно.

ssh-agent

На эту тему никаких твитов не было :)

Всё довольно тривиально. Если Вы часто работаете с ssh, то знаете, что он часто просит пароль. Если использовать ключи, то они тоже просят пароль. При частом общении с ssh (например, во время активной синхронизации с внешними серверами в git) это быстро становится довольно утомительным. ssh-agent - это один из механизмов, которые позволяют ввести пароль лишь однажды за сессию, а затем поручить этот процесс машине.

Конечно, при работе под Gnome или KDE есть свои графические аналоги ssh-agent, которые решают ту же задачу. Но ведь на них не заканчивается список оконных менеджеров, верно? На рабочем компьютере я сейчас использую Openbox, потому что он работает быстрее и почти не сношает мозг, в отличие от. Поэтому ssh-agent пришёлся мне вполне ко двору.

В общем, просто оставлю здесь мануал по этой полезной утилите.

Послесловие

Описывая все эти инструменты, я чувствовал себя в некотором роде слоупоком. В самом деле, все они уже достаточно давно существуют и довольно широко известны (за исключением t, пожалуй). С другой стороны, для кого-то другого эта информация может оказаться новой и (скромно надеюсь) полезной. На пути к совершенству много шагов, и каждый из них важен. Я стал чуть более продуктивен с tmux, чуть более организован с t и испытываю меньше боли в пальцах с ssh-agent. Надеюсь, эта информация о них послужат кому-то ещё.

Как Добавить Ссылку На Трекер В Robot Framework

2012-09-27T00:00:00+00:00

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

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

Сегодня я задался вопросом: а можно ли добавить в отчёты ещё и ссылку на сам тикет, чтобы можно было одним кликом перейти на соответствующую страницу в трекере?

Оказалось, это делается совсем несложно. Достаточно добавить один параметр к строке запуска pybot (или jybot), и ссылки на тикеты добавятся на страницу отчёта.

Для наглядности я сделал небольшой пример.

Создайте файл taglinks.txt с подобным содержанием:

*** Settings ***
Force Tags        issue-123

*** Test Cases ***
Pass
    [Tags]    issue-1234    not-an-issue
    No Operation

И запустите тест командой:

$ pybot \
    --tagstatlink issue-*:http://example.com/redmine/issues/%1:Issues \
    --tagstatlink *i*:http://ahitrin.github.com/:Blog \
    taglinks.txt

Результат не только радует глаз, но и делает отчёт намного удобнее:

Во-первых, к тегам действительно добавились ссылки. Ссылка “Issues” для тега issue-123 отправит пользователя на http://example.com/redmine/issues/123, а для тега issue-1234, соответственно, на http://example.com/redmine/issues/1234.

Во-вторых, видно, что можно создавать несколько ссылок на каждый тег. Главное здесь - придумать для своих тестов хороший способ именования тегов, чтобы не возникало случайных коллизий (а только запланированные). Лично мне пока хватит и просто ссылок на внутренний Redmine ;)

Вот и всё на сегодня. Желаю всем зелёных тестов, и побольше!

Включаем Подсветку Кода В Jekyll

2012-08-09T00:00:00+00:00

В каждой культурной среде существуют свои определённые традиции. Например, хаскеллисты традиционно пишут туториалы по использованию монад. А пользователи jekyll традиционно пишут пост “Как включить подсветку кода”. Внесу же и я свою скромную лепту в общий культурно-гумусный слой.

По-умолчанию, jekyll уже поддерживает pygments, однако всё равно требуется проделать ряд телодвижений, чтобы код действительно стал подсвечиваться. Вот последовательность, которая помогла мне.

Сначала ставим pygments (если их ещё нет). Например, через кошерный pip:

$ pip install pygments

Не забываем также обновить свои гемы - старый liquid может работать некорректно ;)

$ yum update

Проверяем, что конфиг _config.yml содержит указание использовать pygments:

pygments: true

Создаём css-файл, который отвечает за стиль подсветки:

$ pygmentize -S trac -f html > stylesheets/pygments.css

Мне понравился стиль trac, и вы тоже можете поиграть с расцветкой кода:

$ ls /usr/share/pyshared/pygments/styles
__init__.py
autumn.py
borland.py
bw.py
colorful.py
default.py
emacs.py
friendly.py
fruity.py
manni.py
monokai.py
murphy.py
native.py
pastie.py
perldoc.py
tango.py
trac.py
vim.py
vs.py

Добавляем ссылку на созданный нами файл в свой лэйаут. Я не стал мудрить, и тупо вписал одну строку в _includes/themes/twitter/default.html туда же, где указаны прочие стили:

<link href="/stylesheets/pygments.css" rel="stylesheet">

На всякий случай исправляем дефолтный стиль в файле bootstrap.min.css, если у вас используется тема Twitter Bootstrap. Так рекомендуют здесь.

-code{padding:3px 4px;color:#d14;background-color:#f7f7f9;border:1px solid #e1e1e8;}
+code{padding:3px 4px;color:#d14;border:1px solid #e1e1e8;}

После этого всё должно работать.

Пример

Для подсветки надо использовать liquid-теги. Пишем в markdown-исходник страницы что-нибудь вида:

{% highlight c linenos %}
int main() {
printf(“Hello\n”);
return 0;
}
{% endhighlight %}

И получаем симпатичный кусок кода:

1
2
3
4
int main() {
    printf("Hello\n");
    return 0;
}

Если нам не нужна нумерация строк, то убираем слово linenos.

Ссылки

Главная ссылка: How to get Pygments to work with Jekyll

Слияние Репозиториев В Git

2012-07-16T00:00:00+00:00

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

Я не нашёл в сети полного описания всех шагов (может быть, плохо искал), и поэтому решил набить памятку, скомпилированную из разных источников и собственных экспериментов.

Суть проблемы

Допустим, у нас есть два проекта, каждый из которых живёт в отдельном репозитории.

Назовём первый проект libfoo. Это архиполезная библиотека с долгой и знатной историей.

zloddey@zlosung:~/projects/libfoo$ git log --pretty=oneline
2e0560e5c43ec63096f975ea534c23d58274a341 Fix critical bug
f0d99354dd3140d826b7e77cfb4e72f251dcf81e Awesome Foo library

В ней много файлов, все из которых нам очень важны.

libfoo
∟ include
  ∟ foo.h
∟ src
  ∟ foo.c

Второй проект - это mainproject, убийца Facebook, Twitter и (внезапно) Wikipedia.

zloddey@zlosung:~/projects/mainproject$ git log --pretty=oneline
88ed3223758ea3171ba4fccaf0098c85db38d348 Kill'em all!

Он тоже очень большой

mainproject
∟ src
  ∟ main.c

И после трёх лет разработки мы поняли, что нам жизненно необходимо слить оба репозитория в один. А именно, переместить библиотеку в репозиторий проекта (в новую папку libfoo). Разумеется, при этом хочется сохранить всю историю изменений.

Disclaimer

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

Поэтому проводите все эксперименты на копиях рабочих репозиториев. Тем более, что клоны в git создаются очень быстро. А когда все манипуляции будут завершены, то репозитории можно синхронизировать через push/pull.

В общем, я считаю, что предупредил Вас. Берегите свои данные!

Переписываем путь к файлам

Первый шаг на пути к слиянию репозиториев ~~в сладостном экстазе~~ - это изменение пути к файлам в репозитории с библиотекой. Если сейчас файлы лежат в корне, то после наших манипуляций они должны переместиться в папку libfoo (которая будет расположена внутри репозитория libfoo).

Добиться этого нам поможет термоядерная команда git filter-branch. Она предназначена для активного редактирования истории в духе “1984”. История изменяется непосредственно через изменение (точнее, пересоздание) коммитов, поэтому все правки необратимы. Неудачное применение filter-branch может отправить Ваш репозиторий на свалку.

Поэтому внимательно следите за руками:

zloddey@zlosung:~/projects/libfoo$ git filter-branch --tree-filter 'mkdir libfoo; ls | grep -v libfoo | xargs -I{} mv {} libfoo' master
Rewrite 2e0560e5c43ec63096f975ea534c23d58274a341 (2/2)
Ref 'refs/heads/master' was rewritten

Флаг --tree-filter командует git-у, что следующая за ним команда должна быть применена к каждому коммиту в цепочке (в нашем случае ко всей ветке master). Фильтрация пройдёт успешно только в том случае, когда команда завершается со статусом 0, и все коммиты удаётся наложить.

Сама команда шелла тоже состоит из двух частей. Сначала мы создаём папку libfoo. Затем перемещаем в неё все файлы, за исключением самой libfoo. Типичный пример мощи шелла: с помощью пайпа ~~и чьей-то матери~~ составляем из базовых команд сложное действие, которое сделает за человека всю монотонную работу.

Если мы не ошиблись в наборе команды, то git перепишет все коммиты репозитория и явит нам новую, улучшенную библиотеку libfoo:

libfoo
∟ libfoo
  ∟ include
    ∟ foo.h
  ∟ src
    ∟ foo.c

При этом сохранится вся история изменений (хотя, разумеется, изменятся хэши коммитов):

zloddey@zlosung:~/projects/libfoo$ git log --pretty=o
a98d0b1b6196831bf85f24517ece58a74317827b Fix critical bug
0286c0c223c611c35b8df9049a33189ab2e3d72c Awesome Foo library

При желании можно скастовать git log на любой конкретный файл и убедиться, что с его историей тоже всё в порядке.

Теперь можно заняться и самим слиянием.

Объединяем репозитории

Осталось совсем немного. Переходим в наш уберпроект mainproject и вытягиваем все коммиты из изменённого репозитория библиотеки:

zloddey@zlosung:~/projects/mainproject$ git remote add libfoo-source ../libfoo/
zloddey@zlosung:~/projects/mainproject$ git fetch libfoo-source
warning: no common commits
remote: Counting objects: 11, done.
remote: Compressing objects: 100% (4/4), done.
remote: Total 11 (delta 0), reused 0 (delta 0)
Unpacking objects: 100% (11/11), done.
From ../libfoo
* [new branch]      master     -> libfoo-source/master

git будет удивлён, что удалённый репозиторий не имеет с нашим общих коммитов, и предупредит нас об этом. Не стоит беспокоиться - всё идёт по плану.

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

Можно пойти по Linus-way и слить две ветки через обычный merge. В таком случае создастся коммит, у которого будет два предка: один из libfoo, и один из mainproject:

zloddey@zlosung:~/projects/mainproject$ git branch
* master

zloddey@zlosung:~/projects/mainproject$ git merge libfoo-source/master
Merge made by the 'recursive' strategy.
libfoo/include/foo.h |    1 +
1 file changed, 1 insertion(+)
create mode 100644 libfoo/include/foo.h
    create mode 100644 libfoo/src/foo.c

zloddey@zlosung:~/projects/mainproject$ git log --graph --pretty=oneline
*   6c15d2bbaab1ee5751f345ac67a9a1b2400b8476 Merge remote-tracking branch 'libfoo-source/master'
|\
| * a98d0b1b6196831bf85f24517ece58a74317827b Fix critical bug
| * 0286c0c223c611c35b8df9049a33189ab2e3d72c Awesome Foo library
* 88ed3223758ea3171ba4fccaf0098c85db38d348 Kill'em all!

Есть и другой вариант. Например, мы на своём рабочем проекте запретили коммиты с несколькими родителями (ради простой линейной истории коммитов). В таком случае надо сливать ветки через rebase.

zloddey@zlosung:~/projects/mainproject$ git branch 
* master

zloddey@zlosung:~/projects/mainproject$ git checkout libfoo-source/master 
Note: checking out 'libfoo-source/master'.
    (всякая болтовня git)
HEAD is now at a98d0b1... Fix critical bug

zloddey@zlosung:~/projects/mainproject$ git checkout -b new-master
Switched to a new branch 'new-master'

zloddey@zlosung:~/projects/mainproject$ git rebase master 
First, rewinding head to replay your work on top of it...
Applying: Awesome Foo library
Applying: Fix critical bug

zloddey@zlosung:~/projects/mainproject$ git checkout master 
Switched to branch 'master'

zloddey@zlosung:~/projects/mainproject$ git merge new-master 
Updating 88ed322..3641759
Fast-forward
libfoo/include/foo.h |    1 +
 1 file changed, 1 insertion(+)
 create mode 100644 libfoo/include/foo.h
 create mode 100644 libfoo/src/foo.c

zloddey@zlosung:~/projects/mainproject$ git branch -d new-master 
Deleted branch new-master (was 3641759).

zloddey@zlosung:~/projects/mainproject$ git log --graph --pretty=o
* 36417598b9e390c15f9671e8940fc42392b5a4fa Fix critical bug
* d0934618c8316f5190ad57b6ebc67def61a0c096 Awesome Foo library
* 88ed3223758ea3171ba4fccaf0098c85db38d348 Kill'em all!

И в любом случае не забываем подчистить удалённый репозиторий - он нам больше не нужен!

zloddey@zlosung:~/projects/mainproject$ git remote rm libfoo-source

Что в итоге

Мы получили, что хотели: в репозитории mainproject появилась папка libfoo со всеми файлами из проекта libfoo (надеюсь, Вы действительно хотели именно этого!)

mainproject
∟ libfoo
  ∟ include
    ∟ foo.h
  ∟ src
    ∟ foo.c
∟ src
  ∟ main.c

При этом libfoo появился у нас не одним большим блобом, а в виде оригинальной последовательности коммитов. Так что, когда найдётся следующий баг в этой библиотеке, поиск через git blame укажет на реального автора косяка, а не на человека, который сливал репозитории (впрочем, если это одно и то же лицо, я умываю руки).

Мораль всей басни: переписывайте свою историю и упорядочивайте репозитории на здоровье, но только помните:

(Картинка отсюда)

Микрокоммиты В Git

2012-07-15T00:00:00+00:00

Я использую git в работе уже несколько лет, но в последние месяцы заметил, что у меня сменился способ работы с ним. Попробую изложить, как я использую git, и что с этого имею.

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

Большие коммиты

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

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

Программисты, использующие git недавно, также могут создавать коммиты в процессе работы “когда получается”. Такой вариант не сильно отличается от предыдущего. Может быть, даже хуже: в коммиты попадает промежуточный код, от которого потом отказались. На мой взгляд, это весьма вредно. Кто-то другой, копаясь в истории, может надолго смутиться, увидев неправильный код, а то даже и ошибочно принять его за образец для подражания.

Мелкие коммиты

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

Работа с кодом у меня проходит в две фазы. Образно говоря, их можно назвать “время разбрасывать камни” и “время собирать камни”. Порой они сменяют друг друга однократно, а порой чередуются много раз подряд. Обычно это зависит от объёма изменений.

Различие между фазами заключается в том, как мы обращаемся с коммитами.

Разбрасываем камни

Это простой, быстрый и весёлый этап. Мы просто создаём коммиты на каждый чих. Подчистили код? Сделали коммит. Провели рефакторинг? Сделали коммит. Добавили кусок функционала? Сделали коммит.

Критически важно, чтобы в каждом коммите содержалось одно понятное и цельное изменение. Это даёт нам несколько ключевых преимуществ:

Так проще описать изменения. Вместо мало что говорящего сообщения “Тикет 1234” мы можем написать нечто конкретное, а-ля “Класс Fooblinator диспетчеризует клиентов по типу доставки”. Это нам потом ещё очень пригодится.
Pазные цельные изменения меньше пересекаются друг с другом. Полного отсутствия пересечений, конечно, практически никогда не бывает, но к этому стоит стремиться :)
Mы можем активно экспериментировать в том же коде, просто сохраняя экспериментальные изменения в отдельные коммиты. Потом эти коммиты можно будет легко выкинуть.

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

Собираем камни

Если на первой фазе мы создавали много мелких коммитов, то теперь мы начинаем их объединять. Главная рабочая команда на этом этапе - git rebase -i. Также очень помогают git log, git cherry и незаменимый gitk ;)

Интерактивный ребэйз - самая приятная фича git, которую я открыл для себя в последнее время. Фактически, именно он подтолкнул меня к подобному изменению в workflow. Суть его довольно проста: после вызова команды список предназначенных для перебазирования коммитов открывается в текстовом редакторе (мой любимый vim!), где можно указать, как поступить с каждым коммитом. Можно также менять порядок коммитов, выбрасывать их (просто удалив из списка), и даже приказывать запустить между коммитами произвольные команды шелла! И после выхода из редактора git постарается выполнить все указанные действия.

Так как я веду разработку в отдельной ветке, то в 95% случаев формат команды выглядит одинаково:

git rebase -i master

Чаще всего я использую следующие приёмы:

Eсли коммит содержит какой-то экспериментальный код, который не должен попасть в итоговый результат, то он просто выбрасывается.
Если коммит содержит мелкое исправление к предыдущему коммиту, то их можно слить с помощью команды fix.
Если коммит содержит существенное исправление к предыдущему коммиту, то их можно слить с помощью команды squash. Это даст возможность отредактировать сообщение итогового коммита, включив в него информацию из обоих исходных коммитов. Каждый исходный коммит может содержать немного комментариев, но при слиянии мы соединяем их, и так постепенно вырастает большое и подробное описание коммита.
Чaсто коммиты требуется отсортировать, прежде чем сливать друг с другом. Для этого достаточно лишь поменять их порядок при редактировании ребэйза. Чем меньше и цельнее наши коммиты, тем легче осуществлять этот шаг.
Однако, порой становится понятно, что какой-то конкретный коммит содержит слишком много изменений. В таком случае его можно разбить на части с помощью команды edit. Ребэйз остановится на этом коммите, и мы можем удалить последний коммит и отредактировать изменения. После чего продолжить ребэйз с помощью git rebase --continue.
Наличие команды run для запуска произвольных команд шелла, безусловно, радует. Но мне пока она ни разу не требовалась.

Если наши команды слишком безумны, и коммиты не могут быть наложены в указанном порядке, то на помощь всегда готов прийти git rebase --abort. Мой собственный опыт подобных неудач подсказывает ещё один дельный совет по применению ребэйза: не стоит увлекаться и сразу перетасовывать все коммиты с ног на голову. Если что-то пойдёт не так, то есть риск, что придётся надолго застрять в исправлении конфликтов в коде. Куда проще и быстрее выполнить ребэйз несколько раз подряд, каждый раз применяя только одно изменение в структуре коммитов.

Профит!

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

Никогда раньше у меня не было настолько подробных и чётких commit message’ей, которые писались бы так легко! Вся хитрость заключается в том, что я пишу их по кусочкам, а затем сливаю эти кусочки друг с другом. Каждый небольшой и цельный коммит описать намного проще, чем всё изменение в целом. И объединить два предложения в абзац тоже проще, чем написать их с ноля.

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

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

Ещё бывает сложно управляться с коммитами, когда их становится слишком много. Учитывая ограниченность человеческого мозга, фаза “слишком много” может наступать уже на 15-20 мелких коммитах. О чём это обычно говорит? О том, что пришло время собирать камни.

Интересно, есть ли аналог интерактивного ребэйза у mercurial и других соперников git? За 3-4 месяца применения этой команды я понял, что это просто мега-убойная вещь.

Лучи Ненависти Putty

2012-06-28T00:00:00+00:00

Вчера убил битый час на удалённую помощь коллеге, который не мог подключиться к нашему git-серверу. Бедняга работает под Windows и имел неосторожность поставить себе на машину PuTTY. Как результат, он всё никак не мог запушить к нам свою ветку.

Сначала мы думали, что проблема в создаваемых PuTTY ключах. Известный факт: его формат ключей несовместим с OpenSSH. Поэтому мы рекомендуем сотрудникам создавать ключи только через ssh-keygen. Однако здесь проблема оказалась хитрее. Не работал даже “правильный” ключ, созданный по всем правилам.

Выяснилось, что PuTTY, помимо прочего, подменяет переменные окружения, которые использует git. И делает большие удивлённые глаза, когда к нему приходит rsa-шный ключ: “я знать не знаю ваш хост, и не буду с ним соединяться”. Вот и весь сказ.

В нашем случае помог простой unset GIT_SSH в гитовой консоли. Лучшим же решением проблемы будет удаление с компьютера сначала PuTTY, а затем и Windows. Эта операционка, по моему стойкому убеждению, крайне слабо подходит для разработки софта. В отличие от нашего любимого GNU/Linux.

N.B.: А ещё надо будет найти время, чтобы выпилить PuTTY из дудки. Так жизнь станет ещё чуточку приятнее.

Let's Start

2012-06-10T00:00:00+00:00

Статическая генерация сайтов

По-моему, это просто прекрасно!

Mожно создать и оттестировать запись локально, и только потом выпустить во внешний мир
Cам полностью контролируешь стиль страниц
Markdown - наше всё!
Git - наше всё в ещё большей степени

А вот проблемы с буллетами, после которых идёт не-английский текст - это печально :(