Meetup Recap: Fullstack JS (MongoDB)

Last night I attended the Fullstack JS meetup, which is hosted by/at Zeeto Media. Zeeto looks like such a fun place to work; I frequently check their job board for a chance to apply as a junior dev. It's located in the heart of downtown San Diego, and its office has some pretty views of the city. Although this meetup is downtown, they have reserved free parking in the lot adjacent to the building which is always convenient. Come a bit early and you'll be able to mingle with snacks and drinks too; there are about 40 attendees. I was happy to meet new people, but also see some I knew from other meetup groups too! This community doesn't feel so intimidating anymore! Normally this meetup occurs once every month and consists of different talks on various JS subjects, however lately the focus has been on the MERN stack: MongoDB, Express, React, and Node. We will be covering this stack over the next few months and I think we're even building an app together, so be prepared to learn! The previous meetup was an overview of MERN (which I missed), and last night's meetup was specifically an introduction to MongoDB. 

To be honest, I was torn between attending this meetup and the Ember101 workshop. I have little knowledge about both subjects, and unfortunately they occurred at the same time. But I'm happy with this decision because I learned so much! Michael Roberts Jr did a great job explaining MongoDB with live code and examples. Per usual, I will briefly list some of my notes below: 

  • MondoDB is a noSQL database, which means it doesn't use SQL as its primary language to query the db or do CRUD operations.
  • It leads itself to rapid prototyping and good user experience for getting data quickly.
  • It's safe to use for production only in certain cases, as it favors performance over transaction/accuracy. For example, it's not ideal if you need to keep record of something super important, like banking info, as it may occasionally lose records. 
  • It's document-based, instead of relational tables, which is favorable because they are stored in the way you'd like to consume it. But this puts more of a burden on you because you have to make sure you are maintaining relationships. It is not going to enforce a schema on its own. 
  • Based on the examples given, it seems relatively easy to understand/pick up. Dare I say easier than SQL?
  • Its primary core language is javascript. Its queries/commands look like js. The commands are intuitive and the data is stored and returned in json format. In particular, the data comes back as a block of json which can be hard to read. But there is a "pretty" command that puts the json in a listed view, like we are more familiar with.
  • It's easy to set up. You can download or use brew install it, leave it running in the terminal, then open another terminal and run the command "mongo" to connect to the local host. It'll then enter into a shell that you can use as a REPL. 
  • There are also GUI interfaces, such as robomongo. It's helpful to use robomongo to learn the commands and see exactly what they do visually, before attempting to do so in the terminal.
  • You can use mongolabs for bootstrapping smaller projects for free. If you want to go live without a lot of traffic, Michael recommended digitalocean

Additionally he gave live examples of filtering and projecting, as well as CRUD commands. In particular, the "create" command interested me because there is no command to create a db or collection in the terminal. Instead, if you give a command to store something in a location that doesn't exist, mongo will know that and implicitly create it for you. To learn more, Michael suggested to forget everything we know about SQL! The night ended with a Q&A session, as well as with introductions of first timers. 

Testing, testing, 1,2,3... A Simple RSpec demo

I was once asked during an interview about my familiarity with testing. I was honest; it's something I'm familiar with (TDD, BDD, etc), and have had to read/run/pass a bunch (previously written for me) whilst at Learn Verified, but ultimately it's something I haven't had much experience WRITING ... yet. (And of course I added, "But I'm looking forward to learning more about it!", which is true). Side note: they haven't called me back...yet!

I just finished my Angular assessment. It went well but there are definitely some bits about my app that I will change, such as adding a review model in addition to my book model, so that one book could have many reviews. That's slightly annoying because it was how I originally set up my project. I should've listened to my gut.

Anyways, I appreciated the extra time and attention the examiner gave to go over testing. So I'm here to jot down some bullet points half for myself to remember everything we just covered, and half to share/introduce the ideas behind testing to you. I'll insert some screen shots where applicable. For this example, we used RSpec to test my book model. This example does not test Angular, though I'd imagine the same testing concepts apply? More on that later...

