Want to geek out over lunch? Interested in learning something new? Come check out our speakers and come hear about something fun. Every couple of months we host a meeting about something development related, be it security, a programming language, or a UI Framework. We provide the food, you provide the seat warmer.Sign Up Now
C# 7? There are 7 seven versions? Seriously? Who needs 7, because we’ve seen how well 7 of anything has worked out. Take those movies where the main character, who has serious daddy issues, runs around swinging a really large glow stick with his two pet robots trying to “save the galaxy”. They enthusiastically announce, “Hey come see part 7 in the series!” and then BAM they kill off one of the major characters, by his emo son no less, and we were all sitting in the theatre like, “What happened?” and who’s to say C# 7 isn’t going to do the same thing? It’s going to lure us in with a false sense of childhood security and then smack, “we broke your favorite feature!” and I don’t think I can handle that. I don’t need to suddenly find out that C# 7 suddenly axed Reflection or some other cute fluffy feature that’s my security blanket for keeping bad requirements away, so maybe I should stop with 6. It would be a nice conclusion for the language. Throw in a snappy ending credits song and maybe a space explosion, and people could be really happy ending C# there.
Let’s be serious though. You really want to see how the story continues, and maybe they didn’t remove your favorite go to code Swiss army knife after all. Stopping at 6 would be nice, but you don’t want to live in the past. You want to see how the story continues. It’s like eating that second to last piece of bacon and deciding that even though you really want the next one you’re “satisfied” with what you have. SAID. NO. ONE. EVER. You want to know if that next piece of bacon will make you even MORE satisfied than before. Is that gluttony? Maybe, but it is a gluttony of porky awesomeness, and if you don’t get it, someone else will, and then you’ll be strolling around secretly screaming at that person, “You will rue the day for taking MY BACON!” (Rue the day? Who talks like that?) Maybe it would be better if you did come, and claim that last piece of bacon for yourself.
It’s that time again. Yes, that time when we “nominate” someone to stand up for an hour and ramble on about some topic while we stare and eat pizza. What type of pizza you ask? Pizza with bacon. Who doesn’t love bacon? Everyone loves bacon. You know why? Because. It’s. Bacon. And on the off chance you don’t love bacon, we’ll have other pizza things too (we got you covered). But don’t worry, for this meetup, you’ll be an honorary bacon lover with the rest of us while we sit and watch, nay STARE, at that ONE person at the front of the room. We will be a sea of fanatical eyes judging every breath gasping for air, every syllable crying for help, every incorrectly indented line of code written as the presenter wonders if we are actually collectively whispering “Dear God what is that thing?” as it echoes in his perfect ears. That is what being the presenter means in the face of a legion of bacon loving fanatics. We leave him in misery while he tries to explain some concept in between our gnawing on awesome bacon laden pizza.
And the best part about it? That person can’t have any pizza, because you can’t talk and eat at the same time. It’s like an hour of torture watching bacon disappear while he can’t have any. His ability to explain his sacred topic is the only thing that will save him that precious slice he so desperately covets. What do you say his topic is? Read below, find out, and judge for yourself if he deserves any bacon infused pizza.
What is this style of programming taking the world by storm? How do people write functions that are only 5 lines long but seem to do something that would take me at minimum 100 lines to complete? What's happening to how I write my programs?
These are just a few of the questions people tend to ask when chatting about functional programming. This talk is geared toward introducing the functional paradigm. The goal is to show how functional programming can make you a better developer, and at the same time, using multiple languages, show how much more efficient and natural feeling functional programming can be.
Have you ever heard the phrases “beauty is in the eye of the beholder” or “I like what I like” when someone is dismissing your design? Too often good designs are dismissed for aesthetic differences instead of appreciated for its intrinsic value.
Many features of good design are objective, not subjective, and can be either qualified or quantified with predictable results.
Together we will delve into the psychology, physiology, and mathematics of design principles for two key purposes:
On March 7th Visual Studio 2017 will be available for download and Visual Studio itself turns 20. Come join us to learn about what's new in the next version while having pizza and cake! (At least come for the pizza and cake. We've got a lot.)
Ever wonder why teams use Code Obfuscators? What do they do, and what are they for? We’ll look inside PreEmptive Solutions' Dotfuscator to see what it does, what it protects against, and some pitfalls when using it. To familiarize ourselves with its process we’ll look at some which replicates some of the functionality, and compare it against the commercial product.
Understanding the importance of putting the people before the process, and the process before the tool in order to achieve successful continuous improvement for any organization.
No, not really. You need to do user experience research involving the appropriate people as you design your website, product, or service. Come and explore the use of research tools to help you learn more about how people think and work. Join us as we walk our way through a User Experience Design process for Wally, who wants a web site to sell his wallets. He thinks all he needs to do is to put his content into the format of an already successful e-commerce site. Learn about potential customers through activities involving the session attendees and see how this information can be used to create a better design for Wally’s products. An informative and fun introduction to the UX process for anyone interested in creating great products.
Developers commonly face the problem of troubleshooting issues in a production environment with little or no information to accurately determine a solution. Policies prohibit needed access to servers, error logs often show an incomplete picture surrounding issues, and finding the root cause with a partial view of the entire system is frustrating and time consuming leading to increased stress and a longer time to resolution.
Organizations often deny additional expenditure for something not directly enhancing its profit and forces its staff to manually search for a problem’s root cause. The ramification of this is an organization’s failure to consider financial implications stemming from system under performance and outages. Ultimately, they perceive each issue and its resolution as a necessary expense and view finding the issue without incurring additional costs as positive.
With this, developers must find a way to reduce the effort to track and analyze potential issues without incurring additional expense, and by using various systems from open source projects along with relying on small changes to programming, it becomes easy to locate, analyze, and report problems in a clear and meaningful way which reduce downtime, stress, and overall cost.
In functional programming we often use pipelines and function composition to let data flow through a series of operations in a concise, readable manner. Object-oriented languages don't typically support this style of programming but it's possible to achieve a similar effect through method chaining and, by extension, fluent interfaces. Using these techniques however, is seldom an option as they are both architectural patterns that rely on having been deliberately built into the types with which they're used. This is further complicated by the typically statement-based nature of object-oriented languages. But all is not lost. In this talk we'll borrow a few ideas from functional programming so we can not only easily achieve a similar effect in C# but also fix existing broken fluent interfaces such as the one exposed by the StringBuilder.