DEV Community: François

Building AI-Powered Dream Analysis with Mistral AI in My Rails API

François — Tue, 02 Jun 2026 11:46:35 +0000

Pastel is a project I built alone — an API where users log their sleep experiences: dreams, nightmares, lucid sleeps, and the emotional patterns that come with them. Recently, I decided to push it further. What if the app could analyze those dreams for you? What if it could look at the description, the mood, the tags, and tell you something meaningful about what your dream might be saying?

So I built it. Using Mistral AI, background jobs, and a whole lot of defensive coding. Here's how I did it.

What I Wanted

The flow I had in mind was simple: a user logs a sleep entry with a title, a description, a sleep type (lucid, nightmare, recurring), tags, their current mood, and the intensity of the experience. From all that context, I wanted to return a structured, insightful interpretation — and in their language, not just English.

The hard part wasn't the API call. The hard part was making it reliable, testable, and production-ready.

The Architecture I Settled On

POST /api/v1/sleeps/:id/analyse
│
▼
┌──────────────────────┐
│ SleepsController │ ← I validate status, enqueue the job
│ #analyse │
└──────────────────────┘
│
▼ (enqueue)
┌──────────────────────┐
│ SleepAnalyseJob │ ← Background job via Solid Queue
│ perform() │
└──────────────────────┘
│
▼ (call)
┌──────────────────────┐
│ SleepAnalysisService │ ← I call Mistral, parse the response
│ call() │
└──────────────────────┘
│
▼
┌──────────────────────┐
│ Mistral AI API │ ← magistral-small-2509 model
│ /chat/completions │
└──────────────────────┘

It's a classic Rails async pattern. The controller validates and enqueues, the background job orchestrates, and a service object encapsulates the business logic. Let me walk you through each layer.

First Problem: How Do I Track the Analysis Lifecycle?

Dream analysis isn't instantaneous. I needed a way to track where each request was in its lifecycle. I could have just used a boolean — analyzed or not — but that felt fragile. What if the API times out? What if the job crashes? What if the user spams the endpoint?

So I added a proper three-state enum to the Sleep model:

ANALYSIS_STATUS = {
  not_started: 'not_started',
  in_progress: 'in_progress',
  done: 'done'
}.freeze

enum :analysis_status, ANALYSIS_STATUS, default: 'not_started'

And two explicit state-transition methods so nothing happens by accident:

def mark_as_analysis_not_started
  update(analysis_status: :not_started)
end

def mark_as_analysis_done(analysis)
  update(analysis: analysis, analysis_status: :done)
end

I also encrypted the analysis field alongside the other sensitive data (title, description, current_mood). Dream analysis results are deeply personal — they deserve the same protection as the original dream:

encrypts :title, :description, :current_mood, :analysis

See the Rails Active Record Encryption docs for more on this feature.

Finally, a scope for my dashboard so I can track how many dreams have been analyzed:

scope :ai_analyzed, -> { where.not(analysis: nil).where(analysis_status: :done) }

The Controller: Idempotency Is My Obsession

When I wrote the #analyse action, the first thing I thought about was: what happens if someone calls this twice? Or if a mobile app retries the request because of a slow connection?

def analyse
  if @sleep.analysis_status == 'done' ||
     @sleep.analysis_status == 'in_progress' ||
     @sleep.analysis.present?
    return render json: {
      message: 'Sleep analysis already in progress or done',
      code: 'analysis_already_in_progress_or_done'
    }, status: :ok
  end

  locale = params[:locale] || I18n.default_locale
  SleepAnalyseJob.perform_later(@sleep.id, locale)

  @sleep.analysis_status = :in_progress
  if @sleep.save
    render json: SleepSerializer.render(@sleep, view: :update_and_show)
  else
    render json: { message: 'Failed to start sleep analysis', code: 'analysis_start_failed' },
           status: :unprocessable_content
  end
end

Three decisions here that I'm proud of:

Idempotency everywhere. I check the status enum AND the presence of an existing analysis. The endpoint can be called a hundred times — only the first one does anything.
Locale passthrough. The locale travels from the request, through the job, into the service, and directly into the Mistral prompt. The AI responds in the user's language.
Optimistic status update. I set the status to in_progress immediately. If a second request arrives while the job is running, it gets rejected cleanly.