"RSpec is a behavior-driven development (BDD) framework for the Ruby programming language It contains its own mocking framework that is fully integrated into the framework based upon JMock." - Wikipedia
  • Testing is a way for you to literally test your code, making sure it works exactly as you expect. This seems obvious but the way to go about it is not, speaking for myself that is. What do I test? When do I test? How? Depending on the person, you'll receive a different response. If you are heavy into TDD, Test Driven Development, you will likely argue that you should write the test before you write the code, making sure it all passes along the way. Others seem to be more relaxed about it, testing afterwards. Some test everything, others don't. I'm not sure which category I'll fall into yet but I know that either way, testing is an important and helpful tool.
  • Testing gives you a chance to pretend you're a malicious hacker, (or just just an average user), entering all of the incorrect information. It's kind of fun because now is the time you can get creative and think up all the ways your app could go wrong. Now is your chance to efficiently enter bad information and find out how your code will respond. Will it respond in a way that you expect? If it doesn't, why not? Fix it. No surprises here! Defensive programming.

So for this example, we wrote sample code to test my book model. The code will return all the books if its rating is above a certain number.

The next screenshot is my seed file. You'll actually be testing dummy data, not the actual database.

After we got RSpec set up, we wrote a dummy test, "expect(true).to eq(true)", just to make sure it worked (it did). Then we got to writing a real unit test. For this, a "describe" block is set up. Inside of it, you'll declare a scenario and the outcome you would expect of it. In my first test, you'll see that we expected that out of all the books, only one would have a rating above three. If I wanted to take this test even further, I could've said which title that'd be. 

When we ran the test in the terminal this test failed, which surprised me.

I expected this test to pass, but had forgotten that we weren't testing my ACTUAL database; we were testing my seed file. This made sense because as you can see if you look closely, there isn't even a rating attribute in my seed file! So we added one to "current_book", and it passed! 

But actually, before this test passed, it failed again which surprised us both. This time it surely should've passed! Pry to the rescue! We placed a binding.pry in the test file, to check the data it was playing with. In this case, when we checked Book.all, we expected an array of my dummy data but received an empty one instead. hmmm...

The examiner helped here because there was actually something wrong with the way RSpec was set up. He added the following to my rails_helper.rb file, then it passed: 

"config.before(:all) do
    load "#{Rails.root}/db/seeds.rb"

We weren't done yet though! The second test we created to see what would happen if a user gave a book an "unacceptable" rating, such as a negative number.

Screen Shot 2016-04-21 at 3.33.25 PM.png

As you can see, out of the 2 tests/"examples", we have one that failed: "Book handles negative input correctly". This surprised me too, but did it really fail? I expected zero but got one, why? Perhaps this is the outcome I wanted... perhaps it's not. Do I need to debug this? This is an example where I can see what would happen on this particular scenario, and evaluate the outcome as acceptable or not. Perhaps I want to change my code to throw an error, not allowing negative number ratings. Or maybe negative numbers are OK because the book is really THAT BAD. That's the beauty of testing; they help to eliminate surprises and allow you to get quite intimate with your code.

In closing, if you're new to testing, read as many tests as you can. Thankfully I have loads of labs to consult as a refresher, but if you don't have access to that, Team Treehouse offers a great explanation about what RSpec is and how to write tests with it. Or checkout these docs. Also note that RSpec is not the only way to test.

Understanding AngularJS: My Notes

As stated before, I had mixed feelings about Angular. I was instantly smitten but confused by the actual application of it all at the same time. So I thought I would just share a collection of notes I've taken over the course of building my app in case you were struggling too. I'll also insert snippets of code from my app for demonstration purposes, where applicable.

I am by no means an expert, but I am a pretty good note-taker. Please correct me if I'm wrong with anything you see here via the comments so I can update this post (and learn) accordingly. By the way, if you are in the San Diego area, Girl Develop It will be giving an Angular JS class on May 2nd, which I'm really looking forward to! Perhaps afterwards I'll come back and update this post with more notes, so expect this particular post to change quite a bit from its original post. 

What is Angular JS?

It's a front end JavaScript framework that allows you to create responsive, dynamic websites. You should know HTML, CSS and JavaScript to use it. Typically, Angular will communicate with a backend application that parses its data into JSON for use. So instead of a website refreshing the entire page and assets, Angular allows it to only refresh the parts with the new data/information, allowing your page to react super fast! 

