One of The Dumbest Questions Asked on Ruby/Rails Subreddits

One of the dumbest questions I see asked on the Ruby/Rails subreddits is "Are Ruby & Rails still worth learning today?" (plus other variations, such as "Are Ruby and Rails still relevant today?" and "Are Ruby and Rails dead?"). Are you stupid!?!! Obviously, if you ask such a question inside an online community of devs who make a living with these technologies, they are going to answer "yes" (to the first version of the question)! But, more importantly, any Software Engineer worth his or her salt would be able to answer such a question for themselves by doing their own research, spending an hour or a few minutes at least trying out the new technology they are asking about, and building a list of pros/cons/trade-offs to compare the technology to others. Lastly, if you rely on the words of others instead of your own ability to reason in Software Engineering, then you are letting others think for you instead of thinking for yourself, meaning you are surrendering your competitive advantage and weeding yourself out of the competitive pool, so it would be a bad idea to hire you regardless of what skills you have in Software Development. This is how idiots end up using a terrible garbage library like React.js in an otherwise pristine elegant Ruby on Rails web app codebase. Honestly, if you're too lazy as to answer that question for yourself while idiotically posing the question to a group of devs where the majority would answer "yes" to learning Ruby/Rails, then you won't be considered or get hired at any of the good jobs I've worked at. Initiative and analysis skills matter a lot in Software Engineering job candidates and nothing says there is zero initiative and no analysis skills than lazily asking a question that a Software Engineer should be able to answer for themselves. 

The Embarrassing Ruby/Rails Community Chronicles 2026-07-28

"The Embarrassing Ruby/Rails Subreddit Chronicles" becomes "The Embarrassing Ruby/Rails Community Chronicles" as it expands to cover embarrassing interactions by bad Ruby/Rails devs all across social media and the real world, exposing rudeness, meanness, discrimination, and unexcellence/unintelligence in the Ruby/Rails worldwide community. The goal of course is to call that out to discourage in favor of true Rubyist MINASWAN attitudes and behaviors instead (Matz Is Nice And So We Are Nice).

While going through the yearly Bystander Intervention training for my job, I stumbled upon "Persistent unwanted personal questions" as a form of verbal abuse. 

