Category: DevQuest

These posts are part of my quest in live and developing

DevQuest

Let’s change the culture and adopt a Code of Conduct

Posted on by emadev

Thank you for a very informative evening with Rob Richardson — who is a great speaker. I learned a lot.  Los Angeles .NET Developers Group offers access to various concepts and prodigious educational speakers, which is why I have continued to look forward to these evenings going on over five years.

Within the last year, I have noticed that attendance to the meetings has trended down to stagnant 10-15 attendees out of 2,025 Dotnetters (members of this group).

There are few adjustments that could increase Dotnetters attendance and retention — while cultivating an inclusive environment that embraces quality learning.

 IMPLEMENT A CODE OF CONDUCT(samples here, here and here, probably best of all  StackOverflow ) — A well-written code of conduct clarifies an organization’s mission, values and principles, linking them with standards of professional conduct.  No action is needed — link to the code of conduct in the Los Angeles .NET Developer Group meetup page and make sure that all confirmation emails from meetup regarding group events feature a link to the group code of conduct page.  Expected Behavior and Unacceptable Behavior.  Unacceptable Behavior i.e. No interfering with a presentation (questions are allowed, answers on behalf of the speaker are not!)

ENCOURAGE OPEN COMMUNICATION:  Give everyone a chance at your meeting/presentation to stand up and introduce themselves and present a question and/or provide feedback at the END of the meeting.  Maybe provide cards or paper so they can remember their question. If participants do not want to wait for a Q&A at the end of the presentation then a skilled moderator might be the alternative to assist with this effort.

“OLD SCHOOL” DEVELOPERS:  It’s very important to have our “old school” developers share their knowledge and also encourage them to return, but their communication should be held until the end of the discussion.
When the attendee share their knowledge during the discussion, it tends to over-stage the presenter and presentation.  Sometimes “old school” developers can have an approach of “greater knowledge,” that can be intimidating for a new developer or someone that is trying to come to a group/community for networking and to feel part of common knowledge.  I attend several other groups and definitely do not feel this kind of intimidation.

PRESENTERS:  I have noticed that when the Los Angeles .NET Developer Group opened up the forum to first time speakers (“lighting talks”), the questions/comments were more “attacks” not questions. It is already hard to get on stage and speak in front of audience, but when the audience is so scrutinizing it becomes impossible. Instead of letting the speaker convey their point, attendees are focused on criticizing unimportant details to the presentation.  As a first time presenter, this can be disheartening; and will definitely make one never want to get on stage again and even worst not return to the group.

OPEN FORUM TIME:  Many of the members have a lot to say about the profession but, don’t have enough time to prepare or don’t have the language capability to speak on stage. So why don’t we have a 15 minutes “Rant” or “Roast” or “Exciting News” or “Favorite New Tech” or similar where any member can just stand up (or even keep on sitting) and say anything he/she wants about the dev profession or the tech industry or Microsoft or the .NET framework and so on. This might be time to open discussion and initiate a networking relationship between members.

OUTREACH: We need the “new blood” to attend and stay. Difficult to market due to a bad stigma on the Microsoft tech. So maybe joining forces with some other group in other technologies that might cross over could help cross-pollinate the groups. Like integrating the .NET world with front-end frameworks and maybe have a joined session with JS.LA or similar.  Since .NET code is now running everywhere, we might be able to do something with some linux groups out there.

So here it is…food for thoughts. Chime in!

Collaboration with Angela On The Move.

0
DevQuest

JavaScript Framework Syndrome

Posted on by emadev

Learn to let go…and avoid the “fatigue”.

The other day I attended the local Elastic User Group meetup and one of the presentations was about the direction that the new Kibana UI Framework is taking.  CJ Cenizal, an excellent presenter, introduced us to the new UI framework on which all Kibana development will be based upon.  The main point was that the company will now move from AngularJS to React; reason being the idea of making the Kibana UI fully componentized.  Despite the fact that Angular 2 is the natural progression from AngularJS and it is completely component based, they still opted in favor of React.  One other important reason, CJ gave us, was that the core team of developers were very comfortable with React and somehow less comfortable with Angular2, which in my opinion made total sense.

As you can imagine, the questions from the audience kept on coming: “…why React when Angular 2 is also component based?”, “…we like React, but we think the ecosystem of Angular 2 is larger/stronger and would work better for Kibana…”, etc.  CJ did a great job in answering all those questions and more, but the more he was making the point for React the more the audience was questioning their decision.  I was getting irritated about it; I am not a particular fan of React nor Angular 2 per se, but I was respecting and understanding CJ and his team decision.  At that point it dawned on me that the guests where not trying to question the decision, they where trying to find within themselves the  answer to the ultimate question: “What JavaScript Framework should I use for my projects?”.

