Google Flutter goes Beta at #MWC18

Google Flutter goes Beta at #MWC18

What is Flutter? 

 

According to Google, Flutter is a mobile UI framework for creating high-quality native interfaces on iOS and Android. As a Google Partner and a company that has focused on building cross-platform mobile solutions for individuals and organizations, it is amazing to see a product like Flutter be released into Beta.

 

Better than other Cross-Platform Solutions

 

First of all, this initiative is backed by Google, which gives it a strong start. Also, the performance and platform integration are seamless and the structure allows us to build at high speed with great performance on both major platforms (iOS and Android.) Sure, there are some bugs and shortcomings, but that is always expected in a Beta version. We are on a trial run and, so far, our team loves it.

 

 

The team at Flutter highlights the benefits best on their Medium Post (Seth Ladd, Product Manager @ Google for Flutter):

 

  • High-velocity development with features like stateful Hot Reload, a new reactive framework, rich widget set, and integrated tooling.
  • Expressive and flexible designs with composable widget sets, rich animation libraries, and a layered, extensible architecture.
  • High-quality experiences across devices and platforms with our portable, GPU-accelerated renderer and high-performance, native ARM code runtime.

 

As a cross-platform mobile application development company, we are very excited about this solution because we can start using it immediately with our current apps. We don’t need to write our complete app in Flutter, we can simply add new Flutter-based screens to existing apps. Flutter is better than most of the cross-platform solutions we use today because it allows us, not only to build for two platforms but to make changes to the source code and see the UI updates in seconds, making the development process significantly faster.

 

If you are interested in learning more about Flutter, please reach out to schedule an informational meeting.

 

google-flutter-goes-beta

 

Mobile World Congress (#MWC18)

 

MWC is one of the biggest events on the mobile calendar. This year, more than in the past, the focus is going beyond our traditional understanding of Mobile Apps and pushing into the connected life or what MWC is calling “Intelligently Connected.”

 

Follow Shockoe to keep up to date on the key themes this year:

 

  • Artificial intelligence and machine learning (AI & ML)
  • Forthcoming 5G & LTE enablement
  • IoT smart city technology and edge computing devices
  • Big data and analytics
  • Technology in society and net neutrality
  • Consumer smartphone and tablet devices

Points for Style

Points for Style

It’s been years, but I can still remember my lab partner’s frustrated exclamation clearly. “It’s not a rule. It doesn’t matter!”, let out in response to seeing the results of our automatically graded submission of a program in a mid-level Computer Science course. Our work was functionally perfect, but the grading tool had subtracted several points over incorrect indentation size and other various style errors. He was right, technically, as we had adhered to the implementation requirements and using our program would produce indistinguishable results from our classmates’, but the faculty had chosen to take a stand. They chose to force us to care about style, or at least notice it. They chose to enforce a few basic style guidelines at a time when it seemed irrelevant, a time when we did the vast majority of our programming as a single developer in a vacuum. I’m not going to say I saw the light immediately, and I don’t remember a single student arguing in the system’s favor early on. I did, however, adopt good habits that I would later come to be thankful for when I learned what is a shocking truth for many young devs:

Style is not extra credit. Style matters.

Now the vacuum is gone and there is no auto-grader, just a group of incredibly smart fellow developers whose time is valuable and sanity should be protected. I’ve been a strong advocate of vigilant style practices for quite a while, but Shockoe turned out to be a place where justification for that is omnipresent. Due to the nature of our business, every developer makes contributions to a wide array of codebases, and has a hand in reviewing even more. We’ll wrap up a project and deliver it to the client, who then shows it off to the rest of the company and stakeholders. Soon we get feedback… management loved it! And guess what, they want a bigger, better phase 2! This is fantastic news, but it’s time to start planning, and “bigger and better” usually means additional resources. That means bringing new developers onto the project. Getting up to speed on a project quickly is a crucial skill for us, and we want to make that transition as smooth as possible. A little extra time considering style and writing cleaner code up front could make the difference between the next developer brought on grasping it instantly or spending an entire afternoon pulling their hair out.

Every new developer at Shockoe, usually on their very first day, is invited to a repository where an internal fork of the Idiomatic.js style guide lives and asked to study it. We have eyes on each others code constantly. Every user story is a pull request that gets reviewed, critiqued, and signed off on by a coworker.

I’ve known a lot of developers to be hesitant to request stylistic changes to another’s code, and I shared those feelings once too. It can feel like you are pointing out insubstantial issues, or that style is a personal choice and you might offend them. What we need to remember is that we are all trying to improve. If another developer reviews my work and thinks “I would write this differently” then I want to hear how. Several times, seemingly minor comments or questions have sparked a discussion that roped in multiple colleagues and left us all writing better code.

So don’t be satisfied with code that gets the job done. Strive for code that actively helps the next dev down the line, that they will thank you for, because when that time comes, you could be on another project, thanking someone else in kind.

Don’t copy and paste other people’s code, type it out

Don’t copy and paste other people’s code, type it out

If there’s one thing that hasn’t changed for me from the first day I started writing code until today, about my 500th day, it’s that not knowing where to start is incredibly intimidating. I acutely remember the panic of learning HTML and having no idea how to get my divs to go where I wanted them to go. The concept of setting up a grid system made sense to me, but the execution eluded me for days.

My relief finally came when I had the greatest realization of my young coding life: good lord, there is working code everywhere! It’s all over the internet! Just find it, copy it, and see how it works and you’re golden! I became a Google, “view source”, and “inspect element” maestro over night, learning structures and logics by reading other people’s successful executions. And for a while, this was all I needed. I needed to learn such basic things that just reading and seeing how other people’s code executed then editing it to fit my needs was the best thing for me. However, as my skills improved, I found myself lacking the skill to write code from scratch as elegantly as I wanted to. So I started a new system: instead of coping other people’s code, I type it out.

When Hunter S. Thompson was working as a copy boy at Time Magazine in 1959, he spent his spare time typing out the entire Great Gatsby by F. Scott Fitzgerald and A Farewell to Arms by Ernest Hemingway in order to better understand what it feels like to write a great book. To be able to feel the author’s turns in logic and storytelling weren’t possible from reading the books alone, you had to feel what it feels like to actually create the thing. And so I have found it to be with coding.

When I’m doing anything from executing a JQuery plugin someone else wrote to creating a static page in Python on a framework (like Cactus), whenever possibly I split the code onto one screen and my IDE on the other and type out the whole thing. It’s amazing how deeply I can understand the logic and any foreign syntax when I actually have to write it out. My mind has to actually narrate, like “here’s where they’re splitting the string, here’s where they’re parsing it, and WHOA! I didn’t know you could do that with Javascript!” when I undergo this process.

And it’s working. It’s awesome. I suggest you try it.

Nobody ever learned to become a great writer just by reading books, you’ve got to feel it.