costa works: ANNOUNCEMENTS

2022-03-06

Trying to help refugees

This applies to any refugees, please share.

FREE online  advanced software engineering mentorship and tutoring  FOR REFUGEES

While your friends and family heroically fight the crisis at home, prepare yourself to re-build life afterwards, do not migrate permanently!

If your Computer Science studies or your Information Technology job is cut short by the crisis, use this time to get stronger professionally and have better chances at remote work:

only basic programming skills required – I will try to define and accommodate your goals
only basic (read-write) English required – I also speak Russian and understand Ukrainian
only basic (e.g. dated) laptop or desktop required – I will provide cloud computing resources
no obligations of any sort expected – I will help you getting where you want to be
no new dependencies introduced, technological or otherwise – I will work with what you have

2021-10-05

Looking for independent frontend legend

I’m looking for an absolutely top-notch web client-side specialist; any mobile platform expertise is very welcome as well.

A candidate must be independent in the legal business sense, as well as impressive and ambitious technologically.

The place of a candidate’s residence is of no significance since the major communication exchange will consist of project code/doc commits with daily to weekly latency.

The first job (of several) that I have for a candidate (~7.5h/week) is actually to find and to engage some decent frontend outsourcers by helping approach and supervise the latter, while they try and perform a test task as follows.

“divplane” - ACME frontend test task (its complete definition)

A major web page component (acting main element when in use) is required: “Unlimited (zooming) view/edit of unlimited element structure”. The goal is to attain smooth zooming and scrolling as well as simple content editing on a “seemingly” infinitely detailed page surface with the details (nested divs) loaded and stored via an API on the fly.

Data service API

(for reference, the actual service is implemented separately)

GET <API-URI>/divs/<UUID>[?dep=64] (application/xhtml+xml) responds with a “prerendered” HTML fragment with <div id="UUID"... as the root element. For instance, GET https://example.com/divs/...1a?dep=2 yields:

headers:
- X-CONTAINER-DIV-UUID: ...05 – the UUID of depth container (parent) div
- X-ABSOLUTE-W-H-RATIO: 0.5 – the absolute (from root) width/height ratio

body:

<div id="...1a" style="position: absolute; left: 5%; top: 55%; width: 15%; height: 15%;">
  <div id="...1b" style="position: absolute; left: 30%; top: 45%; width: 50%; height: 30%;">
    <div id="...1e" style="position: absolute; left: 15%; top: 25%; width: 70%; height: 50%; background-image: url(data:image/png;base64,...)">
    </div>
  </div>
  <div id="...1c" style="position: absolute; left: 15%; top: 10%; width: 60%; height: 20%;">
    <div style="position: relative; width: 100%; height: 100%;">
      <p>Some text!</p>
    </div>
  </div>
</div>