Helpful Bits and Bobs to know:

  • Modules - Where we write our code, and how we encapsulate our code for maintainability purposes. It's also where we define any dependencies we may need for our app. In the example above, I defined my Angular app by name ("app"), then listed (aka "injected) its dependencies ("['ui.router', 'ngResource', 'templates']").
  • Directives - We can add behaviors and bind javascript code to our HTML via Angular's "directives".  There are several built in already, but you can also create your own. In my example, I am telling the HTML to use my module named "app", via a built-in Angular directive "ng-app". When this document loads, it will run my "app" module. Any HTML following this directive will be treated as part of the Angular app. My personal fav built-in directive is "ng-repeat", exemplified below. "Ng-show" is pretty helpful too because I could allow a button to be visible if a condition is true, for example. "Ng-submit" is another worth mentioning. The example below says "When this form is submitted, call my editReview function (which is a custom built function that posts to my Rails API, saving the Angular data submitted via this form)". Get to know directives; they're all very useful. 
  • Expressions - How we insert dynamic values into the HTML. They will be in between double curly braces, such as "<h1>{{"hello" + "world"}}</h1>". When the page renders, you'll see "Hello World" as the h1 header, interpolated from the expression. It will also evaluate other data types, such as {{ 1 + 2 }}.
Screen Shot 2016-04-20 at 12.53.37 PM.png
  • Controllers - Help us get data onto a page and it's where we will define our functions and values. Note that its name must be Capitalized and it must contain the word "controller" as well. In the example above, I've created a "MeetupsController" to capture API's "results", in a variable called "events". For this example's sake, I then use an expression in my HTML, such as "{{}}" to print the name of the event, which evaluated from the data represented in JSON, below.

In combination with a "filter" (which I haven't explained yet), and a built-in directive called "ng-repeat", when the controller is called I am able to print selected information of the "events", as shown below. You can also give controllers aliases directly in the HTML or when defining the controller itself (which I've done below on line 43, but let me not get ahead of myself and complicate things). However something important to note is that the "scope" of the controller only exists where you define it. So had I called "ng-controller="MeetupsController as meetups" on a div element within the HTML directly instead, I could only access {{}} from inside of that div alone. 

app.js file

app.js file

  • Filter - is a type of service. The above example is encapsulated inside of another div where "ng-model="" is defined within an input element. I call my custom "" filter (matching the name of the model) in ng-repeat so that when I type in the search box (aka the input field) Angular will display only the events that match my search! But Angular also comes with built-in filters, such as formatting dates which you can see detailed in the "date" code of the example above.
  • Services - Gives your controller additional functionalities, such as accessing and retrieving JSON data from an API via injecting a $http service. The built-in services all start with a "$". They return promise objects, such as .success() or .error(). 
  • Dependency Injection
  • Scope
  • Two-way Data Binding - I love this feature. This allows you to type in a form (for example), and see a live preview of what you're typing. It's pretty exciting to see demonstrated
  • Validations - 

This post is not finished! I'll continue to update this post in the upcoming weeks!

Angular Frontend/ Rails Backend

Above is a walk-through of my final project! Requirements include:


  1. Must use an Angular Front-End that includes at least 5 pages
  2. Must contain some sort of nested views
  3. Must contain some sort of searching as well as filtering based on some criteria. Ex: All items in the "fruit" category, or all tasks past due
  4. Must contain at least one page that allows for dynamic updating of a single field of a resource. Ex: Allow changing of quantity in a shopping cart
  5. Links should work correctly. Ex: Clicking on a product in a list, should take you to the show page for that product
  6. Data should be validated in Angular before submission
  7. Must talk to the Rails backend using $http and Services.


  1. Backend created with JSON that accepts and stores the data for Angular

I was inspired to create a localized version of the "Girl Develop It" website, for the San Diego chapter. It's a group that I'm very proud of because of its welcoming environment and offerings of beginner-friendly classes at an affordable price. I've made friends here and it's great to see how much we've all learned. Last night people were writing JQuery when just a few months ago some haven't even heard of it before!  I literally invite every woman I know to this group, regardless if they are local to my area or not because they have chapters sprinkled all throughout the US. And if there isn't a chapter near you, you should totally start one! 

So I wanted to capture the essence of their original site, but highlight the features of our local chapter to include functionalities surrounding our book club, job posting, and meetup groups. I am happy with how it's turned out so far, although I ran into a few roadblocks that I'll briefly discuss below. I also have a few ideas for how I want to improve it. My assessment is this Thursday, which will also mark the completion of the Learn Verified curriculum, if passed! Yahoo!


In general, Angular took me a little while to get the hang of, so much so that I consulted outside resources to receive the same information in multiple ways. I used Lynda, Code School, Code Academy, and of course its documentation, throughout the building of this app. I was instantly smitten by its features such as two-way data binding, nested views and ng-repeat, all in support of a dynamic one-page web app, but I frequently went cross-eyed when it came time to building this app from scratch. 