Solid Queue for Background Processing

I integrated Solid Queue — Rails' built-in Active Job backend — to handle dream analysis asynchronously. Making an AI API call synchronously in a controller request? That's a terrible user experience.

class SleepAnalyseJob < ApplicationJob
  queue_as :sleep_analysis

  def perform(sleep_id, locale)
    sleep = Sleep.find_by(id: sleep_id)
    return if sleep.blank?
    return if sleep.analysis_status == 'done' || sleep.analysis.present?

    SleepAnalysisService.call(sleep, locale)
  rescue StandardError => e
    Rails.logger.error("Error analyzing sleep with ID: #{sleep_id} - #{e.message}")
    sleep.presence&.mark_as_analysis_not_started
    raise
  end
end

Three layers of defense in this job:

find_by instead of find. If the sleep was deleted between the controller and the job execution, I get nil instead of a crash.
Double-check idempotency. Race conditions are real. The controller set the status to in_progress, but I verify again before calling the service.
Graceful recovery. If something explodes — API down, network issue, whatever — I reset the status to not_started so the user can retry. Then I re-raise so the job framework handles its retry logic.

I also put it on a dedicated :sleep_analysis queue. If my app grows and I have other background work, I can control concurrency and priority per queue. Check out the Solid Queue documentation for configuration details.

The Service: My Conversation with Mistral

This is the part I was most excited about — and the most nervous about. I decided to use Net::HTTP from Ruby's stdlib instead of pulling in another gem. For a single API integration, I didn't want the dependency overhead of Faraday or HTTParty.

class SleepAnalysisService < ApplicationService
  def initialize(sleep, locale)
    super()
    @mistral_api_key = ENV.fetch('MISTRAL_API_KEY', nil)
    @mistral_api_url = 'https://api.mistral.ai/v1/chat/completions'
    @sleep = sleep
    @locale = locale
  end

  def call
    response = send_request_to_mistral
    result = parse_response(response) if response.present?
    update_sleep_with_analysis(result) if result.present?
  end

Simple entry point: send, parse, persist. Each step checks the previous one.

Why Mistral and Which Model

I chose Mistral's magistral-small-2509 model. It's fast, cost-effective, and produces quality responses for creative and interpretive tasks. The payload follows their chat completions API:

def build_payload
  {
    model: 'magistral-small-2509',
    response_format: { type: 'text' },
    messages: [
      { role: 'system', content: system_prompt },
      { role: 'user', content: user_prompt }
    ]
  }.to_json
end

Discover the full Mistral API documentation for endpoints, authentication, and more.

The Hardest Part: Prompt Engineering

I'll be honest — I rewrote the system prompt at least five times. The first version produced responses that were too generic. The second was too clinical. I had to find a balance: insightful without being mystical, personal without being presumptuous.

Here's what I ended up with:

