Forem: Aleksei Borovikov

The Unstoppable Rise of AI: Key Takeaways from IBM’s AI Course

Aleksei Borovikov — Fri, 07 Feb 2025 16:27:35 +0000

I recently completed IBM’s Introduction to AI course, which reinforced a simple truth—AI is becoming a core part of how we work and live. While many are aware that AI powers chatbots, recommendations, and automation, what stood out to me was its shift toward more adaptive and multimodal systems that process different types of data together.

Machine learning goes beyond training models; ensuring they perform reliably in real-world scenarios requires careful validation. The way data is split into training, validation, and test sets may seem straightforward, but it plays a crucial role in making AI effective. Generative AI, meanwhile, is reshaping industries by creating realistic videos, personalizing customer experiences, and assisting in medical research.

Another key takeaway was how AI interacts with other technologies like IoT, cloud computing, and edge computing. These connections are already optimizing logistics, shaping smart cities, and improving real-time decision-making in ways we don’t always notice.

Ethics and governance were also a major focus. AI has massive potential, but without fairness, transparency, and oversight, it can reinforce biases or create security risks. Companies are taking this seriously, with frameworks like IBM’s pillars of trust and regulations like the EU AI Act shaping the way forward.

AI adoption isn’t optional anymore—it’s happening everywhere. The real challenge is using it wisely to enhance human capabilities rather than replace them. This course reinforced my commitment to exploring AI’s possibilities and challenges even further.

Learning from Code Reviews: Fostering Collaboration

Aleksei Borovikov — Fri, 07 Jun 2024 23:52:22 +0000

Just finished watching a presentation by Derrick Pryor about making code reviews more effective. Who knew they were about more than just catching bugs? Apparently, a good code review culture can be a game-changer for learning and teamwork.

Here's the big takeaway for me: it's all about clear communication.

Authors gotta set the stage. Before hitting that submit button, gotta explain why the code changed. This way, reviewers can understand the "what" and "why" behind the code and give better feedback.
Reviewers: question, not criticize. Instead of just pointing out problems, asking questions helps the author understand the reasoning and learn from it. Makes the whole thing more of a conversation than a one-sided critique.

This makes me think about code reviews differently. It's not about people finding mistakes in my code. It's a chance to learn from my teammates and become a better developer.

Also, the presentation covered some other cool stuff like dealing with merge conflicts (yikes!) and asynchronous reviews (reviews that happen over time, not all at once). Definitely some things to keep in mind as I keep coding!

Database design

Aleksei Borovikov — Fri, 31 May 2024 17:02:01 +0000

In database design, handling many-to-many relationships typically requires a third table, often called a join table or a junction table. This table records the associations between the two other tables. In contrast, for one-to-many relationships, you do not need a third table. Instead, you usually add a foreign key column in the table that represents the “many” side of the relationship.

Many-to-Many Relationship Example

Suppose you have students and courses tables, where each student can enroll in many courses, and each course can have many students. To model this relationship, you would create a third table, often named enrollments. This join table would include foreign keys referencing the primary keys of the students and courses tables.

class Student < ActiveRecord::Base
  has_many :enrollments
  has_many :courses, through: :enrollments
end

class Course < ActiveRecord::Base
  has_many :enrollments
  has_many :students, through: :enrollments
end

class Enrollment < ActiveRecord::Base
  belongs_to :student
  belongs_to :course
end

One-to-Many Relationship Example

Suppose you have authors and books tables, where each author can write many books, but each book is written by only one author. In this case, you would add a foreign key column to the books table to reference the authors table.

class Author < ActiveRecord::Base
  has_many :books
end

class Book < ActiveRecord::Base
  belongs_to :author
end

In summary, a third table is necessary for many-to-many relationships but not for one-to-many relationships.