The first challenge I had was figuring out how Rails and Angular could work together. I found this Youtube video and blog post to be extremely helpful; both resources use Bower to add Angular to a Rails app. 

The second and probably biggest challenge I faced was making API calls to the API. I kept getting a "CORS" error, which had to do with authorization even though the information I wanted to access is public. Although I'm thinking about it, I purposefully didn't create logins for my app so setting up Omniauth for this wasn't practical. Eventually, a solution was found using the meetup client gem

I also kept changing the structure of my database to suit the needs of my app, which I'm still unsure about. I had to do some googling about because Angular authentication wasn't covered during this course. For the purpose of my assignment though, my current setup fulfills the requirement of being able to save Angular data via a post to my API. However, previously it was set up with two models, so that a book could have many reviews. This was so that everyone from our group could submit a review. Possibly we could have an internal group rating for a particular book with this data, for example. Currently the real website is accessible to everyone which is why I originally wanted to mimic the same feel. But then I changed it because I think I want to create user roles, so that only admins can add a book to our reading list or post jobs, which (I think) would mean that each user could submit/record their own review/rating. Now the book and review is in one model with requests to update the API accordingly. I'm still undecided, but I hope to get helpful advice during my assessment and polish it up. 

Meetup Recap: FullStack Talks

I realize that I declare almost every meetup I go to as a "favorite", but Full Stack Talks truly is at the top of my list mainly because I ALWAYS leave it learning SO much. Yay for free education! It's hosted by Planning Center Online, which is a Rails shop in Carlsbad. Great energy consisting of games, beer, snacks, and an impressive stage setup. Sadly, I hardly make the 1hr trek north to attend, at least not as often as I had originally planned for. But I was extra motivated as I had invited a friend from my cohort to attend. He recently moved to San Diego and will be the first person to actually finish our program! Smart guy, great developer, and now a new local friend :) (PS. If you're reading this, you are just as lovely in person and I'm so glad to know you!) What's also fun about attending this meetup is that the more involved I become with this community, the more often I run into familiar faces and even people I know which makes me feel like I'm no longer on the outside staring in; I'm apart of it. Whether that be from Rubyconf, Railscamp, volunteer events, or other local meetups, it's always fun to reconnect. But my new goal is to speak ... one day. Maybe not anytime soon. Thinking of standing in front of all those people already makes me sweat, which means I should do it let's be honest. It's definitely on my bucket list. 

It's not even 7AM. I haven't had any coffee at all, but I'm just so excited to share with you today. I  had to get up and write a recap! Quick reminder though, if you ever miss an event and want to watch it live stream, you can subscribe to their youtube channel. Or you can just read my blog and I'll try my best to summarize them! 

1) "Phoenix From The Ashes: Transitioning Rails to Phoenix" by Michael Chan. I really like Michael, even before his personality shined from the podium. Michael helped me during the ReactJS training I attended a few months ago, which ironically was also during the time I got laid off which I'm only mentioning because his help was even more appreciated on that particular day of personal emotional turmoil, unbeknownst to him. He's got a warm and welcoming personality that I'm grateful for (Thank you). I enjoyed his presentation style and slide designs too. But biases aside, he gave a talk about Pheonix after tinkering around with it for only 2 days, and humorously compared it to his experience using Rails. This was my first introduction to Phoenix so I learned a lot and will just briefly highlight a few points. 

  • Phoenix is to Elixir as Rails is to Ruby. Phoenix is a framework for a language called Elixir, which I've been told is friendly like Ruby but is more function based. Everything is a function. 
  • Phoenix likes JavaScript. 
  • Phoenix is easy to set up with its thorough documentation, that is also visually pleasing to the eye. 
  • "Mix" is a helpful command vs the Rails/Rake confusion.
  • Semantic gemfile, routing, and single controller names. 
  • It comes with a default pages controller, unlike the magical Rails landing page.
  • " |>" is called a pipe and it feeds the output of one expression into another. Pretty cool.
  • It's fast!
  • Some cons include Ecto, which can be comparable to Active Record but it's much more limited in power.  

If you are interested in learning more about Phoenix, which seems like it has potential to shake up the Rails world, he recommended "Programming Elixir" by Dave Thomas. 

