Vacancy search and new privacy settings

Hi, everyone!

ResumUP is about career decisions, better career decisions.
We’re here to give you different tools to analyze yourself, to discover possible future,
to look for useful contacts.

First

Оf course to give you an information about real life job offers. So now, we’re featuring job offers on our service. There are two types – visual vacancies are directly published by registered recruiters; and text or links provided by our partners.

vacancy

Second

We’ve also updated our Privacy Settings and if you do not want your profile to be visible by recruiters, or some part of it, just go and set it.

privacy

More changes to come soon, so stay tuned. And as always we really appreciate your feedback.

Visually yours, ResumUP team.

Improved Career Planning

Hey everyone!

Our team recently rolled out a few sweet changes that we’d like to share with you.

First

We improved Career Planning section to make it easier for you to set a goal and discover possible steps on the way there. Also now it’s clear what skills you need to have and how you’re improving at each step. So now you can use both your Visual Profile and Career Plan to show your previous experience and future aspirations. Don’t forget to set up your privacy settings to make your career plan visible to others.

cp_1

Second

Now you can see who might be helpful to reach your goal. Just browse “Connections” to find people at each step, see how they got there and ask them for an advice.

cp_2

More changes to come soon, so stay tuned. And as always we really appreciate your feedback.

New ResumUP. Know what it takes.

We’ve been working hard to build really valuable service for you. A service that shows you WHO and WHAT you need to know to achieve your career goals. ResumUP generates a step by step career path based on your professional aspirations, network and experience. And we analyze more than 7 million profiles to give you most relevant results.

new_resumup

So, ResumUP is about knowing what it takes to achieve your career goal. Meanwhile check out our short video about new ResumUP:

 

Beautiful web experience

Hey everyone,

Over the past few weeks we’ve thought about improvements to make your experience simpler and more beautiful with us. After automatic upload and visualization you want to add or edit some info, right? Now it’s way faster and easier to do it. All in one page. At a glance.

Thank you for being with us. We would really appreciate you feedback about this update. Just e-mail us feedback@resumup.com or use this feedback form.

Rapid SVG: From Browser to NodeJS

dThis is a short story of suffering, pain, success and failures in an attempt to speed up RaphaelJS on big and complex SVGs.

Prehistory

In ResumUP we create a lot of colorful and meaningful resumes and vacancies

rapid_1

It all started with using RaphaelJS since it was the only library that enabled a fast implementation of designers’ hard work. When the first version of SVG resume was ready we faced, of course, a performance issue. The process of drawing resumes on the client side took upwards of 5-10 seconds in modern browsers — not to mention old browsers and computers, where it could take up to 30 seconds. Obviously, this was inadequate for both our needs and those of our customers.

Part 1. Tango and Cache.

So, what do we have?

  • A lot of js code that draws SVGs
  • Execution time of up to 30 seconds (5-7 seconds on average)
  • Little time but a great deal of desire to tune-up this stuff a bit

Firstly, we needed to determine where the bottleneck of Raphael was occurring and soon realized that it was closely connected to DOM. Thus, every time we call some Raphael method it creates a new DOM node. This may seem OK, but working with DOM objects directly requires a lot of overhead, so it is always faster to just insert SVG as plain XML in what is called inline SVG. Unfortunately, this feature is only supported by modern browsers and I suspect the library’s author used the DOM way for the sake of compatibility. Imagine that you have a few thousand nodes in one SVG while at the same time the complicated logic of drawing resume elements. Clearly, it’s not a cool solution.

When we came to an understanding of the issue and realized that we couldn’t fix Raphael quickly, we decided to use the server side cache instead of speeding up js code.

That’s what we came up with:

  1. Users visit the resume.
  2. Each of 10 resume blocks is rendered on the client side and then sent to the server.
  3. The next time someone visits the resume, we just load data from the db and insert it as an inline SVG.
  4. If some blocks are missing, we fallback to Raphael, rendering them again

