DEV Community: Lucas Draney

Streamline Your Development with This Awesome Docker Command

Lucas Draney — Sat, 21 Sep 2024 18:31:37 +0000

Streamline Your Development with This Awesome Docker Command

If you're tired of juggling multiple terminal windows for building, running, and cleaning up Docker containers, this one's for you!

The Magic Command

docker run --rm -v ${PWD}:/usr/src/app -itp 8080:8080 $(docker build -q -f Dockerfile.dev .)

Let's break down why this command is so awesome for developing new projects:

One-liner Wonder: This single command builds your image, runs a container, and sets up everything you need for development.
Clean Slate Every Time: The --rm flag ensures that the container is removed when it stops. No more cluttered Docker environments!
Real-time Code Updates: The -v ${PWD}:/usr/src/app part mounts your current directory into the container. This means you can edit your code locally, and the changes are immediately reflected in the running container.
Interactive Development: The -it flags keep the container running and allow you to interact with it, perfect for debugging or running additional commands.
Accessible from Your Browser: With -p 8080:8080, you're mapping the container's port 8080 to your host's port 8080. Just open localhost:8080 in your browser to see your app in action.
Dockerfile Flexibility: The -f Dockerfile.dev allows you to specify a development-specific Dockerfile, keeping your production builds separate.
No Image Clutter: By using $(docker build -q ...), we're building the image on-the-fly without saving it. This keeps your local Docker images list clean.

How It Works

This command assumes you're in the project directory. It uses ${PWD} (present working directory) to mount your local files into the container. This means all your project files are accessible inside the container, and any changes you make locally are immediately reflected in the running app.

Let's Test It Out!

To see this in action, let's create a simple Node.js application and use our awesome Docker command to run it.

Create a new directory for your project:

mkdir docker-dev-demo
cd docker-dev-demo

Create a simple index.js file:

const express = require('express');
const app = express();
const port = 8080;

app.get('/', (req, res) => {
  res.send('Hello from Docker!');
});

app.listen(port, () => {
  console.log(`App listening at http://localhost:${port}`);
});

Create a package.json file:

{
  "name": "docker-dev-demo",
  "version": "1.0.0",
  "main": "index.js",
  "dependencies": {
    "express": "^4.17.1"
  },
  "scripts": {
    "start": "node index.js"
  }
}

Now, let's create our Dockerfile.dev:

FROM node:14

WORKDIR /usr/src/app

COPY package*.json ./

RUN npm install

COPY . .

EXPOSE 8080

CMD ["npm", "start"]

Finally, run our magic command:

docker run --rm -v ${PWD}:/usr/src/app -itp 8080:8080 $(docker build -q -f Dockerfile.dev .)

You should see your app running, and if you make changes to index.js, they'll be reflected immediately without needing to rebuild or restart the container!

Conclusion

This Docker command is a powerful tool for streamlining your development workflow. It combines building, running, and cleaning up into a single, easy-to-use command. Give it a try in your next project and see how it can speed up your development process!

Happy coding! 🚀

docker #webdev #javascript #productivity

Avoid cloud providers when you can

Lucas Draney — Thu, 19 Sep 2024 17:18:21 +0000

Avoid cloud providers when you can;
Or, at least, don't be cloud-dependent.

Businesses should aim to own their own infrastructure.
Aim to only use the cloud for temporary scaling or development needs.
Aim for self-hosting, private cloud projects.
Cloud "serverless" frameworks are often convenient;
but are ultimately expensive and stifling to iteration,
especially for businesses expanding their teams,
but also for many startups and one-man-band devs.

Aim for open-source.
Aim to build your MVP cloud-natively.
Containerization is where it starts.
For example, set up your frontend:

 docker run --rm -v ${PWD}:/app -w /app \
 node:bookworm \
 npx create-next-app@latest . \
 --typescript \
 --eslint \
 --tailwind \
 --app \
 --src-dir \
 --import-alias "@/*"

Then set up your backend:

docker run --rm -v ${PWD}:/app -w /app ruby:bookworm \
 bash -c "gem install rails && \
 rails new backend \
 --api \
 --database=postgresql \
 --skip-javascript \
 --skip-asset-pipeline \
 --skip-sprockets \
 --skip-action-cable \
 --skip-action-mailbox \
 --skip-action-text \
 --name=backend"

Set up your Dockerfiles;
then authentication, fullstack routes and integrations;
then pipelines, secure hosting, and observability.
Manage your own data and tech stack - work within your own timelines
Limit your external dependencies, vulnerabilities, and tech debt distractions

For a scalable, feature-focused, maintainable application,
Avoid cloud-dependency.

DevOps - Mastery Meets Obsolescence

Lucas Draney — Tue, 17 Sep 2024 23:01:51 +0000

Imagine for a moment that you're a DevOps engineer. You've just hit your five-year work anniversary, and according to the famous 10,000-hour rule, you should be on the cusp of mastery. But as you survey the ever-changing landscape of cloud technologies, containerization, and automation tools, you can't help but wonder: Am I really a master, or am I perpetually a student?

This is the DevOps Paradox – a phenomenon where the pursuit of mastery collides head-on with the relentless pace of technological change.

Let's break it down:

The conventional wisdom, popularized by Malcolm Gladwell, suggests that 10,000 hours of deliberate practice leads to mastery in any field. For a DevOps professional working a standard 40-hour week, that translates to about five years of focused work. It's a comforting thought – put in your time, and expertise will follow.

But here's where it gets interesting.

In those same five years, consider what's happened in the DevOps world. Kubernetes went from a niche technology to an industry standard. Serverless architectures evolved from a novel concept to a mainstream approach. AI and machine learning have begun to revolutionize operations and monitoring.

So, our hypothetical DevOps engineer finds themselves in a curious position. They've accumulated their 10,000 hours, but a significant portion of what they mastered in the early years may now be outdated. They're simultaneously an expert and a novice, a master of yesterday's tools and a beginner with tomorrow's technologies.

This paradox reveals something profound about the nature of expertise in rapidly evolving fields. Perhaps we need to rethink what mastery means in the context of DevOps and similar disciplines.

What if, instead of a destination, we viewed mastery as a state of perpetual adaptation? In this paradigm, the true DevOps master isn't someone who knows everything, but someone who has mastered the art of learning itself. They're not defined by their knowledge of specific tools, but by their ability to quickly understand and implement new technologies as they emerge.

This shift in perspective has fascinating implications:

The "10,000-Hour Rule" becomes more of a starting point than an end goal. It's the base from which true adaptive expertise can grow.
Continuous learning isn't just a buzzword, but the very essence of mastery in fields like DevOps.
Soft skills like adaptability, critical thinking, and learning agility become as crucial as technical knowledge – if not more so.
The industry's rapid pace, often seen as a challenge, becomes an opportunity for those who can ride the wave of change.

So, the next time you update your LinkedIn profile or sit for a job interview, consider this: Your greatest asset might not be the list of technologies you've mastered, but your proven ability to master new technologies. In the world of DevOps, the real experts are those who have embraced the paradox, finding comfort in the uncomfortable state of constant learning.

As we navigate this new understanding of expertise, we're left with intriguing questions: How do we measure this new form of mastery? How do we train for it? And perhaps most importantly, how do we build organizations that not only adapt to change but thrive on it?

What are your thoughts? Have you experienced the DevOps Paradox in your career? How do you balance the need for deep expertise with the imperative of continuous learning?

DevOps #ContinuousLearning #TechEvolution #CareerDevelopment