2) "Chrome Dev Tools: JS Profiling" by Tanner Mares. I'm pretty sure Tanner and I have crossed paths before too, circa Rails Camp West 2015? Again, this was another great talk with lots to learn. I've gotten quite cozy with Chrome's developer tools during my programming journey, but never did I find any purpose for its "Timeline" and "Profile" features. Which also made me realize that there are probably more helpful features it offers that I have no idea about. Why haven't I taken the time to look?! Tanner to the rescue!

  • The timeline and CPU profiler are capable of finding expensive JavaScript executions and excessive rendering, which slows down a site. Slow load times = bad user experience. Your user will probably never come back to your site again so this is important. 
  • I appreciated the live demonstration of these tools, which included refactoring his code to improve performance with an obvious before/after detailed in the dev tools. One thing to note is that the Timeline results will refresh with every page refresh while the Profile tool will persist. 
  • These tools are so specific that you can record and zoom into an event, either by color coded line/bar graphs or list view, that will detail the exact line(s) in your code causing the lag. I prefer the "heavy" view because it ranks events. Easy. There should be no more time wasted on guessing what's wrong. We can see exactly what's happening. 
  • FPS = Frames Per Second and the higher the number, the better. Though you'll want a low CPU.

If you haven't been to this meetup, I highly recommend it. Learning is fun and this one never disappoints. 

Rails Camp Round 2 (East)

I was handed an eye mask and ear plugs as I boarded the red eye flight towards JFK. I've never flown a red eye before but besides the turbulent moments, I was able to sleep the entire way and wake up in the city. #winning. I love New York! I am totally that tourist who gladly sports the I <3 NY shirt, although this time I would hardly spend any time in the city. Instead my time would be spent two hours north by bus, in Catskills, for my second Rails Camp. 

Rails Camp has easily become one of my favorite events to attend. I didn't think I was going to make it this year, but I'm grateful to those who made it possible for me. Because of it's size, it's a quite intimate event that builds the community and I would encourage everyone to experience it at least once. It was great to meet others of way more experience than me, and see some familiar faces, but this time I also met a few just starting their journeys too. It was an interesting feeling for the tables to switch, with me sharing my experience and giving advice to a beginner. Pay it forward! Last camp I barely knew anything. This camp I was working on my final project consisting of an Angular front end and Rails backend! Next camp I hope to attend as a professional programmer!

I also love the fact that there are camps EVERYWHERE. If I had the means I would totally check out the one in Scotland! But the next one in the USA will be in Stanely, Idaho which looks absolutely incredible as well!

I could honestly tell you, especially as someone who doesn't identify herself as a "camper" or outdoorsy-type, I would have never camped out at Catskills, NY, or Stanislaus Forest, CA, had it not been for Rails Camp. Though allow me to clarify that both camps provided cabin-like lodging with hot showers, toilets, and prepared meals! Think summer camp for adults. Both experiences allowed me to appreciate nature, make new friends, and realize that it's OK to step outside of my bubble. Not only is it OK, but it's absolutely necessary.

Rails Camp is a place where you can come as you are and be accepted. Never have I ever felt unwanted, or uncomfortable, even though I tend to be on the shy/introvert side of the spectrum. It's a welcoming environment that supports and encourages diversity. There is usually a special (discounted) ticket price reserved to do so. If you want to hack on a project, or dare I say actually work... you can. If you prefer to drink (BYOB) and leave all your work/computers/tech gadgets/worries behind... you can! Want to go hiking, canoeing, sing your heart out over karaoke, learn how to blacksmith, or sweat it out in the sauna? ... You can! (Well, at Rails Camp East 2016 that is). This time I chose to spend majority of my time working on my final project, but I also took some breaks to say Hi to Lucy (the goat who think she's a cat), get (unintentionally) lost in the woods , feel the warmth of the campfire, learn about blacksmithing, and attend a few talks (which are all given on an informal volunteer basis)! There are also opportunities to identify yourself as a job seeker and connect with those who are hiring. And I'm most grateful to those I've met who've been willing to mentor me and/or assist in a code review. (Thank you).

My one and only regret this time is not taking home the jar of Vegemite, a newfound love of mine. 



Rails App Debugged

Sometimes bugs are super simple and staring you in the face. Yesterday I blogged about adding JQuery features to my Rails app, but pointed out that I had a bug. I tried so hard to resolve it yesterday to no avail. But this morning, as I was explaining my  problem out loud to someone, all of a sudden the lightbulb went off. The solution to my bug was extremely simple! 