explanation:
- the component will be aware of its viewport dimensions
  - for the purpose of description, it takes the whole screen, but it is not exclusive on the web page in any way
    - that being said, it’ll probably still be the main component on a page, or at least, a major one, becoming the main when focused, so, anchoring (or other types of URL navigation) are appropriate (e.g. ...#<UUID>)
  - when receiving X-ABSOLUTE-W-H-RATIO from the service, it must have all it needs for geometry computations
- the component will be given a data service API URI, and a UUID of the div to be shown initially (see above)
  - when receiving X-CONTAINER-DIV-UUID from the service, it must be able to zoom out to that containing div: depth (dep [default: 64] refers to param value), or root, if closer to root than dep, and, of course, when responding to a request with a root UUID, no such header will be returned
- the component will insert returned (prerendered) fragments into DOM as is, yet for further DOM manipulation and data service requests while zooming and scrolling, it must be aware of the 3 kinds of relevant structure elements (identifiable divs), all having id="<UUID>" attribute, all absolutely positioned with style="position: absolute; left: R%; top: R%; width: R%; height: R%;" attribute:
  - container:
    - a root will be exceptional with no left/top position, and width/height used just for the ratio
    - will contain just the non-overlapping structure (identifiable) divs
  - content:
    - will have a single “frame” div having style="position: relative; width: 100%; height: 100%" attribute, with any – hopefully reasonable – content inside
  - thumbnail:
    - just like a container, but instead of its contents, it’ll have a low-res render thereof, as an inline background-image styling.
- and if this is the starting view (first request), for instance, landing on https://example.com/whizz#...1a should look something like this:
  
  containing element is constructed appropriately (using screen dimensions)
```
              +----------------screen----------------+
              |//////////////////////////////////////|
              |//+------------div ...1a-----------+//|
              |//|                                |//|
              |//|  +-----div ...1c-----+         |//|
              |//|  |                   |         |//|
              |//|  |  Some text!       |         |//|
              |//|  |                   |         |//|
              |//|  |                   |         |//|
              |//|  |                   |         |//|
              |//|  +-------------------+         |//|
              |//|                                |//|
              |//|                                |//|
              |//|                                |//|
              |//|          +----div ...1b---+    |//|
              |//|          |                |    |//|
              |//|          |                |    |//|
              |//|          | +-div ...1e-+  |    |//|
              |//|          | |<pixelated |  |    |//|
              |//|          | | render of |  |    |//|
              |//|          | | contents> |  |    |//|
              |//|          | +-----------+  |    |//|
              |//|          |                |    |//|
              |//|          +----------------+    |//|
              |//|                                |//|
              |//|                                |//|
              |//|                                |//|
              |//|                                |//|
              |//|                                |//|
              |//+--------------------------------+//|
              |//////////////////////////////////////|
              +----------------screen----------------+
```

POST/PUT/PATCH <API-URI>/divs/<UUID> (application/xhtml+xml) modifies the request div (which must be a container div identified by <UUID>) using the “edited” HTML fragment sent as a body. The root of the fragment should be an identifiable div, and for each such div within the fragment:

no overlapping sibling identifiable divs or overflowing children are allowed
it must be either container or content div as seen above
if it’s new, it should have a new UUID (id attribute)
if it’s “old” (existing div UUID), it must be a direct child of the request div, it will be moved within div hierarchy as appropriate
for a content or a new container div, it should have all its contents within
old container divs can only change their area (attributes) within the request div, and thus, permitted as thumbnails (with no content) only
otherwise, it’s invalid

For instance, POST https://example.com/divs/...1a with

  <div id="...1d" style="position: absolute; left: 10%; top: 5%; width: 80%; height: 35%;">
    <div id="...1c" style="position: absolute; left: 45%; top: 60%; width: 40%; height: 30%;"></div>
    <div id="...1f" style="position: absolute; left: 10%; top: 10%; width: 60%; height: 20%">
      <div style="position: relative; width: 100%; height: 100%;">
        <p>More text?</p>
      </div>
      </div>
    </div>
  </div>

may occur with the initial state like above and aggregating a few edits, such as:

a change in size and location of the content div ...1c - should be a matter of showing borders and dragging corners, or something
enclosing div ...1c within a new container div ...1d, covering the former’s area - adding new divs (by a sort of dragging corners), so they cover some divs completely
adding another new div ...1f within div ...1d - adding new divs (by a sort of dragging corners), so they are covered by some divs completely
adding content to div ...1f with ‘More text?’ in it - content divs will be edited with a pluggable “rich text” editor

and the resulting picture will look something like this:

  containing element is constructed appropriately (using screen dimensions)

                  +----------------screen----------------+
                  |//////////////////////////////////////|
                  |//+------------div ...1a-----------+//|
                  |//| +----------div ...1d---------+ |//|
                  |//| |  +--div ...1f---+          | |//|
                  |//| |  |  More text?  |          | |//|
                  |//| |  +--------------+          | |//|
                  |//| |                            | |//|
                  |//| |            +--div ...1c--+ | |//|
                  |//| |            |  Some text! | | |//|
                  |//| |            |             | | |//|
                  |//| |            +-------------+ | |//|
                  |//| +----------------------------+ |//|
                  |//|                                |//|
                  |//|          +----div ...1b---+    |//|
                  |//|          |                |    |//|
                  |//|          |                |    |//|
                  |//|          | +-div ...1e-+  |    |//|
                  |//|          | |<pixelated |  |    |//|
                  |//|          | | render of |  |    |//|
                  |//|          | | contents> |  |    |//|
                  |//|          | +-----------+  |    |//|
                  |//|          |                |    |//|
                  |//|          +----------------+    |//|
                  |//|                                |//|
                  |//|                                |//|
                  |//|                                |//|
                  |//|                                |//|
                  |//|                                |//|
                  |//+--------------------------------+//|
                  |//////////////////////////////////////|
                  +----------------screen----------------+

DELETE <API-URI>/divs/<UUID> removes the request div (identified by <UUID>):

if the request div is a content div, its contents are removed as well

if it is a non-empty and non-root container div, its contents are moved to its direct container, while area attributes corrected so their areas within that container will stay the same For instance, DELETE https://example.com/divs/...1d with the initial state like above will correspond to a picture that looks something like this:

containing element is constructed appropriately (using screen dimensions)

                +----------------screen----------------+
                |//////////////////////////////////////|
                |//+------------div ...1a-----------+//|
                |//|                                |//|
                |//|    +--div ...1f---+            |//|
                |//|    |  More text?  |            |//|
                |//|    +--------------+            |//|
                |//|                                |//|
                |//|              +--div ...1c--+   |//|
                |//|              |  Some text! |   |//|
                |//|              |             |   |//|
                |//|              +-------------+   |//|
                |//|                                |//|
                |//|                                |//|
                |//|          +----div ...1b---+    |//|
                |//|          |                |    |//|
                |//|          |                |    |//|
                |//|          | +-div ...1e-+  |    |//|
                |//|          | |<pixelated |  |    |//|
                |//|          | | render of |  |    |//|
                |//|          | | contents> |  |    |//|
                |//|          | +-----------+  |    |//|
                |//|          |                |    |//|
                |//|          +----------------+    |//|
                |//|                                |//|
                |//|                                |//|
                |//|                                |//|
                |//|                                |//|
                |//|                                |//|
                |//+--------------------------------+//|
                |//////////////////////////////////////|
                +----------------screen----------------+

Major user interactions

start up
- show the div contents via inserting them in DOM, after requesting them from the API with the given UUID
zoom in/out
- manipulate DOM in an appropriate way, while requesting the API as needed
- stop zooming in when no identifiable divs are completely visible
- stop zooming out when the root div is completely visible
scroll x/y
- manipulate DOM in an appropriate way, while requesting the API as needed
- zoom out to keep at least one identifiable div completely visible
- stop when zooming out stops
create id-div
- whenever it is visually comfortable, provide tools to “draw” enclosing or empty divs, requesting the API as appropriate
- an empty div is a draft div, should not be more than one at a time, and requesting the data service to add such a div is optional
- an empty div must have an option to add content to it – with a pluggable “rich text” editor – or to add another empty div within its area
  - a “russian doll” of empty divs will be as disposable as a single one
mutate id-div
- change location or dimensions, while requesting the API as appropriate
- change contents of a content div – with the same rich text editor, while requesting the API as appropriate
- remove container div – moving its contents to its parent, preserving geometry, while requesting the API as appropriate

Work estimation

I have some weak preferences with frontend technologies, but the only things important here are GUI look & feel, and component engineering quality.

My preliminary effort estimation is 80 software engineer hours.

Frontend outsourcers test process

I am looking for the whole process: producing the “divplane” component and having chosen the right outsourcing provider – to take up to 5 months and to cost less than 2.5 × work estimation budget.

costa works announcing...