If you pay attention to the community and read enough blog posts you realize that the “masters” out there always respond to the above questions with something like: “…it depends.  Use the right tool for the right job…”.  But we do not like to hear that as it requires a lot of prep work before actually building something, we want a straight answer that we can apply all the time to everything (or almost everything).  I want an expert that tells me: “Considering all options, pros and cons, just use Angular 2 (or Aurelia or React or Vue or …)”.

I know that the audience was just looking for the final answer;  they were just trying to finally breath and stop evaluating all scenarios; but mostly they just want to code and PRODUCE.   They wanted a “resolve”.  Not that I am immune from this JavaScript fatigue, but somehow the above realization immensely helped me to calm down; and just trust that the framework decisions, taken at that moment, is the correct one for the time being.

I hope this “2 minutes with the shrink” will help you finding piece in this quest. Please leave a comment and let me know.

0
DevQuest

Just build it… or not?

Posted on by emadev

Sometimes it is hard to start a blog post, you have all what you want to say in your head but you cannot find the “Program/Main” or entry point of your thoughts. So here I am, I will just list what is in my mind and hopefully it will make sense at the end.

Ok so, the app you are working on it is built with different tools and/or frameworks and you are asked to implement a new feature. The first thought is: “Let’s see what this framework has to offer”, or “let’s see if there is already a widget in this toolbox I am using here,… etc.”. But when you start digging into it you realize that there is something similar but not quite what you need, or the design is completely off, or the back-end communication is not fitting your model. So you dig dipper, you start hacking into the widget/control or other feature/functionality and you say: “…ah, ok this work this way but I can change it here and make it work…” then you find another obstacle and you solve it and so on. Did you ever get to the end of this process with a result that the only thing it reminds you of is Frankenstein? Yes, something like a patch work, something that…. if you do not have enough “electricity” you cannot give it “life”, something that can break any minute.

At that point you spent hours if not days through documentation and testing and writing code, and you think:”Is it worthy?….shouldn’t I just build it?”. Well , maybe. But then thinking of: “do not reinvent the wheel!!”, “use and re-use existing code”, “someone for sure have already done the work”, “isn’t what Google is for?….” one is starting to have doubts. So I guess my point is: when do we stop searching and start building? Great question isn’t it?

I guess sometimes we go too far in our search for the solution because we think that out there there is always someone better then us, someone that has already thought about it and made a great product. So is it a problem of self-confidence? But then if you have too much of it you end up putting too many hours into it and your boss will complain. So again, it is hard to find the right balance.

I leave it at this and I am open to ideas and suggestion. Tell me what your mental process is and share it with the community.

0
DevQuest

Where it all began…

Posted on by emadev

A few years back I inherited a brand new web application.  It was commissioned by a desperate company looking to speed up its work flow, they wanted to be more efficient and deliver proposals worthy of the product they were selling.  The assumptions behind this application were of being versatile, fast and comprehensive; it was supposed to be developed in a .net environment based on the new MVC framework (cutting edge at the time) with the latest bells and whistles, but instead…

When I was first exposed to the app, what I noticed were the eternal post-back times and URLs with .aspx extensions, which means it wasn’t a MVC app.  Ding, dong…alarm… nothing looks like the assumptions!!!  At the same time I kept on hearing frustrating remarks coming from the company employees: “…come on! Load it already!  I need to make a call!  I need to send this proposal!…..” and so on.

So I started diving into the source codes and there it was, an old fashioned Web Form application with any possible little logic handled by the server.  Things like input a quantity on a line item in an invoice and wait for the server to calculate the total to then add the item to the invoice item list and finally save the invoice.  All clicks were post-backs — a nightmare!

An overall rewrite was needed but budget and timeline did not allow it, with very little resources and the need to speed up all processes A.S.A.P., I had to compromise and try to transition the app page-by-page, section by section and module by module, where possible.

This process (still ongoing today), despite being quite challenging, turned out to be full of interesting topic of discussion for any developer in the process of transitioning from a legacy application to something more modern (I know….what is “modern” today in our field? …. new frameworks and cutting edge trends are already old the moment they hit the market….).  Therefore, I decided to document as much as possible in this blog.  And so emaquest.net is born, a Chronicle of an evolution, a developer quest.

I hope you’ll enjoy…

0