Category: facebook

Does anyone understand lenses for glasses? Can you really distinguish by a blind test on the nose between optics from Essilor, Hoya, Carl Zeiss, Rodenstock, Seiko?

Recommended by kids

Very

I’m at Vyatskiy Dvoryk in Moscow

How to set up almost free corporate email for an unlimited number of employees?

My opinion:

1. Register a gmail box for each employee in the format fio.companyname@gmail.com

2. Set up a mail server in the company using an inexpensive virtual machine. SMTP, MX records. This requires an admin, and it shouldn’t cost more than a few tens of dollars a month.

For each box fio@companyname.ru, set up an unconditional forwarding (redirect) to fio.companyname@gmail.com

3. In the gmail settings, configure the from/reply-to address as fio@companyname.ru. Google will require confirmation via a link from an email.

As a result, all the hassle of maintaining storage servers on Google is free. The mail is sent from the corporate address. I wonder if this scheme works with Yandex and Mail.ru?

P.S. Just to clarify, it’s not like this with us.

Interestingly, Gillette has almost a monopoly in our market – its nearest competitor, Schick, barely holds any market share in Russia (1.5% compared to 60%). I don’t consider BIC with its non-disposable razors a competitor to Gillette, and there’s hardly anyone else.

I wonder why that is? Especially since Gillette’s consumables are quite expensive, buyers of razors could easily try something else for 20% less. Aren’t there any quality Chinese or European brands that could be promoted in Russia?

[:)] “…In the Russian language, at an unknown time and under unknown circumstances, the meanings of the words for icicle and lollipop were swapped. It should be lollipops hanging from the roofs, and children should be sucking on icicles!…” [LOL]

Masha on a ripstick, and I’m catching a shot on a longboard, just now in Gorky Park

On the longboard (@ Gorky Park in Moscow)

Another observation from years of working on software projects, particularly e-commerce.

The biggest risk to a project is the dragging of deadlines. As a consequence – the budget. It doesn’t matter whose initiative it is – the client’s or the developer’s. If the deadlines are slipping – the risk increases every day that the project will never be completed at all, the money won’t be received, the client will remain unsatisfied, etc. After a certain point, both sides lose interest.

Business is such that if, say, you haven’t launched a new product (website, store, or something else) in four months, the volume of changes over that time accumulates to the point where you might as well throw everything out and start over. Of course, nobody goes for this, and the system gets patched up.

Moreover – the longer the project, the more likely it is that the client will change their mind, that key people on the client’s side will change, that the market situation will change, and in our country, anything can happen. Therefore, everything must be done quickly.

The second problem is that when a project is stalled (no matter the reason – the client is slow in providing data or the developer is falling behind), the costs of labor continue to eat into the project budget. If the development company, in an effort to economize, reduces the resources allocated to the project (by switching someone to another project), it leads to a loss of interest and motivation in the team to finish everything on time and to do it well.

But how to fit a large project into a small timeframe? Here many make a big mistake – they create an excessively large team. Pushing resources should only be done to pull a project out of a mire, but not in its normal planning. A large team increases the number of communications within the project, which in turn increases the volume of documentation and the contradictions and ambiguities that permeate this documentation.

Therefore, we try to make everything very compact and try not to inflate the team without a very great need. Unfortunately, to achieve this goal, it is sometimes necessary to mix some roles that should be separate in the team for large projects. But if you separate them, then the problem of increasing the number of communications arises, and as a result, the increase in timelines and budget. And the growth of timelines – see point 1.

Therefore, for e-commerce projects, I believe in compact teams, dedicated 100%, consisting only of versatile professionals capable of making revolutionary changes in a short time, launching, and then it can be transferred to calm support.

By the way, we are looking for a developer (Java/Spring), QA, business analyst, and systems engineer. Recommend them, we have a good team.