implement: don't allow to instanciate them :-) Just check if the
of the instance we are creating is the own class instead of one of its
childrens, and don't throw an error if it is:
Google used to provide
prebuild Android images of
libWebRTC library, and in fact, it's (still) the recomended way to use them on
its own documentation.
But starting on WebRTC M80 release (January 2020), they decided to
deprecate the binary mobile libraries,
and the reasons were that the builds were intended just only for development
users were already using building themselves with their own customizations, or using third party libraries that embeded them
(where have been left developers that just want to build a WebRTC enabled mobile
app?), and they just only provided another build in August 2020 (1.0.32006) to
fill some important security holes, in case someone (everybody?) was still using
the binary mobile libraries.
When it comes to WebRTC architectures, there is no silver bullet. Depending on each use case, the optimal architecture may vary from project to another. For this reason, I am going to explain the main network architectures that are usually applied in projects based on WebRTC (and mainly applied to the streaming video), and what are the pros and cons of each one of them.
Respecto a arquitecturas WebRTC, no hay una bala de plata. Dependendiendo de cual sea el caso de uso, la arquitectura óptima puede variar de un proyecto a otro. Por este motivo, voy a explicar las principales arquitecturas de red que suelen aplicarse en proyectos basados en WebRTC (y principalmente aplicadas al streaming de video), y cuales son los pros y contras de cada uno de ellos.
I recently got to work on a project where I need to capture a camera, sendback some drawed feedback, exchange commands and chat messages (and voice comments), and record everything. I've always been interested on using non-mainstream features of the Web Platform, and after taking a look of the current state of the art, I've found a way to implement this particular use case using ONLY open and readily available web standards.
I've always loved terminals and retro-computing. I find they were a technology that didn't got fully their full potential due to graphical interfaces (it's strange I say this since my first computer was a Macintosh LC II at a time where everybody else had at most a PC with Windows 3.11...). That's the main reason I added support for Unicode BPM plain in Linux kernel for NodeOS, specially to have available the Braille patters used by blessed-contrib to draw graphical diagrams in the terminal. That's the reason why when I discovered BOOTSTRA.386 project, a Bootstrap theme that mimics a text-mode interface in a website similar to old BBSs (fathers of web forums, and grandfathers of current online walls), I got enthusiastic about the idea of making it compatible with real terminal web browsers like Links, w3m or Lynx.
I've been working lately a bit more on the freelancer calculator, and was able to identify and fix some of its errors.
At the same time I work as employee, sometimes I get offers for freelance projects. It's difficult to find a balanced rate between both schemes, so using Google Spreadsheet I've done a calculator to adjust them. The calculator is focused for Spain taxes (one of the reasons texts are in spanish), but should be easy to addapt to other normatives.
projectlint is a projects-wide linter and
style checker I've been working on during the last weeks. As part of its set of
rules, one of them
ensures that the current version of the operating system where the code is
running is maintained and updated. But, is there a npm package with info about
the operating systems lifecycles? Nope... enter
When designing web services, it's normal to include an option to delete an user's account. Since this is an important action (the user and its data will dissapear from the platform), usually this is done by asking him to confirm the operation, with several endpoints one for each operation step. Navigating between different pages is so 2010-style, and there's no direct mapping at this point between REST APIs and CRUD operations, that I've been thinking in a REST compatible alternative: use a token.
Experimenting with redux-offline,
I've done a Proof-of-Concept about how to use
redux-offline in a Node.js environment,
like a CLI command. This is useful for example when it's needed to do an offline
aware application that needs to queue some operations until it's connected again.
Since I was a child I never liked to write. I was more a thinker, a tinker and a doer, and found really tedious to start writing ideas that I could already do, explain or show. In fact, I hated the idea of receiving a diary as a present for making my first Communion (somewhat typical here at Spain, and luckily didn't happen to me) because I found boring to write about things that already have happened while I would be creating new ones. The same reason why I'm not too much into blogs (both writing and reading) because I pay too much attention to what I say and how I do it, and get to be really slow to get fully polished my final text (I mostly did my bachelor thesis code in 6 months... and later spended other 14 months more just for writting the project memory. It's ironic that the times I got to write something, people got surprised that I have a somewhat good style... and more ironic that having written so much (open) source code, probably in lines number I could be able to make both Dan Brown and J.K. Rowling to fall on their knees :-P Unluckily, they have got more revenues for their jobs than me, good for them :-)