Discussing language constructs with fellow developers in the context of solving a particular problem is something we do routinely. While most such conversations are productive and useful, a fair portion degenerate into angry brawls. A pattern we've observed in the latter situation is that a surprising number of times the argument is that "Why shouldn't I use language feature X to achieve objective Y- after all, the language supports X."
In this talk Aakash and Niranjan walk through a few features of the Ruby language which when used wisely allows programmers to solve problems elegantly but if they are used without caution can lead to bad code.
Talk presented to High School students at the Utah DigiForge Student Conference: "Think Like A Programmer". (Attributes: Laziness, Impatience, Hubris. And how algorithms, abstraction, and generalization will help you to achieve those attributes.)
Talk presented to High School students at the Utah DigiForge Student Conference: "Think Like A Programmer". (Attributes: Laziness, Impatience, Hubris. And how algorithms, abstraction, and generalization will help you to achieve those attributes.)
Learn Ruby 2011 - Session 5 - Looking for a RescueJames Thompson
In this final language-focussed session we covered the three kinds of blocks used in Ruby: blocks, Procs and lambdas. We also covered error/exception handling in Ruby and reviewed iteration mechanisms.
Introduction to writing readable and maintainable PerlAlex Balhatchet
An introduction to writing readable Perl code, for people who write Perl that other people may want to read. Covers the most important lessons from Perl Best Practices, and ends by showing how to use Perl::Critic to test that you are meeting the standards set out.
Given at FOSDEM 2011
What You Need to Know About Lambdas - Jamie Allen (Typesafe)jaxLondonConference
Presented as a keynote at JAX London 2013
Lambdas are coming to the Java language in the upcoming release of Java 8! While this is generally great news, many Java developers have never experienced Lambdas before, and have not yet learned the best ways to use them for maximum productivity. In this talk, we will discuss best practices for using Lambdas in Java and other JVM-based languages, and we will investigate how we can make these constructs more usable in production.
One of the advantages of learning a new language is being exposed to new idioms and new approaches to solving old problems. In this talk, we will introduce the Ruby language with particular focus on the idioms and concepts that are different from what is found in Java.
We will introduce concepts such as closures, continuations and meta programming. We will also examine powerful techniques that are practically impossible in Java due to its compile time binding of types.
No experience with Ruby is assumed although an understanding of Java would be helpful.
This talk was given at the Toronto Java Users Group in April 2008
These are slides from a lecture on Red Flags in Programming that took place at an Israeli Open Source Developers meeting.
Red flags in programming are signs that you likely made a mistake with your application design or code.
Noticing and avoiding these mistakes help us write better code, at any language.
The subject related to mostly dynamic (higher level) languages, even though the sample code is in Perl.
Learn Ruby 2011 - Session 5 - Looking for a RescueJames Thompson
In this final language-focussed session we covered the three kinds of blocks used in Ruby: blocks, Procs and lambdas. We also covered error/exception handling in Ruby and reviewed iteration mechanisms.
Introduction to writing readable and maintainable PerlAlex Balhatchet
An introduction to writing readable Perl code, for people who write Perl that other people may want to read. Covers the most important lessons from Perl Best Practices, and ends by showing how to use Perl::Critic to test that you are meeting the standards set out.
Given at FOSDEM 2011
What You Need to Know About Lambdas - Jamie Allen (Typesafe)jaxLondonConference
Presented as a keynote at JAX London 2013
Lambdas are coming to the Java language in the upcoming release of Java 8! While this is generally great news, many Java developers have never experienced Lambdas before, and have not yet learned the best ways to use them for maximum productivity. In this talk, we will discuss best practices for using Lambdas in Java and other JVM-based languages, and we will investigate how we can make these constructs more usable in production.
One of the advantages of learning a new language is being exposed to new idioms and new approaches to solving old problems. In this talk, we will introduce the Ruby language with particular focus on the idioms and concepts that are different from what is found in Java.
We will introduce concepts such as closures, continuations and meta programming. We will also examine powerful techniques that are practically impossible in Java due to its compile time binding of types.
No experience with Ruby is assumed although an understanding of Java would be helpful.
This talk was given at the Toronto Java Users Group in April 2008
These are slides from a lecture on Red Flags in Programming that took place at an Israeli Open Source Developers meeting.
Red flags in programming are signs that you likely made a mistake with your application design or code.
Noticing and avoiding these mistakes help us write better code, at any language.
The subject related to mostly dynamic (higher level) languages, even though the sample code is in Perl.
Transcript: Selling digital books in 2024: Insights from industry leaders - T...BookNet Canada
The publishing industry has been selling digital audiobooks and ebooks for over a decade and has found its groove. What’s changed? What has stayed the same? Where do we go from here? Join a group of leading sales peers from across the industry for a conversation about the lessons learned since the popularization of digital books, best practices, digital book supply chain management, and more.
Link to video recording: https://bnctechforum.ca/sessions/selling-digital-books-in-2024-insights-from-industry-leaders/
Presented by BookNet Canada on May 28, 2024, with support from the Department of Canadian Heritage.
GraphRAG is All You need? LLM & Knowledge GraphGuy Korland
Guy Korland, CEO and Co-founder of FalkorDB, will review two articles on the integration of language models with knowledge graphs.
1. Unifying Large Language Models and Knowledge Graphs: A Roadmap.
https://arxiv.org/abs/2306.08302
2. Microsoft Research's GraphRAG paper and a review paper on various uses of knowledge graphs:
https://www.microsoft.com/en-us/research/blog/graphrag-unlocking-llm-discovery-on-narrative-private-data/
Alt. GDG Cloud Southlake #33: Boule & Rebala: Effective AppSec in SDLC using ...James Anderson
Effective Application Security in Software Delivery lifecycle using Deployment Firewall and DBOM
The modern software delivery process (or the CI/CD process) includes many tools, distributed teams, open-source code, and cloud platforms. Constant focus on speed to release software to market, along with the traditional slow and manual security checks has caused gaps in continuous security as an important piece in the software supply chain. Today organizations feel more susceptible to external and internal cyber threats due to the vast attack surface in their applications supply chain and the lack of end-to-end governance and risk management.
The software team must secure its software delivery process to avoid vulnerability and security breaches. This needs to be achieved with existing tool chains and without extensive rework of the delivery processes. This talk will present strategies and techniques for providing visibility into the true risk of the existing vulnerabilities, preventing the introduction of security issues in the software, resolving vulnerabilities in production environments quickly, and capturing the deployment bill of materials (DBOM).
Speakers:
Bob Boule
Robert Boule is a technology enthusiast with PASSION for technology and making things work along with a knack for helping others understand how things work. He comes with around 20 years of solution engineering experience in application security, software continuous delivery, and SaaS platforms. He is known for his dynamic presentations in CI/CD and application security integrated in software delivery lifecycle.
Gopinath Rebala
Gopinath Rebala is the CTO of OpsMx, where he has overall responsibility for the machine learning and data processing architectures for Secure Software Delivery. Gopi also has a strong connection with our customers, leading design and architecture for strategic implementations. Gopi is a frequent speaker and well-known leader in continuous delivery and integrating security into software delivery.
Climate Impact of Software Testing at Nordic Testing DaysKari Kakkonen
My slides at Nordic Testing Days 6.6.2024
Climate impact / sustainability of software testing discussed on the talk. ICT and testing must carry their part of global responsibility to help with the climat warming. We can minimize the carbon footprint but we can also have a carbon handprint, a positive impact on the climate. Quality characteristics can be added with sustainability, and then measured continuously. Test environments can be used less, and in smaller scale and on demand. Test techniques can be used in optimizing or minimizing number of tests. Test automation can be used to speed up testing.
PHP Frameworks: I want to break free (IPC Berlin 2024)Ralf Eggert
In this presentation, we examine the challenges and limitations of relying too heavily on PHP frameworks in web development. We discuss the history of PHP and its frameworks to understand how this dependence has evolved. The focus will be on providing concrete tips and strategies to reduce reliance on these frameworks, based on real-world examples and practical considerations. The goal is to equip developers with the skills and knowledge to create more flexible and future-proof web applications. We'll explore the importance of maintaining autonomy in a rapidly changing tech landscape and how to make informed decisions in PHP development.
This talk is aimed at encouraging a more independent approach to using PHP frameworks, moving towards a more flexible and future-proof approach to PHP development.
SAP Sapphire 2024 - ASUG301 building better apps with SAP Fiori.pdfPeter Spielvogel
Building better applications for business users with SAP Fiori.
• What is SAP Fiori and why it matters to you
• How a better user experience drives measurable business benefits
• How to get started with SAP Fiori today
• How SAP Fiori elements accelerates application development
• How SAP Build Code includes SAP Fiori tools and other generative artificial intelligence capabilities
• How SAP Fiori paves the way for using AI in SAP apps
Generative AI Deep Dive: Advancing from Proof of Concept to ProductionAggregage
Join Maher Hanafi, VP of Engineering at Betterworks, in this new session where he'll share a practical framework to transform Gen AI prototypes into impactful products! He'll delve into the complexities of data collection and management, model selection and optimization, and ensuring security, scalability, and responsible use.
LF Energy Webinar: Electrical Grid Modelling and Simulation Through PowSyBl -...DanBrown980551
Do you want to learn how to model and simulate an electrical network from scratch in under an hour?
Then welcome to this PowSyBl workshop, hosted by Rte, the French Transmission System Operator (TSO)!
During the webinar, you will discover the PowSyBl ecosystem as well as handle and study an electrical network through an interactive Python notebook.
PowSyBl is an open source project hosted by LF Energy, which offers a comprehensive set of features for electrical grid modelling and simulation. Among other advanced features, PowSyBl provides:
- A fully editable and extendable library for grid component modelling;
- Visualization tools to display your network;
- Grid simulation tools, such as power flows, security analyses (with or without remedial actions) and sensitivity analyses;
The framework is mostly written in Java, with a Python binding so that Python developers can access PowSyBl functionalities as well.
What you will learn during the webinar:
- For beginners: discover PowSyBl's functionalities through a quick general presentation and the notebook, without needing any expert coding skills;
- For advanced developers: master the skills to efficiently apply PowSyBl functionalities to your real-world scenarios.
Smart TV Buyer Insights Survey 2024 by 91mobiles.pdf91mobiles
91mobiles recently conducted a Smart TV Buyer Insights Survey in which we asked over 3,000 respondents about the TV they own, aspects they look at on a new TV, and their TV buying preferences.
Essentials of Automations: The Art of Triggers and Actions in FMESafe Software
In this second installment of our Essentials of Automations webinar series, we’ll explore the landscape of triggers and actions, guiding you through the nuances of authoring and adapting workspaces for seamless automations. Gain an understanding of the full spectrum of triggers and actions available in FME, empowering you to enhance your workspaces for efficient automation.
We’ll kick things off by showcasing the most commonly used event-based triggers, introducing you to various automation workflows like manual triggers, schedules, directory watchers, and more. Plus, see how these elements play out in real scenarios.
Whether you’re tweaking your current setup or building from the ground up, this session will arm you with the tools and insights needed to transform your FME usage into a powerhouse of productivity. Join us to discover effective strategies that simplify complex processes, enhancing your productivity and transforming your data management practices with FME. Let’s turn complexity into clarity and make your workspaces work wonders!
Pushing the limits of ePRTC: 100ns holdover for 100 daysAdtran
At WSTS 2024, Alon Stern explored the topic of parametric holdover and explained how recent research findings can be implemented in real-world PNT networks to achieve 100 nanoseconds of accuracy for up to 100 days.
Encryption in Microsoft 365 - ExpertsLive Netherlands 2024Albert Hoitingh
In this session I delve into the encryption technology used in Microsoft 365 and Microsoft Purview. Including the concepts of Customer Key and Double Key Encryption.
Observability Concepts EVERY Developer Should Know -- DeveloperWeek Europe.pdfPaige Cruz
Monitoring and observability aren’t traditionally found in software curriculums and many of us cobble this knowledge together from whatever vendor or ecosystem we were first introduced to and whatever is a part of your current company’s observability stack.
While the dev and ops silo continues to crumble….many organizations still relegate monitoring & observability as the purview of ops, infra and SRE teams. This is a mistake - achieving a highly observable system requires collaboration up and down the stack.
I, a former op, would like to extend an invitation to all application developers to join the observability party will share these foundational concepts to build on:
In his public lecture, Christian Timmerer provides insights into the fascinating history of video streaming, starting from its humble beginnings before YouTube to the groundbreaking technologies that now dominate platforms like Netflix and ORF ON. Timmerer also presents provocative contributions of his own that have significantly influenced the industry. He concludes by looking at future challenges and invites the audience to join in a discussion.
22. class Species
attr_accessor :type
HUMAN = "human"
# some code
def is_human?
self.type == Species::HUMAN
end
end
23. class GodClass
def environment_to_support(species)
case
when species.is_human?
{:feeds_on => ["Plants", "Meat"],
:required_elements_in_atmosphere => ["Oxygen", "Nitrogen"]}
when species.is_babel_fish?
{:feeds_on => "Brain wave",
:required_elements_in_atmosphere => []}
# so on
end
end
end
26. class BabelFish < Species
def environmental_necessities
{:feeds_on => "Brain wave",
:required_elements_in_atmosphere => []}
end
end
class GodClass
def environment_to_support(species)
species.environmental_necessities
end
end
28. class User
def is_admin?
self.role == :admin
end
end
class ApplicationController < AbstractController::Base
def require_admin_privilege
unless current_user.is_admin?
head :unauthorized
end
end
end
35. class Species
@@environmental_necessities = {
"babel_fish" => {:feeds_on => "Brain wave"},
"human" => {} # so on
}
def environmental_necessities
@@environmental_necessities[self.type]
end
end
37. class Aircraft
def start_engine
# try to start the engine
raise "Unable to start engine" unless @engine.started?
end
end
38. class Aircraft
def deploy_landing_gear
# try to deploy the landing gear
return @landing_gear.deployed?
end
end
39. class Aircraft
def deploy_landing_gear
# try to deploy the landing gear
# landing gear is stuck halfway through
raise "Prepare for crash landing" if @landing_gear.stuck?
return @landing_gear.deployed?
end
end
41. begin
# some calculations
# some network io
# some file io
# some magic
rescue => e
logger.error('Run! Run! we have an error!')
end
42. begin
# some calculations
# some network io
# some file io
# some magic
rescue => e
logger.error "Just logging! don't look at me like that."
raise
end
43. begin
# some calculations
# some network io
# some file io
# some magic
rescue ZeroDivisionError
# handle the zero devision exception
rescue SomeCrazyException
# handle the crazy exception
rescue => e
logger.error "No idea what's heppening. I'm just going
to retry in a while. #{e.message}"
end
52. class Person
def teach(arguments)
arguments[:student].accept_skill(skill(arguments[:skill]))
end
end
# 1.8.x
yoda.teach(:student => luke, :skill => "lightsaber")
# 1.9.2
yoda.teach(student:luke, skill:"lightsaber")
# VS
yoda.teach(luke, "lightsaber")
64. class BabelFish
def translate(some_sound, to_language)
# code for
# detecting the language
# of the text
# code for
# converting the input sound
# into text
# code for
# generating text
# in target language
# code for
# convertin text
# to speach in to_language
end
end
65. class BabelFish
def translate(sound, to_lang)
from_lang = detect_language(sound)
from_text = convert_to_text(from_lang,sound)
to_text = translate_text(from_lang, to_lang, from_text)
return text_to_speach(to_text, to_lang)
end
private
def detect_language(sound)
# some code
end
def convert_to_text(language,sound)
# some code
end
def translate_text(from, to, text)
# some code
end
def text_to_speach(text,language)
# some code
end
end
69. class BabelFish
def translate(sound_data, to_language)
Sound.new(sound_data).to_text.translate(to_
language).to_sound
end
end
class Sound #:nodoc:
# code
end
class Language #:nodoc:
# code
end
class Script #:nodoc:
#code
end
89. class Foo
def self.say
p "#{self.name} says hi"
end
end
class Bar < Foo
end
Foo.say #=> "Foo says hi"
Bar.say #=> "Bar says hi"
90. class Foo
def self.say
p "#{self.name} says hi"
end
end
class Bar < Foo
def self.say
super
p "and welcomes you to ruby conf"
end
end
Foo.say #=> "Foo says hi"
Bar.say #=> "Bar says hi" n "and welcomes you to ruby conf"
Good morning everyone and thank you for being here. \n
\n
I do my open source here\n
Albeit intermittently I tweet here\n
This is Niranjan\n
you can find his open source contribution here\n
he tweets here\n
\n
\n
criticising\ndiscuss design or architecture\ntrivial part of the system or whole codebase\n\nIf there is one common thing that we all love, it&#x2019;s criticising code. We discuss the design or if you excuse me &#x201C;the architecture&#x201D; of the system we are working on. It may be a trivial part of the system or it might impact the whole codebase. The fact is we like to talk.\n
Some time these discussions lead to a debate\n
To begin with rational arguments are presented by everyone involved to justify why certain thing should or should not be done. Points are put forward, counter-points are offered and merits and demerits of various approaches are taken into consideration. This often leads to a conclusion and everyone gets back to coding. But unfortunately sometimes this doesn&#x2019;t happen.\n
Despite of all the odds, someone decides to stick with his solution and starts offering defensive arguments. It&#x2019;s fine, we can agree to disagree. \n\nBut then there comes a time when the unspeakable is spoken.\n
The language designers weren&#x2019;t stupid, why can&#x2019;t I use this feature when the language supports it\n
\n
Yes indeed, the language does support it. Language also supports writing 900 odd lines long class with 150 lines long method. Which has a switch case, for loop, 42 return statements, a few raise conditions and opening up a class like Array to add domain logic.\n\nAll these things and many more are supported by Ruby. There are places where you&#x2019;ll use these features. But you shouldn&#x2019;t treat everything as nail just because you are holding a hammer.\n
In next 30 minutes we will talk about various things which Ruby supports, few are specific to Ruby, while other are more generic in nature. We will talk about why you need to pay attention whenever you use any of these features.\n\nIn this talk we will cover various features provided by Ruby that, while awesome, should be used with caution. Few of these features are specific to Ruby, few are language agnostic.\n
Most of these constructs might seem like a norm and necessary if you have been writing lot of library code to provide a generic feature set, but while writing domain specific (production) code they can be avoided to achieve better object oriented design\n
One thing I&#x2019;ld like to point out is, most of this is a mechanic to achieve a better code.\n
[Handoff]\n\nDepending on the maturity of team, you may use few of these construct without adding &#x2018;Magic&#x2019; for the fellow programmer, while you may stay away from others by instinct.\n\nWhen I say fellow developers, I am not talking about your current team but also the developers who are going to inherit your code.\n
[achamian]\n\nI guess that&#x2019;s enough of context let&#x2019;s skip through rest of the context and jump directly to the crux of the talk\n
Jumping straight into the code example.\n\nWhat&#x2019;s wrong with this method:\n\nanyone?\n\nIt&#x2019;s as short as a method can get.\nName expresses the intent.\nIt returns a boolean, appropriately indicated by &#x201C;?&#x201D; at the end as per the Ruby convention\n\nLooks perfect and it is. But it indicates a smell. Every time I write a method like this, I ask why anyone needs to know what state my object is in. The very existence of this method indicates that there&#x2019;s an &#x201C;if&#x201D; or worse &#x201C;switch&#x201D; somewhere else in my code. May be something like this\n
Sweet, we have a switch case. \n\nNice readable code, is it testable? Who cares?\n
Now that&#x2019;s a problem our small, beautiful method created for us.\n
We are violating one of the basic principles of OO &#x201C;tell don&#x2019;t ask&#x201D;. How to fix it, maybe it&#x2019;s time to create a different classes for Human and BabelFish. May be something like \n
\n
Not always. There are places where you have to make a choice between either breaking &#x201C;tell don&#x2019;t ask&#x201D; or pushing code to an objects where it doesn&#x2019;t belong. In such cases you might be forced to expose internal state of the object to outside world. For example:\n
Yes, this can be pushed into user by passing a lambda etc. but at least it is acceptable as you don&#x2019;t want to push controller&#x2019;s responsibility to a model\n
\n
While most of the places switch can be replaced with a better modelling, there are scenarios where it&#x2019;s difficult to avoid switch. The only example I can think of is parsing an input from a command line\n
[Handoff]\n\nNo switch, no if, no exposing the type.\n\nThe branching still exists.\n\nWhile all that is true I&#x2019;ld rather leave my code with an if or a switch and make the branching explicit so as to refactor it later instead of hiding the branching behind a Hash. \n\nThis is strictly a personal preference.\n
[aakashd]\n\nWhat I want to talk about raising & rescuing exceptions is based on an assumption that we all know about two possible program flows; the regular flow & exceptional flow. That one should not throw an exception in regular flow & should use it carefully even in exceptional flow.\n
\n
\n
But what happens when landing gear is stuck.\n
One should raise an exception when the purpose of the method cannot be completed and because of that the application is left in an unknown and possible inconsistent state.\n\nIn languages like Java, exceptions are way to force user to handle a possible outcome of method invocation, which I believe is very much useful because hardly any of the developers take pain to read the documentation.\n\nAnd last but not the least is the teams or community&#x2019;s conventions about using exceptions. If nothing please stick to that.\n
A classic example of wrong exception handling is unqualified rescue\n\nIf you are expecting a piece of code to raise an exception, it is always better to catch that particular exception instead of catching a generic exception. \n\nIf you are forced to write an unqualified rescue because the code block you are rescuing raises a lot of exceptions, then probably that problem should be solved first. \n\n\n
One of the scenario where unqualified rescue makes sense is that we just want to log the exception & propagate it further.\n
Another scenario where I will have an unqualified raise is when I don&#x2019;t want an unexpected exception to kill the deamon process.\n\nI would handle all the known exceptions if I can, and in the end just suppress the exception after logging it.\n
(Gregory Brown aka @seacreature)\n\nThere are just too many anti-patterns for rescue..\n\nAnother `clever` use of rescue is to assign default values in case of exceptions. What Gregory Brown calls as Blind Rescue Mission in his book Ruby Best Practices. The example in his book is so apt, that I have shamelessly copied the same thing.\n
The writers intention here is to return a string &#x201C;Anonymous&#x201D; when user does not have first_name. This line of code is slightly complicated because of the ternary operator.\n
Few people prefer it&#x2019;s concise & questionably though but cleaner version.\n\ncertainly looks a lot more cleaner but what happens when the user itself is nil. The line still succeeds & tells me that the current user is Anonymous.\n
[Handoff]\n
[achamian]\n\nRuby supports accepting variable number of arguments or hash as a last argument of the method call. While writing a library code this comes in handy.\n
But when you are dealing with non-generic code it is better not to accept the var args. Explicitly calling out list of arguments to the method might increase the method signature but it is much more readable.\n
If method is accepting a huge list of parameters, say 5 or more, because of which you want to shift to switch to *args, that itself is a smell.\n\nIt might be necessary for a factory or an object builder, but other places you might want to look at that list and see if those arguments can be clubbed into one or more objects. I am not talking about DTOs here. These related parameters almost always represent some job which method under consideration is doing which can be pushed to that object itself.\n
Same can be said for the hash as a last argument of the method. If the hash represents a long list of options which user may or may not pass, I can understand accepting a hash as it makes it easier to invoke method.\n\nTypical example of such options hash is any of the Rails view helper methods.\n
Here the first approach looks tempting as the invocation is lot more readable than the second case. But I&#x2019;ld rather wait for Matz to support such method invocations over using hashes. \n\nBetter state the number of arguments method accepts in the method signature rather than the rdoc\n
\n
\n
Hamster\n
\n
\n
Path to the dark side it leads to\n
please don&#x2019;t\n
Before I put forward my opinions about private methods let&#x2019;s see what the proponents of private methods say about it. The top reasons why people choose private methods are:\n
\n
\n
\n
I have twisted the implementation of BabelFish to make it more understandable for people who are not familiar with Hitchhikers Guide. So please pardon me for this stupid code.\n\nAs I said earlier, this big method is not readable & to any new developer the implementation is not very clear. So let&#x2019;s split this into multiple methods.\n
As expected the translate method has become concise & readable. The extracted methods are obviously private, as no one should be able to call detect_language or text_to_speach on BabelFish, it&#x2019;s just bad API & I couldn&#x2019;t agree more.\n\nSo now we have a clean API, with great encapsulation & all the methods are perfectly readable.\n\nIf using private methods allows me to achieve all these important qualities of a good API, why do I smell something fishy here?\n
I still feel I shouldn&#x2019;t have done this!\n
Our BabelFish is too big & doing too many things. Any implementation change, bug fixes, new functionalities will touch this one file. Not a good thing to do.\n
There may not always be an alternative to private methods, but in my experience if I look hard I have generally found another hidden entity, who can take this responsibility and make the original class smaller & neater.\n\nI always look at private methods as first step towards better design, the key is to observe the data private methods are manipulating. If you see a data that is being manipulated purely by private methods, you have just found the entity that is waiting to be extracted.\n\nGenerally private methods can be replaced by composition or delegation.\n
Broken encapsulation\nways to communicate not to use internals\nstill I prefer it\n\nI have probably broken library level encapsulation & exposed classes with public interfaces that I don&#x2019;t want my users to use. But I would any day prefer this design over a well encapsulated BabelFish.\n\nThere are ways to communicate to user that these classes should not be used. Most simple but not very effective way would be to annotate the class or module as nodoc, so that the respective class or module won&#x2019;t be documented.\n
\n
\n
\n
\n
\n
\n
\n
\n
\n
From OO design perspective I have same set of arguments against static methods that I have against private methods. In some cases static methods are worse than private methods, because they encourage procedural programming.\n\nI will repeat myself, that if you look hard you can certainly find the objects to whom you can delegate this responsibility.\n
Next few slides are my personal opinions & I am still figuring out things. They will be very controversial, and I won&#x2019;t be surprised if everyone of you disagrees with me.\n\nIn my more than 4 years of experience with Java, class methods or static methods have become a taboo. I have heard similar nightmarish stories of statically typed languages where bunch of static methods live in their own global context & cause limitless problems right from bad design, hard to test code, threading issues to erratic behavior of static members due to multiple custom class loaders.\n\nLet&#x2019;s see what arguments I would have presented against static methods before I started working with Ruby.\n
\n
\n
\n
\n
It suffice to say that as a rule of thumb, just stay away from static in Java world.\n
But apart from the OO thingy, none of the problems stated previously hold true with Ruby.\n
The ruby class methods are unfairly compared with Java static methods, when the Ruby class methods need not be static.\n\n\n
\n
The ruby class methods can be inherited, making them part of the class definition hierarchy if not object hierarchy. \n\nThe method is no more a non-extensible block of static code & if coded well it can deliver a lot of value.\n
The behavior of class methods can be extended or completely overridden, making it more reusable. If there is a logic at blueprint level but not applicable at instance level, you can effectively use class methods to DRY the code.\n
The ruby class methods are as easy to test as instance methods, making the maintenance a non issue.\n
ActiveRecords find method is one my most favorite example of a good class method. There will be a lot of people here who hate the kind of baggage extending activerecord pushes on simple models. But it really changed the way I used to look at class level methods, coming from Java world.\n\nWith ruby&#x2019;s class methods, I am more comfortable having this as class method on my models, rather than adding boilerplate code of DAO&#x2019;s.\n
What I am about to say sounds slightly convoluted, but I will speak slowly. Ruby class methods are not static they are methods on an instance of a class Class\n
\n
\n
Having a class method which does not use its state is as stupid as having an instance of Company \n