def system_prompt
  <<~PROMPT
    You are an expert dream analyst combining psychology, symbolism, and emotional intelligence.
    Your role is to provide structured, insightful dream interpretations that feel personal and meaningful.

    When analyzing a dream, you must:
    - Identify the core narrative and dominant themes
    - Decode symbols and archetypes present in the dream
    - Connect the emotional tone (mood + intensity) to the dream's meaning
    - Consider the sleep type (lucid, nightmare, recurring, etc.) as interpretive context
    - Use the tags as thematic anchors to deepen the analysis
    - Reference the timing ("when") only if it adds contextual relevance

    Structure your response EXACTLY (adapt title to the language
    corresponding to this locale: #{locale}) as follows:

    ##### 🌙 Global interpretation
    A 3-4 sentence synthesis of the dream's overall meaning.

    ##### 🎭 Theme and meaning
    Identify 2-3 key symbols or themes and explain their psychological significance.

    ##### 💭 Emotional dimension
    Analyze how the mood and intensity level shape the dream's message.

    ##### 🔮 Points to consider
    2-3 open-ended questions or reflections.

    Keep the tone warm, insightful, and grounded.
    Respond in the language corresponding to this locale: #{locale}.
  PROMPT
end

What I learned from this:

Structure is everything. By specifying exact markdown headers, my frontend can parse and display sections consistently. Without structure, the response was a wall of text.
Locale in the prompt. I interpolate the locale directly into the system prompt. Mistral handles multilingual output beautifully — I just have to tell it which language.
Tone guardrails. The line "avoid being overly mystical or clinical" was added after I got some really weird responses. Sometimes the AI goes full fortune teller. Sometimes it reads like a medical report. This constraint keeps it in the sweet spot.

The user prompt is simpler — I just assemble all the sleep data into a coherent request:

def user_prompt
  <<~PROMPT
    Please analyze this dream and provide a structured interpretation:

    **Title:** #{sleep.title}
    **Type:** #{sleep.sleep_type}
    **When:** #{sleep.happened}

    **Description:**
    #{sleep.description}

    **Tags:** #{sleep.tags.pluck(:name).join(', ')}
    **Emotional state (current mood):** #{sleep.current_mood}
    **Dream intensity:** #{sleep.intensity}

    Use all of the above attributes in your analysis. The tags, mood,
    and intensity are especially important.
  PROMPT
end

I make sure to pass every attribute — the title, type, when it happened, the full description, the tags, the mood, and the intensity. I specifically call out that tags, mood, and intensity are important because the AI has a tendency to focus only on the description and ignore the metadata.

The HTTP Request

Nothing fancy here — just Net::HTTP with proper error handling:

def send_request_to_mistral
  uri = URI(mistral_api_url)
  http = Net::HTTP.new(uri.host, uri.port)
  http.use_ssl = true

  request = Net::HTTP::Post.new(uri.path, {
    'Content-Type' => 'application/json',
    'Authorization' => "Bearer #{mistral_api_key}"
  })
  request.body = build_payload
  response = http.request(request)

  if response.is_a?(Net::HTTPSuccess)
    response.body
  else
    Rails.logger.error "Failed to get response from Mistral API: #{response.code}"
    sleep.mark_as_analysis_not_started
    nil
  end
rescue StandardError => e
  Rails.logger.error "Error while sending request to Mistral API: #{e.message}"
  sleep.mark_as_analysis_not_started
  nil
end

See the Ruby Net::HTTP documentation for more on HTTP requests in Ruby.

If anything goes wrong — HTTP error, network failure, whatever — I log it, reset the status, and return nil. The caller handles the nil gracefully.

Parsing the Response

def parse_response(raw_response)
  response = JSON.parse(raw_response)
  return response['choices'].first['message']['content'][1]['text'] if response.present?
  nil
end

I'll be honest — this parsing is fragile. The path to the text content depends on Mistral's response structure. If they change their API, this breaks. In a production system at scale, I'd use dig or a response schema validator. For now, it works, and I know exactly where to look if it breaks.

Testing: Because I Don't Want Surprise API Bills

Testing AI integrations is tricky. I don't want to hit the real Mistral API on every test run — that costs money, it's slow, and it's flaky. But I need confidence that my code handles real responses correctly.

VCR to the Rescue

I set up VCR to record real API responses and replay them deterministically:

# spec/support/vcr.rb
VCR.configure do |config|
  config.cassette_library_dir = 'spec/fixtures/vcr_cassettes'
  config.hook_into :webmock
  config.configure_rspec_metadata!
  config.filter_sensitive_data('<MISTRAL_API_KEY>') { ENV['MISTRAL_API_KEY'] }
end

That filter_sensitive_data line is crucial — it replaces my actual API key in the cassette files so I never accidentally commit it. Combined with WebMock, VCR intercepts all HTTP requests during tests.

Then in my service spec:

describe SleepAnalysisService do
  let(:sleep) { create(:sleep, :with_tags) }
  let(:locale) { 'en' }

  describe '#call' do
    it 'analyzes the sleep and persists the result' do
      VCR.use_cassette('sleep_analysis_service/success') do
        service = described_class.call(sleep, locale)

        expect(sleep.reload.analysis).to be_present
        expect(sleep.analysis_status).to eq('done')
      end
    end
  end
end

The first time I run this, VCR hits the real Mistral API and records the response. Every time after that, it replays the cassette. Fast, deterministic, free.

Testing the Job

The job spec verifies idempotency and error recovery:

describe SleepAnalyseJob do
  let(:sleep) { create(:sleep) }

  it 'enqueues the job' do
    expect {
      described_class.perform_later(sleep.id, 'en')
    }.to have_enqueued_job.on_queue('sleep_analysis')
  end

  it 'does not analyze if already done' do
    sleep.mark_as_analysis_done('existing analysis')
    expect(SleepAnalysisService).not_to receive(:call)
    described_class.perform_now(sleep.id, 'en')
  end
end

Testing the Endpoint

And at the request level, I verify the idempotency guard actually works:

describe 'POST /api/v1/sleeps/:id/analyse' do
  context 'when analysis is already done' do
    before { sleep.mark_as_analysis_done('analysis text') }

    it 'returns ok with appropriate message' do
      post analyse_api_v1_sleep_path(sleep)
      expect(response).to have_http_status(:ok)
      expect(json_response['code']).to eq('analysis_already_in_progress_or_done')
    end
  end
end

What I Learned Along the Way

Prompt Engineering Is Iterative

I can't stress this enough. The system prompt went through at least five revisions. Each one got better, but I had to actually read the AI outputs and notice patterns: too vague, too clinical, ignoring the tags, wrong language. Only by iterating on real outputs did I get something that felt right.

Status Machines Save You From Yourself

The three-state enum combined with double-checks at both the controller and job level — that saved me from bugs I didn't even know I was going to have. Race conditions, retries, duplicate requests — they all get handled gracefully because I thought about failure modes upfront.

VCR Is Worth the Setup Time

Recording API responses once and replaying them forever is a superpower. My test suite runs fast, I never worry about API rate limits, and I'm not burning through credits on every CI run.

Always Reset on Failure

Early in development, I had a bug where a failed API call left the status stuck at in_progress. The user couldn't retry. The analysis was orphaned. That's when I added the mark_as_analysis_not_started calls in every error path. Defensive coding isn't paranoia — it's experience.

Less Is More for Dependencies

I could have added Faraday or HTTParty or a dedicated Mistral SDK. Instead, I used Net::HTTP and it works fine. The code is a bit more verbose, but I have one fewer gem to maintain and one fewer dependency to audit.

Final Thoughts

Building this feature was a great exercise in wrapping something inherently unpredictable — an AI API call — in predictable, well-tested infrastructure. The Mistral integration itself is maybe 30% of the work. The other 70% is status tracking, background jobs, error recovery, idempotency, and testing.

That's the part I'm most proud of: not that I called an AI API, but that I built a system around it that's resilient enough to run in production without me babysitting it.

If you're building something similar, my advice is: spend more time on the plumbing than on the prompt. A good prompt with bad error handling will fail silently. A mediocre prompt with great error handling will at least fail gracefully — and you'll have the logs to fix the prompt later.

You can check out the full implementation in the Pull Request on GitHub.

Introducing Squidly: Simplify Your GitHub Workflow Management

François — Fri, 24 Jan 2025 12:57:22 +0000

Hello, Dev.to community! 🚀

I'm excited to introduce you to Squidly (beta), a SaaS platform designed to streamline your GitHub workflow management. Whether you're a solo developer or part of a larger team, Squidly offers a comprehensive suite of features to help you manage, monitor, and gain insights into your GitHub workflows—all in one place.

🚧 Note: the platform is in Beta stage, server can make from 30 seconds to 1 minute to be up and ready.

Why Squidly?

Managing multiple GitHub workflows can be challenging, especially when you're juggling various projects. Squidly aims to simplify this process by providing a centralized dashboard where you can visualize and control your workflows efficiently.

Key Features

Dashboard Overview: Get a quick overview of all your GitHub workflows. Monitor their status, view statistics, and manage them with ease.
Repository Management: Add or remove repositories directly from Squidly. Gain insights into your workflows and manage them without leaving the platform.
Workflow Control: View all your workflows and their statuses. Re-run or cancel workflows directly from the list.
Billing Usage Recap: For premium users, Squidly provides a detailed billing usage recap, helping you keep track of your workflow usage.

More details is on the pricing section: Squidly

Pricing Plans

Squidly is currently in beta and free to use. We offer a Free Plan for small projects and a Premium Plan for developers who need more advanced features. A Teams Plan is also in the works for enterprise users.

How to Test

To test Squidly, navigate to the relevant sections of the app and explore the features. Our intuitive interface makes it easy to get up and running quickly.

Join Our Community

We'd love for you to join our growing community of developers. Follow us on Twitter for updates, or reach out through our contact form if you have any questions.

Thank you for taking the time to learn about Squidly. We hope it becomes an invaluable tool in your development workflow.

You can try the tool directly in Beta environment (All data will be deleted at the end of Beta testing).

Squidly - All your Github workflows in one place

Happy coding! 🎉

Question - Tools to see differences between JS frameworks

François — Thu, 30 Mar 2023 14:01:55 +0000

Hi developers! 👋

Do you have any tools to see the difference in terms of code between different frontend frameworks?
For example, difference to declare a props, events, ...

Thanks a lot 🙏

ReactJS vs Vue.js - Feedback about two long-term projects

François — Wed, 30 Mar 2022 13:33:55 +0000

I don't think it is really useful to introduce these two frameworks/libraries since you probably already know them. If it is not the case, you can find a quick introduction on those links ReactJS/Vue.js.

Here is a graph of their evolution in terms of Github stars from 2014 to today 📊.

Number of stars on GitHub projects React and Vue (source: https://star-history.t9t.io/#facebook/react&vuejs/vue&angular)

As a comparison, the most starred repository on GitHub is FreeCodeCamp, with over 340k stars 🌟 . It is an open source project with a large codebase and a friendly community where you can learn to code for free with over 8,000 tutorials.

In this article, I will give you my feedback on the use of these 2 frameworks through two projects at Kinoba 💛

DISCLAIMER

The projects I will be talking about started in 2020 and are part of my discovery and learning of main frontend frameworks. I deliberately did not go into advanced technical details to make it accessible to beginners, tech lovers and also experienced developers. Today, I'm working with these two amazing frameworks in my daily life 🙌 .

Vue.js

First steps in front-end frameworks with Vue

My first Vue.js project at Kinoba was made with the Highday project. This platform allows you to describe your professional life in synthetic, graphic and contemporary formats, to share with your community.

The technical stack used is Vue for the front-end and Ruby On Rails for the back-end.

I think that these 2 technologies work really well together: development is super smooth, Vue is intuitive and the learning curve is awesome.

The choice of the framework for this project was mainly made thanks to the growth of Vue, its simplicity of understanding, its lightness compared to others and its growing community. Others criteria came into consideration, such as the possibility to install the app in PWA mode on mobile or desktop devices.

What I appreciated during the development

⚙️ The principle of the "single file component" is useful: it allows you to keep all the code related to a component in one place, so it is easier to organize your project. And you don't end up with styles from one component overwriting the styles of another component.
📚 The documentation is great
🤩 Quick and easy PWA setup
🏢 Vue was not created by a big company like Facebook or Google.
📦 Packages are awesome!

Examples of packages used

While working on the project, the latest version of Vue (Vue 3) had just been released (Evan You 💚️), with lots of new features. I am already looking forward to start a new project with this new version. 🤩

React

First steps with React
The second framework I learned is React, thanks to an event platform.

Unlike the project with Vue, this one required the use of React because the project integrated massive rendering and performance issues. We needed a more complete and robust framework and React turned out to be a perfect fit for this type of project.

We also implemented a custom chat made with actioncable and a custom backoffice for event administrators.

What I appreciated during the development

🤓 Learning a "new language", JSX.
⚙️ We used the "Class Component" system (I have not used the "Functionnal Component" yet so I have no hindsight on this point)
📣 The massive React community
💪 The stability of the library

Examples of packages used

Next time, I hope to be able to test how Functionnal Component works to see the different aspects of using React. I have also heard a lot about Next.js or React Native from several friends, they sound pretty cool 😎

Simple code examples between Vue.js and React

Loops

Loop in React

Loop in Vue.js

I find it so much easier in Vue.

Reading the code becomes quite complicated when you have multiple loops in React. The syntax is too heavy in my opinion.

Conditions

Condition in React

Condition in Vue.js

Same thing for the conditions, I find React's JSX pretty heavy and if there are too many conditions so it quickly becomes unmaintainable over time.

To conclude…

The learning of the two frameworks was done without too many worries but which one do you think I prefer? 😉

Because of my knowledge of Vue, I did not have too many learning issues with React, and for any problem I had my colleagues as a backup 💪. This is a personal opinion but I prefer to use Vue.js for all the points I mentioned above.

JSX complicates a little bit the readability of the code but it is useful not to have an html, css and a separate javascript file.

Having a separate stylesheet is not so annoying, we still manage to organize ourselves even if some styles may overwrite styles of other components.

In my future personal projects, I would also like to learn the Svelte.js framework which, as its name suggests, greatly reduces the weight of the application once compiled. Indeed, the virtual DOM is not present, which is one less thing to load 🚀. It promises better loading speed compared to other frameworks and as web developers we are always looking for better performance. So, I think Svelte can be interesting in that regard and its popularity keeps increasing.

👋 See you soon @Kinoba

Se reconvertir dans le développement web 👩‍💻👨‍💻

François — Fri, 04 Feb 2022 09:54:14 +0000

Viens découvrir les premiers articles de notre série d'interviews au format court sur la reconversion dans le développement web.

Chez Kinoba, nous avons des profils très différents. Six membres de l’équipe se sont reconvertis dans le développement web après s’être essayés à des métiers divers et variés. Ils témoignent de leur reconversion dans cette série d’interviews au format court :

Et toi, comment as-tu vécu ta reconversion ? ⬇️ ⬇️ ⬇️

3 ways to send emails with only few lines of code and Gmail - Python - Part 3

François — Mon, 28 Jun 2021 14:01:51 +0000

We will see how to send a simple email with the help of three different programming languages: Javascript, Ruby and Python
Before you start you need to create a Gmail account.
Do not forget to accept and allow the "Less secure apps" access in order use your scripts with your Gmail smtp connection.
I'll let you do this on your own, you don't need a tutorial for this 😜

Python 🐍

We are going to use the Smtplib and the MIMEMultipart libraries:

import smtplib
from email.mime.multipart import MIMEMultipart
from email.mime.text import MIMEText

Define Gmail account info and recipient email:

# The email addresses and password
sender_address = 'youremail@gmail.com'
sender_password = 'yourpassword'
gmail_port = 587

receiver_address = 'myfriend@yopmail.com'
mail_content = 'Easy peazy lemon squeezy'

Setup the MIME:

message = MIMEMultipart()
message['From'] = sender_address
message['To'] = receiver_address
message['Subject'] = 'Sending email using Python'
message.attach(MIMEText(mail_content, 'plain'))

Create SMTP session for sending the mail:

session = smtplib.SMTP('smtp.gmail.com', gmail_port)
session.starttls() # enable security
session.login(sender_address, sender_password)
text = message.as_string()
session.sendmail(sender_address, receiver_address, text)
session.quit()

print('Email Sent')

Here the final code:

import smtplib

from email.mime.multipart import MIMEMultipart
from email.mime.text import MIMEText

# The email addresses and password
sender_address = 'youremail@gmail.com'
sender_password = 'yourpassword'
gmail_port = 587

receiver_address = 'myfriend@yopmail.com'
mail_content = 'Easy peezy lemon squeezy'

# Setup the MIME
message = MIMEMultipart()
message['From'] = sender_address
message['To'] = receiver_address
message['Subject'] = 'Sending email using Python'

# The body and the attachments for the mail
message.attach(MIMEText(mail_content, 'plain'))

# Create SMTP session for sending the mail
session = smtplib.SMTP('smtp.gmail.com', gmail_port)
session.starttls() # enable security
session.login(sender_address, sender_password)
text = message.as_string()
session.sendmail(sender_address, receiver_address, text)
session.quit()

print('Email Sent')

The power of Python 🐍

What's next?

With those scripts, we went through the basics of the module, gem and library (read the docs 📚) but you can also do amazing things with them like loops, sending attachments, automated things... feel free to do want you want.

Thanks for reading this tiny scripts serie 😊
See you soon @Kinoba

3 ways to send emails with only few lines of code and Gmail - Ruby - Part 2

François — Mon, 21 Jun 2021 11:48:01 +0000

Ruby 💎

We are going to use the Mail gem:

gem install mail

Require it at the beginning of your send_email.rb:

require 'mail'

Declare Gmail account info:

# Gmail account info
options = {
  address: 'smtp.gmail.com',
  port: 587, # gmail smtp port number
  domain: 'gmail.com',
  user_name: 'youremail@gmail.com',
  password: 'yourpassword',
  authentication: 'plain'
}

Initialize Mail delivery_method info:

Mail.defaults do
  delivery_method :smtp, options
end

Send email 📧 :

Mail.deliver do
  to 'myfriend@yopmail.com'
  from 'youremail@gmail.com'
  subject 'Sending email using Ruby'
  body 'Easy peasy lemon squeezy'
end

Here the final code:

require 'mail'

# Gmail account info
options = {
  address: 'smtp.gmail.com',
  port: 587,
  domain: 'gmail.com',
  user_name: 'youremail@gmail.com',
  password: 'yourpassword',
  authentication: 'plain'
}

Mail.defaults do
  delivery_method :smtp, options
end

Mail.deliver do
  to 'myfriend@yopmail.com'
  from 'youremail@gmail.com'
  subject 'Sending email using Ruby'
  body 'Easy peasy lemon squeezy'
end

puts 'Email sent'

The ease of Ruby 💎

3 ways to send emails with only few lines of code and Gmail - Javascript - Part 1

François — Mon, 14 Jun 2021 10:05:45 +0000

Javascript 🚀

For the first script, we are going to use the Nodemailer module:

yarn add nodemailer

Require or import the module into your index.js:

const nodemailer = require('nodemailer')

Initialize the mailer with our Gmail account info:

// Gmail account info
const transporter = nodemailer.createTransport({
  service: 'gmail',
  auth: {
    user: 'youremail@gmail.com',
    pass: 'yourpassword'
  }
});

Create your email:

// Email info
const mailOptions = {
  from: 'youremail@gmail.com',
  to: 'myfriend@yopmail.com',
  subject: 'Sending email using Node.js',
  text: 'Easy peasy lemon squeezy'
};

Sending your email:

// Send email and retrieve server response
transporter.sendMail(mailOptions, function(error, info){
  if (error) {
    console.log(error);
  } else {
    console.log('Email sent: ' + info.response);
  }
});

Here the final code:

const nodemailer = require('nodemailer')

// Gmail account info
const transporter = nodemailer.createTransport({
  service: 'gmail',
  auth: {
    user: 'youremail@gmail.com',
    pass: 'yourpassword'
  }
});

// Email info
const mailOptions = {
  from: 'youremail@gmail.com',
  to: 'myfriend@yopmail.com',
  subject: 'Sending email using Node.js',
  text: 'Easy peasy lemon squeezy'
};

// Send email 📧  and retrieve server response
transporter.sendMail(mailOptions, function(error, info){
  if (error) {
    console.log(error);
  } else {
    console.log('Email sent: ' + info.response);
  }
});

Javascript buddy 🤝

Javascript 🚀 - Part 1
Ruby 💎 - Part 2
Python 🐍 - Part 3

3 ways to send emails with only few lines of code and Gmail - Series

François — Fri, 11 Jun 2021 11:56:07 +0000

Table of teasing

Configure Scaleway S3 for Active Storage in Rails 6.0

François — Fri, 26 Mar 2021 08:20:08 +0000

Scaleway is a French web hosting company, founded by Xavier Niel in 1999. It provides physical and online dedicated servers, domain registration services and datacenters.

In 2020, Scaleway was the second player in France behind OVHCloud and the third in Europe.

If you want an alternative to Amazon AWS S3 storage services that we use @Kinoba, follow along this tiny and easy tutorial 😊

Scaleway part

Let's begin with the Scaleway config 👨🏻‍🔧

1️⃣ First step: Create an account on Scaleway Elements:

👉🏻 https://www.scaleway.com/fr/object-storage/

2️⃣ Second step: Create your S3 bucket by going to your Scaleway console and "Object Storage" tab.

Here, a help procedure if needed:
👉🏻 https://www.scaleway.com/en/docs/object-storage-feature/#-Operation-Procedures

3️⃣ Third step: Generate your Access key and your Secret key 🔐 (do not forget to store them somewhere like 1Password or Bitwarden for example):

👉🏻 https://www.scaleway.com/en/docs/generate-api-keys/

Ruby On Rails part

The funniest part: integrating Scaleway into your Rails app 👩🏽‍💻

After installing ActiveStorage and creating the active_storage_tables migration, you can add the "aws-sdk-s3" gem to your Gemfile

# Gemfile
gem 'aws-sdk-s3', require: false

Then, you can add your credentials to your .env file (do not forget to add your file to your .gitignore)

# .env
SCALEWAY_ACCESS_KEY_ID=YOUR_ACCESS_KEY_ID
SCALEWAY_SECRET_ACCESS_KEY_ID=YOUR_SECRET_ACCESS_KEY_ID
SCALEWAY_BUCKET_NAME=YOUR_BUCKET_NAME

Add this config to you storage.yml with your personal keys and bucket

# storage.yml
test:
  service: Disk
  root: <%= Rails.root.join("tmp/storage") %>

local:
  service: Disk
  root: <%= Rails.root.join("storage") %>

scaleway:
  service: S3
  endpoint: https://s3.fr-par.scw.cloud # Scaleway API endpoint, depending on your region
  access_key_id: <%= ENV['SCALEWAY_ACCESS_KEY_ID'] %> # Do not forget to hide your secrets
  secret_access_key: <%= ENV['SCALEWAY_SECRET_ACCESS_KEY_ID'] %> # Do not forget to hide your secrets
  region: fr-par # Your bucket region, here it's Paris
  bucket: <%= ENV['SCALEWAY_BUCKET_NAME'] %> # Your bucket name

Do not forget to tell Rails to use Scaleway storage in production environment

# production.rb
config.active_storage.service = :scaleway

Finally, you can attach your files to your records as usual 🙌🏻

# user.rb
has_one_attached :avatar

# users_controller.rb
@user.avatar.attach(params[:avatar])

That's it 🎉

Check it out on Medium

François Loupias - Fullstack web developer @Kinoba

DEV Community: François

Building AI-Powered Dream Analysis with Mistral AI in My Rails API

What I Wanted

The Architecture I Settled On

First Problem: How Do I Track the Analysis Lifecycle?

The Controller: Idempotency Is My Obsession

Solid Queue for Background Processing

The Service: My Conversation with Mistral

Why Mistral and Which Model

The Hardest Part: Prompt Engineering

The HTTP Request

Parsing the Response

Testing: Because I Don't Want Surprise API Bills

VCR to the Rescue

Testing the Job

Testing the Endpoint

What I Learned Along the Way

Prompt Engineering Is Iterative

Status Machines Save You From Yourself

VCR Is Worth the Setup Time

Always Reset on Failure

Less Is More for Dependencies

Final Thoughts

Introducing Squidly: Simplify Your GitHub Workflow Management

Why Squidly?

Key Features

Pricing Plans

How to Test

Join Our Community

Question - Tools to see differences between JS frameworks

ReactJS vs Vue.js - Feedback about two long-term projects

DISCLAIMER

Vue.js

React

Simple code examples between Vue.js and React

To conclude…

Se reconvertir dans le développement web 👩‍💻👨‍💻

3 ways to send emails with only few lines of code and Gmail - Python - Part 3

Python 🐍

The power of Python 🐍

What's next?

Table of contents

3 ways to send emails with only few lines of code and Gmail - Ruby - Part 2

Ruby 💎

The ease of Ruby 💎

Table of contents

3 ways to send emails with only few lines of code and Gmail - Javascript - Part 1

Javascript 🚀

Javascript buddy 🤝

Table of contents

3 ways to send emails with only few lines of code and Gmail - Series

Table of teasing

Configure Scaleway S3 for Active Storage in Rails 6.0

Scaleway part

Ruby On Rails part

That's it 🎉