phone

    • chevron_right

      Erlang Solutions: Call for Speakers at the RabbitMQ Summit

      news.movim.eu / PlanetJabber • 8 June, 2023 • 1 minute

    Are you a user, operator, developer, engineer, or simply someone with interesting user stories to tell about RabbitMQ? If so, we have some exciting news for you! The RabbitMQ Summit 2023 is just around the corner, and we are thrilled to invite you to submit your talks for this highly anticipated event.

    The RabbitMQ Summit brings together a vibrant, diverse community of enthusiasts from all corners of the world. It’s a unique opportunity to connect, learn, and exchange ideas with fellow RabbitMQ users, experts, and developers.

    This year, we have curated two exciting themes that encompass the breadth and depth of RabbitMQ usage and its impact across industries. We invite you to consider these themes when submitting your proposals:

    1. Features Theme-  in-depth tech explanation of RabbitMQ features, e.g.: How to use RabbitMQ in an economical fashion explained by developers, a roadmap of how to use streams.

    2. Industry Theme-  how RabbitMQ is used in the industry, e.g.: In an IoT space, troubleshooting, etc.

    Think creatively and propose talks that bring unique perspectives, cutting-edge techniques, and actionable insights to the table. Don’t hesitate to submit your ideas – every story counts.

    Event date and location

    20 Oct 2023 at the Estrel Hotel- Berlin, Germany

    Submission deadlines

    All talks should be submitted by 23:59 BST on 11 June 2023 . You will be informed about your submission status by 31 July 2023 .

    You can submit your talks here .

    Ticket Details

    There is no event fee for speakers. For just attendees, The public Early Bird tickets will be available on 15th June 2023. You can sign up for the waiting list here

    For more information

    You can visit the RabbitMQ Summit website for more details and follow our Twitter account for the latest updates.

    The post Call for Speakers at the RabbitMQ Summit appeared first on Erlang Solutions .

    • wifi_tethering open_in_new

      This post is public

      www.erlang-solutions.com /blog/call-for-speakers-at-the-rabbitmq-summit/

    • chevron_right

      Erlang Solutions: How ChatGPT improved my Elixir code. Some hacks are included.

      news.movim.eu / PlanetJabber • 1 June, 2023 • 3 minutes

    I have been working as an Elixir developer for quite some time and recently came across the ChatGPT model. I want to share some of my experience interacting with it.

    During my leisure hours, I am developing an open-source Elixir initiative, Crawly , that facilitates the extraction of structured data from the internet.

    Here I want to demonstrate how ChatBot helped me to improve the code. Let me show you some prompts I have made and some outputs I’ve got back.

    Writing documentation for the function

    I like documentation! It’s so nice when the code you’re working with is documented! What I don’t like — is writing it. It’s hard, and it’s even harder to keep it updated.

    So let’s consider the following example from our codebase:

    My prompt:

    Reasonably good for my taste. Here how it looks like after a few clarifications:

    Improving my functions

    Let’s look at other examples of the code I have created! Here is an example of code I am not super proud of. Please don’t throw stones at me; I know I should not create atoms dynamically. Well, you know how it can be- you want to have something, but you don’t have enough time with idea to improve things later and that later never happens. I think every human developer knows that story.

    Suggesting tests for the code

    Writing tests is a must-have in the modern world. TDD makes software development better. As a human, I like to have tests. However, I find it challenging to write them. Can we use the machine to do that? Let’s see!

    Regarding tests, the response code needs to be more accurate. It might be possible to improve results by feeding chatBot with Elixir test examples, but these tests are good as hints.

    Creating Swagger documentation from JSON Schema

    I like using JSON schema for validating HTTP requests. The question is — is that possible to convert a given JSON schema into a Swagger description so we don’t have to do double work?

    Let’s see. Fortunately, I have a bit of JSON schema-type data in Crawly. Let’s see if we can convert it into Swagger.

    Well, it turns out it’s not a full Swagger format; which is a bit of a shame. Can we improve it a bit so it can be used immediately? Yes, let’s prompt engineer it a bit:

    Now I can preview the result in the real Swagger editor, and I think I like it:

    Conclusion

    What can I say? ChatGPT is a perfect assistant that makes development way less boring for regular people.

    Using ChatGPT when programming with Elixir can bring several advantages. One of the most significant advantages is that it can provide quick and accurate responses to various programming queries, including syntax and documentation. This can help programmers save time and improve their productivity.

    Additionally, ChatGPT can offer personalised and adaptive learning experiences based on individual programmers’ skill levels and preferences. This can help programmers learn Elixir more efficiently and effectively.

    The use of AI and NLP in programming is likely to become more widespread in the near future. As AI technology continues to improve, it may become more integrated into the programming process, helping programmers to automate repetitive tasks and improve their overall productivity. ChatGPT is just one example of how AI is already being used to improve the programming experience, and more innovations in this field will likely emerge in the future.

    Honestly, I am super excited and would love to explore the possibilities of AI even further!

    The post How ChatGPT improved my Elixir code. Some hacks are included. appeared first on Erlang Solutions .

    • wifi_tethering open_in_new

      This post is public

      www.erlang-solutions.com /blog/how-chatgpt-improved-my-elixir-code-some-hacks-are-included/

    • chevron_right

      Erlang Solutions: Here’s why you should consider investing in RabbitMQ during a recession

      news.movim.eu / PlanetJabber • 25 May, 2023 • 6 minutes

    Europe and the US are leading the way in the forecasted recession for 2023, due to persistently high inflation and increasing interest rates. With minimal projected GDP growth, modern technologies can play a crucial role in reducing the impact of economic downturns.

    As caution looms, it can be tempting to reign in on your investment. Your initial thought is to balance the books and save money where you can which, on the surface, sounds like the sensible thing to do.

    But consider this. Investing in technology, specifically RabbitMQ in the face of recession can actually reduce the cost of doing business and save you money over time. In fact, leading digital organisations that have prioritised this has a lower cost of doing business and create a significant competitive edge in the current inflationary environment.

    Carving out a tech budget can signify that you’re conscious of the current challenges while being hopeful for the future. Being mindful of the long game can allow businesses to thrive as well as survive.

    So if you really want to recession-proof your business? We’ll tell you why it’s best to invest.

    Executives are already planning tech investments

    In a survey complied by Qualtrics, a majority of C-suite level executives (85%) expect spending to increase this year, as their companies go through both a workforce and digital transformation, with tech priorities as follows:

    1. Tech modernisation (73%)
    2. Cybersecurity (73%)
    3. Staffing/retaining workforce (72%)
    4. Training/reskilling workforce (70%)
    5. Remote work support (70%)

    This is a major shift from previous cycles we’ve seen. In the past, tech investments have been one of the first on the chopping block. But now, businesses have taken note that investing in technology is not a cost, but a business driver and differentiator.

    The game of business survival has changed

    Prior to the pandemic in 2020, digital capabilities were not considered a high priority by businesses when considering preparations for a potential economic downturn. Fast forward to today, and we can see that COVID-19 has expedited digital change for businesses.

    Companies have accelerated the digitisation of customer and supply-chain interactions by three to four years, and a sudden change in consumer habits has steered the ship.

    Consumers made a drastic shift towards online channels, which meant that industries had to ramp up their digital offerings fast. Rates of adoption during this time were lightyears of ahead when compared to previous years (as shown above).
    Fast forward to today and 48% of consumers say their buying habits have permanently changed since the pandemic. Businesses have to maintain their digital presence, in order to serve a growing market.

    Adapting to demand

    Technologies such as RabbitMQ have been integral to support the high volume of incoming requests and efficiently accommodate digital acceleration.

    Consider this- your website might be selling tickets to an event, and you’re anticipating a record number of visitors. Your main consideration is ensuring your satisfying customer wait times. So what’s the solution? A faster operating system.

    RabbitMQ technology helps with customer wait times through its ability to handle high volumes of incoming requests. These requests are distributed to various parts of the system, ensuring that each one is processed promptly. By effectively handling the increased load, RabbitMQ helps businesses maintain shorter wait times, accommodating increased or decreased message volumes with ease, as business demands fluctuate during a recession.

    Sustainability is steering the tech agenda

    Do you think businesses are slowing down on ESG during a recession? Think again.

    A recent study revealed nearly half of CFOs plan to increase investment in ESG initiatives this year despite high inflation, ongoing supply chain challenges and the risk of recession.

    According to the World Economic Forum, 90% of executives believe sustainability is important. However, only 60% of organisations have sustainability strategies.

    Addressing ESG initiatives during a recession requires a thoughtful approach from C-Suite leaders and should be apparent across your tech offerings. While not all software is inherently sustainable, tools like RabbitMQ can support sustainable practices.

    For example, organisations can further enhance the sustainability of their messaging infrastructure by running RabbitMQ on energy-efficient hardware, leveraging cloud services with renewable energy commitments, or optimising their message routing algorithms to minimise resource usage. These additional considerations can contribute to a more sustainable use of RabbitMQ as part of a broader sustainability framework within a business.

    Providing professional, reliable, and cutting-edge products and services with ESG values can bring meaningful change to people’s lives. And building social responsibility is critical to support the entire ecosystem.

    Tech built for business operations

    IT was once run by very centralised systems. But today, most software used by businesses is outsourced- meaning all the services are disjointed and require training to understand how to manage each one individually, which can be costly.

    SOA stands for Service-Oriented Architecture. In relation to RabbitMQ, SOA refers to a design approach where software applications are built as a collection of individual services that communicate with each other to perform specific tasks. RabbitMQ can play a role in facilitating communication between these services.

    An_Empirical_Analysis_on_the_Microservices_Architecture_Pattern_and_Service-Oriented_Architecture

    Imagine your company’s different departments- sales, inventory, shipping, HR etc. Each department has its own software application that handles specific tasks. In a traditional architecture, these applications might be tightly coupled, meaning they directly interact with each other.

    With a service-oriented architecture, the applications are designed as separate services. Each service focuses on a specific function, like processing sales orders, managing inventory, or tracking shipments. These services can communicate with each other by sending messages.

    RabbitMQ acts as a messenger between these services. When one service needs to send information or request something from another service, it can publish a message to RabbitMQ. The receiving service listens and responds accordingly. This decoupled approach allows services to interact without having direct knowledge of each other, promoting flexibility and scalability.

    For example, when a sales application receives a new order, it can publish a message to RabbitMQ containing the order details. The inventory service, subscribed to the relevant message queue, receives the order information, updates the inventory, and sends a confirmation back through RabbitMQ. The shipping service can then listen for shipping requests and initiate the shipping process.

    During a recession, SOA with RabbitMQ enables a more modular and flexible system, where services can be developed, deployed, and scaled independently. It simplifies communication between different components, promotes loose coupling, and allows for efficient integration and the ability to quickly adapt to changing market conditions of a recession.

    Tech supports recession-proofing goals

    Investment in innovative digital initiatives is indispensable for a constantly evolving digital transformation journey, especially during market shifts. Programmes such as RabbitMQ provide organisations with the flexibility required to swiftly shift to new solutions, responding to market changes more quickly.

    To conclude, although recessions can be intimidating, it is crucial for businesses to embrace technology as a means to prepare themselves and ensure a positive customer experience. Leveraging technological solutions allows businesses to stay resilient, adapt to changing market dynamics, and position themselves for long-term success, even in challenging economic times.

    If you’d like to talk about your current tech space, feel free to drop us a line .

    The post Here’s why you should consider investing in RabbitMQ during a recession appeared first on Erlang Solutions .

    • wifi_tethering open_in_new

      This post is public

      www.erlang-solutions.com /blog/heres-why-you-should-consider-investing-in-rabbitmq-during-a-recession/

    • chevron_right

      Ignite Realtime Blog: CVE-2023-32315: Openfire Administration Console authentication bypass

      news.movim.eu / PlanetJabber • 23 May, 2023

    We’ve had an important security issue reported that affects all recent versions of Openfire. We’ve fixed it in the newly published 4.6.8 and 4.7.5 releases. We recommend people upgrade as soon as possible. More info, including mitigations for those who cannot upgrade quickly, is available in this security advisory: CVE-2023-32315: Administration Console authentication bypass .

    Related to this issue, we have also made available updates to three of our plugins:

    If you’re using these plugins, it is recommended to update them immediately.

    When you are using the REST API plugin, or any proprietary plugins, updating Openfire might affect availability of their functionality. Please find work-arounds in the security advisory .

    If you have any questions, please stop by our community forum or our live groupchat .

    For other release announcements and news follow us on Twitter and Mastodon .

    1 post - 1 participant

    Read full topic

    • wifi_tethering open_in_new

      This post is public

      discourse.igniterealtime.org /t/cve-2023-32315-openfire-administration-console-authentication-bypass/92869

    • chevron_right

      Ignite Realtime Blog: Openfire 4.7.5 Release

      news.movim.eu / PlanetJabber • 23 May, 2023

    The Ignite Realtime Community is happy to announce the 4.7.5 release of Openfire!

    This release primarily addresses the issue that is subject of security advisory CVE-2023-32315 , but also pulls in a number of improvements and bugfixes

    You can find download artifacts available here with the following sha256sum values

    f70faf11b4798fefb26a20f7d60288d275a6d568db78faf79a4194cbae72eab4  openfire-4.7.5-1.noarch.rpm
    d1283d417dacb74d67334c06420679aae62d088bd3439c8135ccfc272fd5b95b  openfire_4.7.5_all.deb
    60d8efb96a1891cda2deac2cda9808cf6adec259f090d3a7fb2b7ca21484d75b  openfire_4_7_5.exe
    98d36c2318706c545345274234e2f5ccbf0f72f7801133effea342e2776b8bb0  openfire_4_7_5.tar.gz
    e95348be890aff64a7447295ab18eebb29db4bdc346b802df0c878ebbbf1d18e  openfire_4_7_5_x64.exe
    a5bb8c9b944b915bdf7ecf92cd2a689d0cf09e88bfc2df960f38000f6b788194  openfire_4_7_5.zip
    

    If you have any questions, please stop by our community forum or our live groupchat . We are always looking for volunteers interested in helping out with Openfire development!

    For other release announcements and news follow us on Twitter and Mastodon .

    1 post - 1 participant

    Read full topic

    • chevron_right

      Ignite Realtime Blog: Openfire 4.6.8 Release

      news.movim.eu / PlanetJabber • 23 May, 2023 • 2 minutes

    The Ignite Realtime Community is happy to announce the 4.6.8 release of Openfire!

    We have made available a new release of this older version to addresses the issue that is subject of security advisory CVE-2023-32315 .

    We are aware that for some, the process of deploying a new major version of Openfire is not a trivial matter, as it may encompass a lot more than only performing the update of the executables. Depending on regulations that are in place, this process can require a lot of effort and take a long time to complete. To facilitate users that currently use an older version of Openfire, we are also making available this new release in the older 4.6 branch of Openfire. An upgrade to this version will, for some, require a lot less effort. Note well: although we are making available a new version in the 4.6 branch of Openfire, we strongly recommend that you upgrade to the latest version of Openfire (currently in the 4.7 branch), as that includes important fixes and improvements that are not available in 4.6.

    You can find download artifacts available here with the following sha256sum values

    aa1947097895a6d41bc8d1ac29f6ea60507bce69caadc497b4794a2a4110dc20  openfire-4.6.8-1.i686.rpm
    346871c71eff8e3b085fecd2f8dce5bfbf387885cfa7aff2076d42bd7273f70b  openfire-4.6.8-1.noarch.rpm
    37e4cc510cc2a59de50288c0e3baa53dcc702631433a01873a9270eeb7c789db  openfire-4.6.8-1.x86_64.rpm
    e92c5a0b76da5964b2e3fa43686ad63db29ef891ec7266ab16fe3a93b06c9e01  openfire_4.6.8_all.deb
    c6e0e40c55a81276881e93469ce88a862226ce33e58c8811e760427b878ebed4  openfire_4_6_8_bundledJRE.exe
    1b4c209453fffb6a6310354b425995bb92c1f09944eed35a1fd61a30201355bc  openfire_4_6_8_bundledJRE_x64.exe
    6b19394dc3f275ca039f85af59ca4f2fc5f628e2505cb39e59f5cfa55d605788  openfire_4_6_8.exe
    b22fce993bce4930346183d5edc1e9e38827a47ed8f64c41486a105f574cc116  openfire_4_6_8.tar.gz
    7c5769c7c8869ce2dfbb93fbbf1ec97a4e8509d61f8c14ba3f6be20abd05e90e  openfire_4_6_8_x64.exe
    72f27d063446479e1d4ceb2a46ac838f5462dfca53032cfa068eb96ef08d0697  openfire_4_6_8.zip
    

    If you have any questions, please stop by our community forum or our live groupchat . We are always looking for volunteers interested in helping out with Openfire development!

    For other release announcements and news follow us on Twitter and Mastodon .

    1 post - 1 participant

    Read full topic

    • chevron_right

      Erlang Solutions: Entendiendo procesos y concurrencia

      news.movim.eu / PlanetJabber • 18 May, 2023 • 8 minutes

    Bienvenidos al segundo capítulo de la serie “ Elixir, 7 pasos para iniciar tu viaje” .

    En el primer capítulo hablamos sobre la máquina virtual de Erlang, la BEAM, y las características que Elixir aprovecha de ella para desarrollar sistemas que son:

    • Concurrentes
    • Tolerantes a fallos
    • Escalables y
    • Distribuidos

    En esta nota explicaremos qué significa la concurrencia para Elixir y Erlang y por qué es importante para desarrollar sistemas tolerantes a fallos. Al final encontrarás un pequeño ejemplo de código hecho con Elixir para que puedas observar las ventajas de la concurrencia en acción.

    Concurrencia

    La concurrencia es la habilidad para llevar a cabo dos o más tareas

    aparentemente al mismo tiempo .

    Para entender por qué la palabra aparentemente está resaltada, veamos el siguiente caso:

    Una persona tiene que completar dos actividades, la tarea A y la tarea B

    • Inicia la tarea A, avanza un poco y la pausa.
    • Inicia la tarea B, avanza un poco, la pausa y continúa con la tarea A.
    • Avanza un poco con la tarea A, la pausa y continúa con la tarea B.

    Y así va avanzando con cada una, hasta terminar ambas actividades.

    No es que la tarea A y la tarea B se lleven a cabo exactamente al mismo tiempo, más bien la persona dedica un tiempo a cada una y va intercambiándose entre ellas. Estos tiempos pueden ser tan cortos que el cambio es imperceptible para nosotros, por eso se produce la ilusión de que las actividades están sucediendo simultáneamente.

    Paralelismo

    Hasta ahora no había mencionado nada sobre paralelismo porque no es un concepto fundamental en la BEAM o para Elixir. Pero recuerdo que cuando estaba aprendiendo a programar se me dificultó comprender la diferencia entre paralelismo y concurrencia, así que aprovecharé esta nota para compartirte una breve explicación.

    Sigamos con el ejemplo anterior. Si ahora traemos a otra persona para completar las tareas y ambas trabajan al mismo tiempo, hablamos de paralelismo .

    De manera que podríamos tener a dos o más personas trabajando paralelamente, cada una llevando a cabo sus actividades concurrentemente. Es decir, la concurrencia puede ser o no paralela.

    En Elixir la concurrencia se logra gracias a los procesos de Erlang, que son creados y administrados por la BEAM.

    Procesos

    En Elixir todo el código se ejecuta dentro de procesos. Y una aplicación puede tener cientos o miles de ellos ejecutándose de manera concurrente.

    ¿Cómo funciona?

    Cuando la BEAM se ejecuta en una máquina, se encarga de crear por default un hilo en cada procesador disponible. En ese hilo existe una cola dedicada a tareas específicas, y cada cola tiene a su vez un administrador ( scheduler ) que es responsable de asignar un tiempo y una prioridad a las tareas.

    Entonces, en una máquina multicore con dos procesadores puedes tener dos hilos y dos schedulers , lo que te permite paralelizar las tareas al máximo. También puedes ajustar la configuración de la BEAM para indicarle qué procesadores utilizar.

    En cuanto a las tareas, cada una se ejecuta en un proceso aislado.

    Parece algo simple, pero justamente esta idea es la magia detrás de la escalabilidad, distribución y tolerancia a fallos de un sistema hecho con Elixir.

    Veamos este último concepto para entender por qué.

    Tolerancia a fallos

    La tolerancia a fallos de un sistema se refiere a la capacidad que tiene para manejar los errores y no morir en el intento. El objetivo es que ninguna falla, sin importar lo crítica que sea, inhabilite o bloquee el sistema. Esto se logra nuevamente gracias a los procesos de Erlang.

    Los procesos son elementos aislados, que no comparten memoria y se comunican mediante paso de mensajes.

    Lo anterior significa que si algo falla en el proceso A, el proceso B no se ve afectado, es más, es posible que ni siquiera se entere. El sistema seguirá funcionando con normalidad mientras la falla se arregla tras bambalinas . Y si a esto sumamos que la BEAM también nos proporciona por defecto mecanismos para detección y recuperación de errores podemos garantizar que el sistema funcione de manera ininterrumpida.

    Si quieres explorar más acerca del funcionamiento de los procesos, puedes consultar esta nota: Understanding Processes for Elixir Developers .

    ¿Cómo se ve esto en Elixir?

    ¡Por fin llegamos al código!

    Revisemos un ejemplo de cómo crear procesos que se ejecutan de manera concurrente en Elixir. Lo vamos a contrastar con el mismo ejercicio ejecutándose de manera secuencial.

    ¿Listo? No te preocupes si no entiendes algo de la sintaxis, en general el lenguaje es muy intuitivo, pero el objetivo por ahora es que seas testigo de la magia de la concurrencia en acción.

    El primer paso consiste en crear los procesos.

    Spawn

    Hay diferentes formas de crear procesos en Elixir. A medida que vayas avanzando encontrarás maneras más sofisticadas de hacerlo, aquí utilizaremos la básica: la función spawn . ¡Manos a la obra!

    Tenemos 10 registros que corresponden a la información de usuarios que vamos a insertar en una base de datos, pero antes queremos validar que el nombre no contenga caracteres raros y que el email tenga un @.

    Supongamos que la validación de cada usuario tarda en total 2 segundos.

    1. Abre un editor de texto y copia el siguiente código. Guárdalo en un archivo llamado procesos.ex
    defmodule Procesos do
    
    
     # Vamos a utilizar expresiones regulares para el formato del nombre y
     # el correo electrónico
     @email_valido ~r/^([a-zA-Z0-9_\-\.\+]+)@([a-zA-Z0-9_\-\.]+)\.([a-zA-Z]{2,5})$/
     @nombre_valido ~r/\b([A-ZÀ-ÿ][-,a-z. ']+[ ]*)+/
    
    
     # Se tiene una lista de usuarios con un nombre y correo electrónico. 
     # La función validar_usuarios_X manda a llamar a otra función: 
     # validar_usuario, que revisa el formato del correo e imprime un
     # mensaje de ok o error para cada registro
    
    
     # Esta función trabaja SECUENCIALMENTE
     def validar_usuarios_secuencialmente() do
       IO.puts("Validando usuarios secuencialmente...")
    
    
       usuarios = crear_usuarios()
    
    
       Enum.each(usuarios, fn elem -> 
         validar_usuario(elem) end)
    end
    
    
     # Esta función trabaja CONCURRENTEMENTE, utilizando spawn
     def validar_usuarios_concurrentemente() do
       IO.puts("Validando usuarios concurrentemente...")
    
    
       usuarios = crear_usuarios()
    
    
       Enum.each(usuarios, fn elem ->
         spawn(fn -> validar_usuario(elem) end)
       end)
     end
    
    
     def validar_usuario(usuario) do
       usuario
       |> validar_email()
       |> validar_nombre()
       |> imprimir_estatus()
    
    
    # Esto hace una pausa de 2 segundos para simular que el proceso inserta # los registros en base de datos
       Process.sleep(2000)
     end
    
    
     # Esta función recibe un usuario, valida el formato del correo y le 
     # agrega la llave email_valido con el resultado.
    def validar_email(usuario) do
       if Regex.match?(@email_valido, usuario.email) do
         Map.put(usuario, :email_valido, true)
       else
         Map.put(usuario, :email_valido, false)
       end
     end
    
    
     # Esta función recibe un usuario, valida su nombre y le agrega la
     # llave nombre_valido con el resultado.
     def validar_nombre(usuario) do
       if Regex.match?(@nombre_valido, usuario.nombre) do
         Map.put(usuario, :nombre_valido, true)
       else
         Map.put(usuario, :nombre_valido, false)
       end
     end
    # Esta función recibe un usuario que ya pasó por la validación
     # de email y nombre y dependiendo de su resultado, imprime el
     # mensaje correspondiente al estatus.
     def imprimir_estatus(%{
           id: id,
           nombre: nombre,
           email: email,
           email_valido: email_valido,
           nombre_valido: nombre_valido
         }) do
       cond do
         email_valido && nombre_valido ->
           IO.puts("Usuario #{id} | #{nombre} | #{email} ... es válido")
    
    
         email_valido && !nombre_valido ->
           IO.puts("Usuario #{id} | #{nombre} | #{email} ... tiene un nombre inválido")
    
    
         !email_valido && nombre_valido ->
           IO.puts("Usuario #{id} | #{nombre} | #{email} ... tiene un email inválido")
    
    
         !email_valido && !nombre_valido ->
           IO.puts("Usuario #{id} | #{nombre} | #{email} ... es inválido")
       end
     end
    
    
     defp crear_usuarios do
       [
         %{id: 1, nombre: "Melanie C.", email: "melaniec@test.com"},
         %{id: 2, nombre: "Victoria Beckham", email: "victoriab@testcom"},
         %{id: 3, nombre: "Geri Halliwell", email: "gerih@test.com"},
         %{id: 4, nombre: "123456788", email: "melb@test.com"},
         %{id: 5, nombre: "Emma Bunton", email: "emmab@test.com"},
         %{id: 6, nombre: "Nick Carter", email: "nickc@test.com"},
         %{id: 7, nombre: "Howie Dorough", email: "howie.dorough"},
         %{id: 8, nombre: "", email: "ajmclean@test.com"},
         %{id: 9, nombre: "341AN L1ttr377", email: "Brian-Littrell"},
         %{id: 10, nombre: "Kevin Richardson", email: "kevinr@test.com"}
       ]
     end
    end
    

    2. Abre una terminal, escribe iex y compila el archivo que acabamos de crear.

    $ iex
    
    
    Erlang/OTP 25 [erts-13.1.3] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit:ns]
    
    
    Interactive Elixir (1.14.0) - press Ctrl+C to exit (type h() ENTER for help)
    iex(1)> c("procesos.ex")
    [Procesos]

    3. Una vez que hayas hecho esto, manda a llamar la función que valida los registros secuencialmente. Tomará un poco de tiempo, ya que cada registro tarda 2 segundos.

    
    iex(2)>  Procesos.validar_usuarios_secuencialmente

    4. Ahora manda a llamar la función que valida los registros concurrentemente y observa la diferencia en tiempos.

    iex(3)>  Procesos.validar_usuarios_concurrentemente

    Es bastante notoria, ¿no crees? Esto se debe a que en el paso 3, con la evaluación secuencial, cada proceso tiene que esperar a que el anterior termine. En cambio, la ejecución concurrente crea procesos que funcionan aisladamente; por lo tanto, ninguno depende del anterior ni está bloqueado por ninguna otra tarea.

    ¡Imagina la diferencia cuando se trata de miles o millones de tareas en un sistema!

    La concurrencia es la base para las otras características que mencionamos al inicio: distribución, escalabilidad y tolerancia a fallos. Gracias a la BEAM, se vuelve relativamente fácil implementarla en Elixir y aprovechar las ventajas que nos brinda.

    Ahora, ya conoces más sobre procesos y concurrencia, especialmente sobre la importancia de este aspecto para crear sistemas altamente confiables y tolerantes a fallas. Recuerda practicar y volver a esta nota cuando lo necesites.

    Siguiente capítulo…

    En la siguiente nota hablaremos de las bibliotecas, frameworks y todos los recursos que existen alrededor de Elixir. Te sorprenderá lo fácil y rápido que es crear un proyecto desde cero y verlo funcionando.

    Documentación y Recursos

    Consejero técnico:

    Raúl Chouza

    Corrección de estilo:

    Si tienes dudas acerca de esta nota o te gustaría profundizar en el tema, puedes escribirme por Twitter a @loreniuxmr .

    ¡Nos vemos en el siguiente capítulo!

    The post Entendiendo procesos y concurrencia appeared first on Erlang Solutions .

    • chevron_right

      Erlang Solutions: Understanding Elixir processes and concurrency

      news.movim.eu / PlanetJabber • 18 May, 2023 • 7 minutes

    Welcome to the second chapter of the “Elixir, 7 steps to start your journey” series.

    In the first chapter , we talk about the Erlang Virtual Machine, the BEAM, and the characteristics that Elixir takes advantage of to develop systems that are:

    • Concurrent
    • Fault-tolerant
    • Scalable and
    • Distributed

    In this note, I’ll explain what concurrency means to Elixir and Erlang and why it’s essential for building fault-tolerant systems. You’ll also find a little Elixir code example to see the advantages of concurrency in action.

    Concurrency

    Concurrency is the ability to perform two or more tasks apparently at the same time.

    To understand why the word apparently is highlighted, let’s look at the following case:

    A person has to complete two activities, task A and task B.

    • Starts task A, moves forward a bit, and pauses.
    • Starts task B, moves forward, pauses, and continues with task A.
    • Goes ahead with task A, pauses, and continues with task B.

    And so it progresses with each one, until finishing both activities.

    It is not that task A and task B are carried out at precisely the same time; instead, the person spends time on each one and interchanges between them. But these times can be so short that the change is invisible to us, so the illusion is produced that the activities are happening simultaneously.

    Parallelism

    So far, I haven’t mentioned anything about parallelism because it’s not a fundamental concept in the BEAM or for Elixir. But I remember that when I was learning to program, it took me a while to understand the difference between parallelism and concurrency, so I took advantage of this note to explain briefly.

    Let’s continue with the previous example. If we now bring in another person to complete the tasks and they both work at the same time, we now achieve parallelism.

    So, we could have two or more people working in parallel, each carrying out their activities concurrently. That is, the concurrency may or may not be parallel.

    In Elixir, concurrency is achieved thanks to Erlang processes, which are created and managed by the BEAM.

    Processes

    In Elixir all code runs inside processes. And an application can have hundreds or thousands of them running concurrently.

    How does it work?

    When the BEAM runs on a machine, it creates a thread on each available processor by default. In this thread, there is a queue dedicated to specific tasks, and each queue has a scheduler responsible for assigning a time and a priority to the tasks.

    So, on a multicore machine with two processors, you can have two threads and two schedulers, allowing you to parallelize tasks as much as possible. You can also adjust BEAM’s settings to indicate which processors to use.

    As for the tasks, each one is executed in an isolated process.

    It seems simple, but precisely this idea is the magic behind the scalability, distribution, and fault tolerance of a system built with Elixir.

    Let’s go deep into this last concept to understand why.

    Fault-tolerance

    The fault tolerance of a system refers to its ability to handle errors. The goal is that no failure, no matter how critical, disables or blocks the system and this is again achieved thanks to Erlang processes.

    The processes are isolated elements that do not share memory and communicate through message passing.

    This means that if something goes wrong in process A, process B is unaffected. It may not even know about it. The system will continue functioning normally while the fault is fixed behind the scenes. And if we add that the BEAM also provides default mechanisms for error detection and recovery, we can guarantee that the system works uninterruptedly.

    Elixir

    If you want to explore more about how the processes work, you can check this note: Understanding Processes for Elixir Developers .

    What does this look like in Elixir?

    Finally, the code!

    Let’s review an example of creating processes that run concurrently in Elixir. We are going to contrast it with the same exercise running sequentially.

    Ready? Don’t worry if you don’t understand some of the syntax; overall, the language is very intuitive, but the goal is to witness the magic of concurrency in action.

    The first step is to create the processes.

    Spawn

    There are different ways to create processes in Elixir. As you progress, you will find more forms to do it; here, we will use the basic one: the spawn function. Let’s do it!!

    We have ten records that correspond to the user’s information that we will insert into a database, but first, we want to validate that the name does not contain random characters and that the email has @.

    Suppose each user validation takes a total of 2 seconds.

    1. In your favorite text editor copy the following code. Save it in a file called processes.ex
    defmodule Processes do
    
    
     # We are going to use regular expressions for the name format and the
     # email
     @valid_email ~r/^([a-zA-Z0-9_\-\.\+]+)@([a-zA-Z0-9_\-\.]+)\.([a-zA-Z]{2,5})$/
     @valid_name ~r/\b([A-ZÀ-ÿ][-,a-z. ']+[ ]*)+/
    
    
    # There is a list of users with a name and email.
    # The function validate_users_X calls another function:
    # validate_user, which checks the format of the email and prints an
    # ok or error message for each record
    
    
     # This function works SEQUENTIALLY
     def validate_users_sequentially() do
       IO.puts("Validating users sequentially...")
    
    
       users = create_users()
    
    
       Enum.each(users, fn elem -> 
         validate_user(elem) end)
    end
    
    
     # This function works CONCURRENTLY, with spawn
     def validate_users_concurrently() do
       IO.puts("Validating users concurrently...")
    
    
       users = create_users()
    
    
       Enum.each(users, fn elem ->
         spawn(fn -> validate_user(elem) end)
       end)
     end
    
    
     def validate_user(user) do
       user
       |> validate_email()
       |> validate_name()
       |> print_status()
    
    
     # This pauses for 2 seconds to simulate the process inserting 
     # the records into the database
       Process.sleep(2000)
     end
    
    
     # This function receives a user, validates the format of the email and
     # add the valid_email key to the result.
    def validate_email(user) do
       if Regex.match?(@valid_email, user.email) do
         Map.put(user, :valid_email, true)
       else
         Map.put(user, :valid_email, false)
       end
     end
    
    
    # This function receives a user, validates the format of the name and
     # add the valid_name key to the result.
     def validate_name(user) do
       if Regex.match?(@valid_name, user.name) do
         Map.put(user, :valid_name, true)
       else
         Map.put(user, :valid_name, false)
       end
     end
    
    
     # This function receives a user that has already gone through  
     # validation email and name and depending on its result, prints 
     # the message corresponding to the status.
     def print_status(%{
           id: id,
           name: name,
           email: email,
           valid_email: valid_email,
           valid_name: valid_name
         }) do
       cond do
         valid_email && valid_name ->
           IO.puts("User #{id} | #{name} | #{email} ... is valid")
    
    
         valid_email && !valid_name ->
           IO.puts("User #{id} | #{name} | #{email} ... has an invalid name")
    
    
         !valid_email && valid_name ->
           IO.puts("User #{id} | #{name} | #{email} ... has an invalid email")
    
    
         !valid_email && !valid_name ->
           IO.puts("User #{id} | #{name} | #{email} ... is invalid")
       end
     end
    
    
     defp create_users do
       [
         %{id: 1, name: "Melanie C.", email: "melaniec@test.com"},
         %{id: 2, name: "Victoria Beckham", email: "victoriab@testcom"},
         %{id: 3, name: "Geri Halliwell", email: "gerih@test.com"},
         %{id: 4, name: "123456788", email: "melb@test.com"},
         %{id: 5, name: "Emma Bunton", email: "emmab@test.com"},
         %{id: 6, name: "Nick Carter", email: "nickc@test.com"},
         %{id: 7, name: "Howie Dorough", email: "howie.dorough"},
         %{id: 8, name: "", email: "ajmclean@test.com"},
         %{id: 9, name: "341AN L1ttr377", email: "Brian-Littrell"},
         %{id: 10, name: "Kevin Richardson", email: "kevinr@test.com"}
       ]
     end
    end
    

    2. Open a terminal, type iex and compile the file we just created.

    $ iex
    
    
    Erlang/OTP 25 [erts-13.1.3] [source] [64-bit] [smp:8:8] [ds:8:8:10] [async-threads:1] [jit:ns]
    
    
    Interactive Elixir (1.14.0) - press Ctrl+C to exit (type h() ENTER for help)
    iex(1)> c("processes.ex")
    [Processes]

    3. Once you’ve done this, call the function that validates the records sequentially. Remember that it will take a little time since each record takes 2 seconds.

    iex(2)>  Processes.validate_users_sequentially

    4. Now call the function that validates the records concurrently and observe the difference in times.

    iex(3)>  Processes.validate_users_concurrently

    It’s pretty noticeable, don’t you think? This is because in step 3, with sequential evaluation, each process has to wait for the previous one to finish. Instead, concurrent execution creates processes that run in isolation; therefore, neither depends on the former nor does any other task block it.

    Imagine the difference with thousands or millions of tasks in a system!

    Concurrency is the foundation for the other features we mentioned: distribution, scalability, and fault tolerance. Thanks to the BEAM, implementing it in Elixir and taking advantage of it becomes relatively easy.

    Now, you know more about processes and concurrency, especially about the importance of this aspect in building highly reliable and fault-tolerant systems. Remember to practice and come back to this note when you need to.

    Next Chapter

    In the next note, we will talk about the libraries, frameworks, and all the resources that exist around Elixir. You will be surprised how easy and fast it is to create a project from scratch and see it working.

    Documentation and Resources

    Technical Adviser

    Style correction

    If you have questions about this story or want to go deeper, you can reach me on Twitter @loreniuxmr .

    See you in the next chapter!

    The post Understanding Elixir processes and concurrency appeared first on Erlang Solutions .

    • wifi_tethering open_in_new

      This post is public

      www.erlang-solutions.com /blog/understanding-elixir-processes-and-concurrency/

    • chevron_right

      Isode: Messaging Products Update – 19.0 Capabilities

      news.movim.eu / PlanetJabber • 16 May, 2023 • 5 minutes

    The below is a list of the new capabilities brought to our Messaging products for the 19.0 release. 19.0 adds a lot of extra functionality across the board for our messaging products, along with a complete rewrite of the codebase so that future releases and bug fixes can be developed more quickly. For the full release notes please check the individual product updates, available from the customer portal and evaluation sections of our website.

    Dependencies

    Cobalt (version 1.3 or later) is needed to manage various capabilities in M-Switch 19.0.

    M-Switch, M-Store and M-Box depend on M-Vault 19.0.   All of these products are a part of R19.0 with common libraries and so are commonly installed together.

    Product Activation

    All of the messaging products now use the new product activation.  Products activation is managed with the Messaging Activation Server (MAS) which provides a Web interface to facilitate managing activation of messaging and other Isode products.   MAS is provided as a tool, but installed as an independent component.

    M-Switch

    Product Activation

    There are a number of M-Switch features arising from the new product activation:

    • Various product options are encoded in the activation, restricting functionality to M-Switch options purchased.   The options available and any activation time limits are displayed by MConsole.
    • MConsole will correctly display the product name of the M-Switch being used (e.g., M-Switch MIXER, M-Switch Gateway etc).
    • MConsole views are restricted so that only ones relevant to the activated options are shown (e.g,, ACP 127 views will not be shown unless ACP 127 is activated).

    Use of Cobalt

    A number of functions have been moved from MConsole to Cobalt, which provides a Web general administrator interface.   MConsole is being more focused on M-Switch server configuration and operation.   Capabilities provided by Cobalt in support of M-Switch:

    • User and Role provisioning (replacing Internet Mail View)
    • Special function mailboxes
    • Redirections
    • Standard SMTP distribution lists
    • Military Distribution Lists
    • Profiler Configuration
    • File Transfer by Email (FTBE) account provisioning

    Directory and Authentication

    A number of enhancements have been made to improve security of authentication.   New configurations will require this improved security and upgrades are expected to switch.

    • Configuration of default M-Vault configuration directory is simplified.
    • Option provided to use a different M-Vault directory for users/operators, defaulting to the configuration directory.
    • M-Switch access to configuration and user directories will always authenticate using SASL SCRAM-SHA-1.  This is particularly important for deployments not using TLS, as it will ensure plain passwords are not sent over a link, while still using hashed passwords in M-Vault.
    • M-Vault directories created by MConsole will always have TLS enabled (where the product activation option allows).
    • Connections from M-Switch to M-Vault will use TLS by default.
    • Three modes can be configured for SMTP and SOM (MConsole) access to M-Switch
      • SCRAM-SHA-1.  This is the default and is a secure option suitable for most configurations.
      • PLAIN.  This option is needed if authentication is done using pass through to Active directory.   This should only be used on systems with TLS.
      • ANY.  When this option is used, SOM/MConsole will use SCRAM-SHA-1.   It is needed for SMTP setups that want to offer additional SASL mechanisms such as CRAM-MD5, which will need plain passwords to be stored in M-Vault.

    ACP 127

    An extensive set of enhancements had been provided to ACP 127.

    • Extend circuit control from enabled/disable to Enabled (Rx/Tx) / Rx Only / Disabled
    • Enhanced OPSIG support for BRIPES following agreed doc:
      • QRT/QRV.   Supports remote enable/disable, including control from top level of circuit management UI
      • ZES2 automatic handling on receive
      • Service message option to send INT ZBZ
      • Configurable option for reliable circuit to send ZBZ5 to acknowledge receipt of identified message
      • Limiting priority UI use two letter codes, but will still recognize single letter
      • Add CHANNEL CHECK generation and response
    • Option to use “Y” for emergency messages
    • Support for Community Variables (CV) which is a BRASS mechanism to use multiple crypto keys
      • Configuration of CVs available for each destination
      • Display of CVs for queued messages
      • CV Audit Logging
    • Scheduled Broadcasts to support MUs with constrained availability (e.g., Submarines)
      • Periodic Mode with GUI configuration
      • UI to show which messages will be transmitted in which period based on estimated transmission times
      • Scheduled periods at same time each day
      • Explicitly scheduled fixed intervals on specific day
    • Extension to Routing Tree configuration to specify specific channel.   This makes it easier to utilize the ACP 127 RI routing, which is needed in many ACP 127 configurations
    • Improved mapping of CAD/AIG to SMTP
    • Option to turn off message reassembly
    • Improvements to monitoring of circuits using serial links

    FAB (Frequency Assignment Broadcast)

    A subsystem is provided to support FAB, which is needed for older BRASS systems that do not support ALE. The M-Switch FAB architecture is described in https://www.isode.com/whitepapers/brass.html . The key points are listed below:

    • A new FAB Server component is provided to run black side and generate the FAB data stream(s).
    • Red/Black separation can be provided by M-Guard
    • The FAB Server can monitor a remote modem for link quality using a new SNR monitoring protocol provided by Icon-5066 3.0.
    • Circuits to support FAB use a new “anonymous” type, reflecting that they are not associated with a specific peer.
    • Support is provided for ARQ (STANAG 5066 COSS) circuits which operate automatically shore side and for direct to modem circuits which require a shore side operator.
    • There is an operator UI for each circuit that enables setting FAB status and controlling acceptance of messages

    Profiler and Corrector

    1. Support of TLS for Corrector UI and Manual Profiler
    2. Improved message display, including Security Label
    3. Profile configuration read from directory, which enables Cobalt configuration of Profiler rules

    Icon-Topo Support

    Isode’s Icon-Topo product automatically updates M-Switch configuration in support of MU Mobility.  M-Switch enhancements made in support of this:

    • Show clearly in MConsole when External MTAs, Routing Tree Entries and Nexus are created by Icon-Topo.
    • Enhance Nexus and Diversion UI to better display Icon-Topo created information.

    Miscellaneous

    • Configure Warning Time based on Message Priority.
    • Tool to facilitate log and archive clear out

    M-Store

    No new features for R19.0.

    M-Box

    Improved Searching

    Message searching is extended with three new capabilities that are exposed in Harrier.

    • Choice to search based on SIC (Subject Indicator Code) which can be used on its own or in conjunction with options to search other parts of the message.
    • Option to filter search based on a choice of one or more message precedences, matching against the action or info precedence as appropriate for the logged in user.
    • Option to filter search based on selected security label.

    • wifi_tethering open_in_new

      This post is public

      www.isode.com /company/wordpress/messaging-products-update-19-0-capabilities/