I have to confess I recently experienced that at a Ruby tech event. A bad Ruby dev (the kind you'd find on the Ruby/Rails subreddits) kept rudely asking me what my salary was after I told him I won awards by Matz (the creator of Ruby) for my open-source projects. Any normal Rubyist would have asked me about my open-source projects instead, just out of normal Software Engineering curiosity to learn better ways of serving customers with Ruby. Instead, he kept prying very hard about my salary and was unwilling to accept the fact that it's rude to ask people he doesn't know for their salary. 

After I gave him multiple examples of how previous companies I worked at had policies against people asking about salaries because knowing the answer could cause envy and create bad relationships, citing a real story of that happening at one of my previous jobs when someone's salary leaked, he pivotted towards asking me if "I felt uncomfortable answering". He kept insisting on me answering that new question instead going forward. The person was already coming across by that point as a very awful rude unprofessional person due to literally attempting to make me feel uncomfortable with incessent questioning.

He sounded like he desperately wanted to "win the conversation/situation" in any way possible (of me having won awards he hasn't won, instead of being humble/happy for me) by trying to make me "look bad" as someone who is "weak" due to being "uncomfortable". That revealed to me what his original intention and ulterior motive was behind asking for my salary: He just wanted to make me "look bad" as I'm sure he was going to tell me my salary was too low no matter what answer I would have provided, as a trap, to insult me and render me "unimportant" even if I've won awards by Matz. As if the awards were about me "being important" or "making more money" as opposed to ensuring I serve customers with the best quality work possible (which is what awards really encourage from the perspective of truly ethical excellent people who don't prioritize greed or pride over customer service). 

What a ridiculous interaction that was! I finally answered him by saying "it's not about me being uncomfortable. It's just a bad practice/etiquette to ask for someone's salary, especially if you don't know them well, and I won't endorse/enable that practice by answering the question even if I were comfortable with answering it."

The dude confessed to me eventually that he doesn't work in Ruby anymore because he lost a political battle at work, so he is now using Python even though Ruby is more effective than Python at building his work application. What a loser! That's exactly the kind of pushover rude loser my team would never hire and would screen for during the interviewing phase of hiring. We don't want devs who lose political battles for what technology decisions are best for serving customers. I have won many many such political battles at my company over the years, and it was because I'm no pushover. A bad dev being unethical/rude goes hand in hand with other bad attributes like being a pushover, which is why we never hire such devs in the first place.

The Ruby Community in 2026

The Ruby community in 2026 is dominated by mean discriminators and their benefactors (they're about 50% of the community at least). Many devs in the Ruby community who are indirect (unconscious) or direct benefactors of discrimination have this attitude of "well, if this discrimination problem is not affecting me, then I don't care". So, they're not real Rubyists because real Rubyists always care about being nice to everyone in the community.

Basically, the #Ruby community in 2026 is comprised of 3 groups. 

The 1st group is the true Rubyists who are customer focused with their work (not popularity focused) and who are sincere nice people, well-educated, and well-accomplished with often a good number of free open-source contributions and talks for the benefit of the Ruby community at large. 

The 2nd group is the elites (devs who work at organizations like RubyConf, 37Signals, and Shopify) who act like they're not required to treat everyone with equality and respect, and often discriminate against certain people in the community, treating them like dirt while boosting other people in the community who don't have merit in Ruby or in general at their expense. When such companies hire unqualified devs by giving them false privilege, they don't always choose them based on true merit or Software Engineering education and skills, yet based on whether they belong to certain elitist circles, they are alphas/cool, or they are good looking to use them as the product, not their Software Engineering education or skills. That's an incredible form of blatant discrimination and preferential treatment. 

The 3rd group is the benefactors of false privilege. It's mostly people who have no completed university degrees, no big accomplishments in open-source, no substantial Software Engineering skills beyond Monkey-See-Monkey-Do and copying "famous devs" at large corps without true understanding, but they're treated like they're better than the 1st group because the 2nd group gets off on the feeling of acting like benevolent heroes by giving false privilege to people in the 3rd group who don't deserve it at the expense of people in the 1st group who have earned everything with sincere effort and smart ethical excellent work. In other words, people in the 3rd group are living off of stolen good via false privilege and preferential treatment while making the Ruby community worse. I have run into people of the 3rd group who work for organizations of people in the 2nd group that came across as extremely rude/mean, unintelligent/unskilled, apathetic towards treating everyone with equality, niceness, and respect, and quite aloof or nasty in some instances. 

This only started happening more with the rise of Shopify as explained in this article:

https://andymaleh.blogspot.com/2025/06/shopify-has-been-bad-for-ruby-community.html

In other words, RubyConf in 2026 is FakeRubyConf. Anyone attending it is endorsing discrimination and unexcellence. Learn more about that here: 

https://andymaleh.blogspot.com/2026/06/rubyconf-has-joined-railsconfrailsworld.html 

I've said it in previous posts. If the people perceived as mean discriminators were to courageously address this issue and apologize for it if needed, I'd take down these posts, alas the coward's plea is often the only response provided. They're not real men of honor who are willing to face the music and address serious matters like discrimination to demonstrate good will and tell us they care about treating everyone in the Ruby community equally.

The Embarrassing Ruby/Rails Subreddit Chronicles 2025-12-02

Welcome to another edition of the Embarrassing Ruby/Rails Subreddit Chronicles! A post was shared in the Rails subreddit about DHH claiming that money is a good reason to cheer for Shopify. I simply stated that no amount of money justifies mean discrimination, and I immediately got downvoted to 0. That proves yet again that there are devs in the Rails subreddit who are OK with mean discrimination if a certain amount of money is made and the subreddit mods are OK with mean discrimination by extension by allowing them into the group. 

Yet another embarrassment for the Ruby on Rails community as it officially admits the belief that mean discrimination is OK if a certain amount of money is gained, throwing MINASWAN out of the window instead of behaving in the ethical and nice Ruby way! This is the truth of the Ruby on Rails community in 2025!

The Embarrassing Ruby/Rails Subreddit Chronicles 2025-11-24

Welcome to another edition of the Embarrassing Ruby/Rails Subreddit Chronicles. Attached are screenshots for another embarrassing incident demonstrating the mean/hateful nature of Ruby/Rails subreddit members and how they downvote without first having a nice and loving patient discourse in case of a misunderstanding or an uninformed disagreement. 

It hit me the other day that the reason I suffer from mean/hateful behaviour in the Ruby/Rails subreddits despite being a 2-time Fukuoka international competition winner (of awards by Matz, the creator of Ruby), a 4-time RubyConf speaker, and a 2-time RailsConf speaker is because they allow in people who are below the minimum bar of professionalism and respectful conduct that is required for hiring in a Software Engineering job at a respectful ethical company. I mean I wouldn't hire any of them in a million years, not just for lack of technical skills, but more importantly for not having the patient loving nice Rubyist personality. So, why do the Ruby/Rails subreddit mods allow in unnice/hateful people who are below the minimum bar of respectful conduct?! This is a negative reflection on the mods just as much as it is on the trash members of the Ruby/Rails subreddits. I say trash because they're no different from trash criminals and drug addicts I'd encounter on the streets in their mean behaviour. It's not the behaviour of a member of the Software Engineering community, let alone the Ruby/Rails community.

In this screenshot, you can see a Ruby subreddit moderator asking for feedback about new rules, which in my opinion are embarrassingly fascist (not referring to the linked rules, yet the ones in the post, which negate the value of asking for feedback; I never restrict people from sharing feedback, especially negative, in the sports groups I moderate, and they're infinitely better than this Ruby group as a result). 

Here, you can see my response, and how it was immediately downvoted to 0 within 5 minutes of posting, demonstrating the mean hateful non-open-minded unsympathetic nature of Ruby subreddit members (not sympathizing with someone who says they received hateful behaviour means you are a hateful person).

Of course, fascist rules are a red herring. They're a side effect to Ruby subreddit mods holding on to terrorists that they harbour within their group instead of letting them go as explained in this sentence:

"If you worry too much about the rules, it means you have the wrong kind of people in the group, and that’s the real problem not being dealt with (eg allowing in haters of Ruby, people who don’t give Ruby the benefit of the doubt in applications that it’s not common in, people who are below the minimum bar of ethical respectful conduct and professionalism, etc…)."

Here is my full comment, repeated here textually:

"This group allows a lot of hate on Frontend Ruby. It also literally allows people who don’t truly like Ruby or get it to freely discuss JavaScript as better than Ruby while making true Rubyists who understand and appreciate Ruby’s benefits over JavaScript not feel safe in a Ruby group. This automatically renders the group a bad one.

Also, I’ve encountered a lot of hateful behavior in this group against anything that’s novel and outside the box of what’s common in the software development community. 15 years ago, Rubyists were open minded about new novel ideas and patiently listened to them without downvoting. In this group today, such ideas get downvoted to zero in a very hateful unintelligent way without giving the poster the benefit of the doubt or even attempting to understand the benefits of what is shared. That discourages Rubyists from sharing new ideas or exploring them in this group in a respectful intelligent open minded manner. I personally make an effort not to downvote anyone, yet to ask questions and facilitate discussions if I disagree with something.

In general, rules that are unethical or do not implicitly respect everyone equally only make the group a bad one.

Lastly, politics are off-topic. Honestly, this is not a good group if it allows off-topic things while attempting to shift the blame unto the people who are right about the matter. That’s attempting to get out of responsibility, which is also bad. If you don’t understand this, you’re on the wrong side of this. I’m apolitical and don’t vote by choice by the way, so I don’t care to discuss this further because I don’t like discussing politics ever, especially not in a Ruby group not about politics.

If you worry too much about the rules, it means you have the wrong kind of people in the group, and that’s the real problem not being dealt with (eg allowing in haters of Ruby, people who don’t give Ruby the benefit of the doubt in applications that it’s not common in, people who are below the minimum bar of ethical respectful conduct and professionalism, etc…).

Update: Exhibit A: I have won 2 awards from Matz in very difficult international engineering competitions, and have spoken at RubyConf 4 times, and yet people don’t respect me, discriminate against me and hate me, unintelligently downvoting my posts out of hate and discrimination not for any intelligent reasons. Of course, this behavior is only an indirect reflection on the mods allowing hateful disrespectful people into a Ruby group without respecting the Ruby luminaries of the Ruby community. I was respected more 10-15 years ago when I wasn’t a very well accomplished Ruby Software Engineer back then because the Ruby group was run better back then."

The Rails subreddit is an embarrassment to the Ruby community

The Rails subreddit is such an embarrassment to the Ruby community. I get anti-Ruby sentiments from people there more than anywhere else. People there are very hateful of any Ruby innovations that are outside the box, like using Ruby in the Frontend of Rails apps. It is shameful the group does not make people with highly innovative ideas feel safe. Everyone there must comply with the few things the top players in the Rails community say or else they are downvoted to kingdom come while receiving many mean hateful comments without being given a chance to explore new divergent ideas safely, meaning the group is unsupportive of innovation and diversity, as they discriminate against people who have diverse ideas by being very nasty towards them. Ironically, such people act like how many devs acted towards Rails in the mid-2000s when Rails was still very new and young. This goes against the Ruby motto MINASWAN (Matz Is Nice And So We Are Nice). I personally prefer the acronym WAN (We Are Nice) or WANNJBMIN (We Are Nice Not Just Because Matz Is Nice), but either way, the Rails subreddit fails all niceness acronyms. When I pointed that out to someone on the Rails subreddit, their response was literally "lol", meaning lots of laughter as in they don't care, thus confirming my point 100%.

 
With the negative things happening at the Rails subreddit, it is no wonder the Rails community is questioned daily on whether Rails is dead. The community is not healthy at all in 2024 and is not what it used to be 10 years ago when everyone was open-minded about any brand-new out-of-the-box ideas that are not necessarily coming from the creators of Rails themselves. I joined the Rails community in 2007 initially because of how open-minded, creative, and intelligent it was, but today it is extremely closed-minded outside of what the Rails top players do. The community has become elitist, meaning only people who are part of the elite contributors to Rails or who are compliant with the elitists' thoughts and ideas are included in respectful treatment by others, but everyone else who is not part of the elite core or the people who worship them and their ideas are excluded from any respectful treatment or are ignored without providing any community support. Again, this goes counter to MINISWAN. 

When a respectable Software Engineer disagrees with someone else's idea, they highlight their reservations rationally in a civil manner without downvoting a post until they have done their homework first and tried whatever open-source project is mentioned to be supportive of open-source and to ensure their opinion is an informed opinion. They would never knock something till they have tried it. Downvotes/upvotes that come from uninformed opinions have zero weight. Uninformed opinions don't say anything about the subject at hand, but they say a lot about the false prejudice of downvoters/upvoters and how incompetent and unintelligent they are for not doing their homework or having the curiosity of true Software Engineers to try the new open-source projects.

If you want a subreddit that is NOT flooded by Ruby haters who are unsupportive of new Ruby open-source project innovations and NOT flooded by people who are negative/mean/nasty/discriminatory towards anyone who has ideas that are outside the mold, check out my new Rubyists subreddit:

https://www.reddit.com/r/Rubyists/

It is a very new subreddit that aims to be an online group for hardcore Rubyists, meaning people who are experienced in Ruby and who fully understand the awesomeness and potential of Ruby while being open-minded about new Ruby innovations. It doesn't have many people in it right now, but I'd take the few that are in it over the many hateful people who are in the Rails subreddit. I would be patient with growing this group very gradually. It is worth it in the long-term to have a place for hardcore Rubyists to converse without feeling unsafe in sharing out of the ordinary open-source Ruby ideas.

Still, it is not enough to join the group. Please share as many posts there as possible too to help grow it. Please break the ice by sharing a post immediately if possible.

Also, please repost this tweet and repost the Rubyists subreddit link on all your social media accounts if possible.

Can You Afford To Be Too Busy for Long-Term Indirect-Value Activities in Software Engineering?

Software Engineering activities are split between ones that provide direct value to customers in the short-term and ones that indirectly benefit customers in the long-term. It is important to have a good balance of both in order to ensure the long-term viability of Software Engineering work and continuously offer maximal value to customers. The best Software Engineers out there are those who have mastered the skill of balancing short-term direct-value activities with long-term indirect-value activities.

Examples of short-term direct-value activities are gathering user requirements from customers, breaking requirements down into use-cases, writing implementation code, doing QA testing, and deploying software into the cloud. 

Examples of long-term indirect-value activities are reading tech books and blogs, learning new technologies with vastly different approaches to what is commonly followed, building toy projects that explore new ideas, and attending local tech meetups and software conferences.

Developers who engage in short-term direct-value activities without engaging in long-term indirect-value activities end up stagnating in technical skills and getting stuck in what is known as Single-Loop Learning (read about Single-Loop Learning and Double-Loop Learning here: https://en.wikipedia.org/wiki/Double-loop_learning). In other words, they get stuck inside the box without intelligent questioning of the technology approaches and libraries being used. So, they passively accept what some library creators decided (including what they decide in future library versions) without thinking for themselves, thus losing the ability to think outside the box and make exponential jumps in productivity. Instead, they might make contributions to libraries inside the box of what they already use instead of exploring much different simpler and more elegant solutions outside the box. 

Often, such developers practice an anti-pattern known as Hero Worship as they position some library creators as Heroes on top of everyone else, making themselves believe that the Heroes are way above anybody else's ability to think, and thus they shut down their mind and default to relying on the thoughts, ideas, and works of the "Heroes" without ever questioning them. That's instead of actually thinking for themselves and living by the truth that everyone makes mistakes and everyone could be wrong from time to time, including library creators. As a result, they end up adopting highly over-engineered solutions that waste a lot of productivity due the solutions being originally created for the large organizations of the "Heroes" and their specific project situations.

The single loop referred to in Single-Loop Learning is the short-term feedback loop that is relied on to improve things within the box of previously selected technologies without periodically questioning the entire box in an outer long-term feedback loop to explore brand new novel approaches that might provide exponential jumps in improvement (Double-Loop Learning). For example, developers that use Java Enterprise Edition + Spring could continuously discover weaknesses in an inner feedback loop that leads them to upgrade their Java Spring libraries repeatedly. They won't have exponential jumps in productivity unless they employ an outer feedback loop that enables them to re-evaluate all their technology choices and discover that the dynamically typed Ruby language and the Rails web framework could offer exponential improvements in productivity for many business domains that would cut 12 months of work down into 6 months or less. 

Unfortunately, developers who stick to the safe box of technologies they are accustomed to instead of practicing Double-Loop Learning end up in a rot due to the Dunner-Kruger Effect (https://nesslabs.com/dunning-kruger-effect), meaning they end up not knowing what they don't know as time goes on. So, when others discover new ways to improve Software Engineering productivity and quality in an exponential jump that renders 12 months of work doable in 6 months or less, the developers stuck inside the box end up missing out on those benefits completely. It's like Java developers that have never experienced the huge productivity benefits of Ruby on Rails. They don't know what they don't know. Eventually, their competitors end up swooping in and taking their business, which is what sometimes causes layoffs at companies. In other circumstances, such developers are fired due to not delivering work at maximum capacity when others are able to do their work in half the time or less. 

One metaphor to explain this is how shipping services advanced over time. More than a couple of centuries ago, shipping companies relied on horse carriage. Later, they relied on the train. After that, cars were invented, so shipping could be done on trucks. Finally, airplanes were invented and sped up the ability to ship packages even further. If horse carriage shipping companies kept themselves too busy with horse carriages pulling the weights of their shipments to actually learn how to utilize newer technologies of shipping, they would have allowed their competitors to beat them to learning how to use newer methods of transportation and finish work in less than half the time needed for shipping on horse carriage, thus winning their business over. 

Some developers like to tell themselves excuses, like they are too busy with customer value adding work to spend any time reading tech books or exploring new novel technologies. Unfortunately, this attitude neglects the big picture and the fact that long-term indirect-value activities do bring more value to customers even if it is not apparent as they ensure the delivery of maximum value to customers in the long-term. So, not spending time on such activities results in worse quality work for customers in the long-term. Meaning, such developers resign themselves to doing bare-minimum quality work for customers by avoiding long-term indirect-value activities instead of boldly spending out of the box time that would enable them to do maximum quality work for customers over the long haul. In turn, they end up opening the door for their competitors to eat their lunch, whether by taking their company business or taking their employment positions. 

Making excuses to avoid something is always a red flag that signals mediocrity and a mediocre work ethic. Good Software Engineers always take responsibility instead of making excuses, and they have a healthy engineering curiosity about better technology approaches. No one can be thought of as a good engineer without having curiosity and passion for learning alternative methods of engineering that could offer better benefits to customers than whatever technologies are being used. Developers who make excuses usually do so because they have gotten too attached to and too comfortable within the confines of whatever technologies they know and have gotten too lazy to learn new technology approaches that shatter the comfortable box they have been operating inside of. Additionally, some of those developers are simply selfish as they care more about earning a paycheck with familiar work than doing their absolute best work possible for customers everyday. As such, those developers cannot actually be trusted to do the best work for customers. This matter goes further than keeping one's business and job. Those who do not do the best work possible for the amount of money paid to them by customers while claiming to belong to one of the "best businesses" out there are literally lying to their customers and engaging in unethical behaviour.

In summary, Software Engineers must engage in a good balance between short-term direct-value activities and long-term indirect-value activities to ethically ensure the long-term viability of Software Engineering work and continuously offer maximal value to customers, which helps in guarding their business and job from the competition.

Announcing 2 Talks for Montreal.rb Meetup in April 2023

The next Montreal.rb meetup (April 5, 2023) has been announced and will include 2 talks!!

https://www.meetup.com/montrealrb/events/291415005/

Talk 1 - Rails Already Supports View Components - 30 minutes

There are several view component Ruby gems out there that were created and used by Rails developers in order to decompose application views into view components. Little did they know, Rails already supports view components!!! This talk will explain the various ways Rails already supports view components out of the box. And as part of that, it will demonstrate that the built-in Rails view component options are simpler, more Rails-idiomatic, and more conformant to the MVC pattern (Model-View-Controller). As such, they offer higher maintainability and productivity by avoiding the big great evil of Over-Engineering and NIH-Syndrome (Not Invented Here). 

Talk 2 - Internal Productivity Tooling CLI - 30 minutes 

This is a talk on Potloc's internal productivity tooling CLI (Command Line Interface), including a short demo and tour of the codebase to complement. 

---

P.S. I have been promoted by Mathieu Gagné to a secondary organizer of the Montreal.rb meetup group (The Montreal Ruby Programming Language Community Meetup Group). If you would like to share useful knowledge with others in the Montreal Ruby community by giving a talk, please hit me up! The only requirement is that you work in Ruby or Rails at a senior level.

Presenting at Montreal.rb: Glimmer DSL for SWT - Ruby Desktop Development GUI Framework

I will be giving a talk at a Montreal.rb meetup with the title: 

"Glimmer DSL for SWT - Ruby Desktop Development GUI Framework"

The event will take place on Wednesday, October 5, 2022 at the Lexop office (506 McGill St Suite 400, Montreal, Quebec H2Y 2H6, Canada), starting at 6:30pm (talk starts at 7pm).

Abstract:

You may not already know, but it is possible to build native desktop applications for Mac, Windows, and Linux using Ruby, including native packaging as APP/DMG/PKG files on Mac, EXE/MSI files on Windows, and DEB/RPM files on Linux. In fact, Ruby syntax makes developing such applications much quicker with better maintainability than in traditional desktop development languages like C, C++, C#, Objective C, Swift, and Java. That is courtesy of Glimmer DSL for SWT, a JRuby Desktop Development GUI Framework that enables using the robust SWT cross-platform native GUI toolkit the Ruby way, with support for the following:

• Application Scaffolding
• Declarative Ruby GUI DSL (Graphical User Interface Domain Specific Language)
• Declarative Unidirecitonal/Bidirectional Data-Binding
• Declarative Drag and Drop
• Custom Components
• Canvas Graphics
• Embedded Browser (Web View)
• Native Executable Packaging (APP/DMG/PKG/EXE/MSI/DEB/RPM)

This presentation will provide attendees with a broad overview of the features of Glimmer DSL for SWT while demonstrating samples and complete applications along the way.

Target Audience:

This talk should be invaluable to web developers in addition to desktop developers as it shows how to apply MVC 100% cleanly in a local app, as opposed to in a cluttered web app with many layers of separation and routing complexity, so it provides a great reference of how to apply MVC optimally, which can transfer to the web in addition to being useful on the desktop.

RSVP: https://www.meetup.com/montrealrb/events/288312775/

If you are anywhere in the vicinity of Montreal or neighbouring cities (e.g. Ottawa), come and join us!

Please inform your colleagues and friends in tech about the event, and post about it on social media!

Update 2022-10-07: Presentation Video and Slides have been posted.

Eclipse Regional Communities, Chicago Edition

Yes, if you're not living close to Austin, you can come to Chicago instead. ;)

Please click >>here<< to sign up for the Chicago Eclipse Community mailing list.

We are open to any event ideas. For now, it seems like the first two events will be an Eclipse DemoCamp where participants get 5-10 minutes each to demo local Eclipse projects, and an Eclipse Ganymede overview.

We'll keep you posted. Otherwise, hang on in Chicago's windy weather!