Well, it worked and reduced the required drawing time to only one second, which was amazingly fast for us after the previous requirement of 5-7 seconds. The only problem left was what to do about old browsers which do not support inline SVG. They still have to render a resume every time.

Part 2. SVG on server side and tears.

Again, we have:

  1. A lot of js responsible for drawing.
  2. Execution time of 1 to 30 seconds (funny, yeah).
  3. Some time and the necessity of drawing SVG on the server side.

As perfectionists by nature, we weren’t satisfied by these results and started looking for a more elegant solution. In addition, some ideas we came up with required an API for drawing images. We needed server side functionality. The one thing we knew for certain was that we didn’t want to rewrite the thousands (and I mean it) of lines of code responsible for rendering resumes in some other language (we have ruby on the back end).

In the beginning, we tried to solve this problem by straight running existing js code with rubyracer, a wrapper around V8, which can interpret js code inside ruby. But as we said, Raphael is tightly connected with DOM and there is no DOM in V8. Fail. After googling around a bit we found jsdom, a library that imitates a browser inside a V8 environment. Cut to a few hours later and we had managed to run everything we needed. But happiness didn’t last long, because the program failed on the tenth resume with a “could not allocate memory” message. After some investigation we found out that the process of rendering each resume took approximately 8 seconds and 50-70 MB were leaking with each iteration. Nevertheless, it was a success since we proved the concept.

We started fine tuning this scheme and, at first, replaced the rubyracer with NodeJS with no wrappers. We wrote simple HTTP client with ExpressJS and loaded all our code alongside it with jsdom here. Using this method, we got four seconds for each resume with 50-60 MB of leakage. Still, it wasn’t good enough, so to improve performance we obviously needed to get rid of jsdom, which was leaking. This, however, required a whole new approach.

Part 3. Baileys and Absinthe. First hope

After all these experiments we decided that we should not stop halfway. The new idea was simple: we wanted to split the process of drawing in two separate parts:

  1. Building an abstract model, which described a future picture.
  2. Mapping this model to SVG.

This approach helped us to resolve some issues:

  1. No more jsdom on the server.
  2. Take advantage of inline SVG in modern browsers with a fallback to working with DOM for client.
  3. Since we had an abstract model we could map it to different formats, for example VML for IE8 support.

To achieve this goal, we started with the idea of modifying Raphael. We wanted to divide it into two parts and extract the one which didn’t depend on DOM. However, a few hours spent in RaphaelJS 2.0 source code made us realize that it wouldn’t work or would take too much time. And the deadline was approaching.

Thinking quickly, we decided to write a copycat of Raphael with all the same methods we used in our legacy code, so it looked the same, but worked in the way we needed. Thus, we could use Raphael on the client side and this copycat on the server. We called it “Baileys”.

rapid_2

Scenario

The User sends request to rails, rails call nodejs, nodejs processes data, renders it to json representing svg and sends it to rails, rails renders json to svg. We called the ruby part “Absinthe”.

This scheme appeared to be a success: rendering for 0.5 seconds with no leaks, but many questions.

Part 3. The Prototype.

We had a working solution, but it was far from production quality as we had some requirements:

  1. One code everywhere. We had to create one more entity to use it on server and on client sides.
  2. Less ruby is better. We wanted to port absinthe to js.

The final scheme looks like this:

  1. Tetris and — all code responsible for drawing svg without any dependencies on the library that creates svg.
  2. Baileys — a copycat of Raphael that creates an abstract model instead of DOM elements. In addition, we optimized such things as transformations and getBBox function.
  3. Absinthe — ported to js, works in tandem with Baileys and maps it to SVG.
  4. Polyomino — lightweight expressjs server that serves requests.

We are now able to use Tetris as an npm packet on the server and as asset pipeline gem on the client.

rapid_3

The current situation is 70 ms for each resume on average, which is super fast comparing with initial results.

Our next step is to port our current code to using baileys+absinthe scheme and stop using raphael. For those browsers, which do not support inline SVG we will insert it as img tag with src pointing to an actual svg image on s3. In case nodejs server is down, we can fallback to client side drawing as well.