My images weren't changing because of this line of code: 

After using the inspect tool, I realized that it had made a call to my API and grabbed the correct image, however it was putting it in between the <img> tags instead of replacing my src attribute, which makes sense as I told JQuery to use it as text. My bad! The computer was simply listening to my orders!

This was such a simple fix that I'm embarrassed I didn't see it sooner! All I had to do was tell JQuery to replace the src attribute with the correct data!

If it were a snake, it would've bit me!

Rails App Updated with jQuery Front End

Hello! I know it has been a while since my last blog post. How naughty of me! 

A lot of learning has been going on recently in the form of Javascript, JQuery, APIs, JSON, and AJAX. JQuery Tic Tac Toe is no joke! I've also been learning Angular, but we'll talk about some other time. 

For my latest project, I had to extend the functionalities of my Rails app to include building an API, making calls to it, and using JQuery to update my page without refreshing it. I used a gem called Active Model Serializer to render JSON for my pins, and then was able to add dynamic features with the help of JQuery and AJAX requests. Initially I was super confused by what was being asked of me. I thought I needed to find a random API and incorporate it into my app. But thankfully the details were clarified and the rest was smooth sailing! To be honest, I had a lot of fun building this one, however I do have a bug that I still need to work out, as demonstrated in my walkthru: 

I am very close to crossing the finish line with Learn Verified! I just have the Angular section to complete, and then I THINK I'm done! I met with one of the career counselors on Monday and am really looking forward to working with her because finding a Jr. programming job on my own has been difficult! I'll be sure to share the details of my job hunt once that begins. I actually had my first "technical interview" ever today, but it was awful. No, I don't want to talk about it

We Code Too - Rails Assessment

I can't believe I've finally made it through Rails! I have learned so much, but am also aware of the points I need to keep practicing (ahem, associations). This has been a roller coaster of a journey for me, but I'm having fun! And today I present to you my final Rails project for Learn Verified. 

Lately I've been a little irritable about diversity in tech. In particular, I hate it when I'm a) the only girl, b) the only person of color, or c) all of the above at tech-related events. So that inspired me to create "We Code Too": a place to collect diversity-friendly tech resources a la Pinterest style. But really, this app could be used to collect anything, especially if I add a feature of a user having different boards where pins could be assigned. For now, I kept it simple. 

In my demo, the only feature that oddly isn't working is my category list (I swear it worked before). I'm thinking I'll have to go back and use a datalist element? I want my user to type in a category name to create a pin category (ie. blog, website, meetup group), and then choose from the list of created categories. This is an example of a nested form. Of course, there should also be a validation there to prevent duplicate categories. hmmm...

Some cool features (gems) to mention are: 

  • Omniauth - A user can sign up and sign in with their facebook account.
  • Devise - User authentication system that has advanced features such as resetting your password (currently not activated) or having a new one emailed to you (also not activated).
  • Paperclip - For image uploads.
  • - Uses images of bears as a default pic, if one isn't uploaded. 
  • Bootswatch - Themes for Bootstrap!

Besides needing to fix my category feature, I would also like to deploy this app on heroku. My only problem is that heroku prefers postgres. My app uses sqlite3. I started to tinker with this discrepancy and totally broke my app. So let me get through my actual final assessment before trying again! Once I figure that out, I'll be sure to share it here so you can have a go at it! 

Am I a unicorn?

Sometimes being Black feels awkward. 

While thus far everyone seems to be welcoming of me, and nice to me, during my programming journey, I can't help but to feel some type of way about being in a room full of people, as the only Black female there. The only Black person there actually. Sometimes even the only female there too. 

I wonder how the workplace will be. My experience is limited to tech meetups and events though. Thank goodness I've discovered GDI and POCinTech

Perhaps shame on me for "seeing color" and/or gender? Is this normal? Can I talk about this without being afraid? Where is the line defined for being honest and being politically correct? Should I dare cross it? 

The thing is, technology is our future. We all need to be a part of it. Diversity is important.

Sometimes I feel like a unicorn, but not in a good way. Although I'm proud of who I am and what I'm accomplishing; don't get me wrong. That's not going to stop me. I just wish that being a unicorn wasn't always so dang obvious.

I don't want to just talk about it though, and I definitely don't want to whine. I've got to figure this out, the Why's and the How's. I look forward to being part of the solution... somehow.