As a developer, 3d modeling was something that I had always wanted to try since it was something that I needed to visualize the final product or to create prototypes in my DIY projects. For a long time I’ve been searching for a perfect CAD, but none of them were ideal for me. During one of my talks with a colleague of mine, he mentioned something about TinkerCAD, Fusion360 and OpenSCAD. The last one immediately got my attention as it had “open” in its name. I asked him to elaborate on that but “that’s geeky stuff” was all that he said. I’ve decided then to look it up since I had a feeling that it might be something for me…
React Native is a neat piece of technology that I get along pretty well with. Creating multiplatform apps using a shared codebase and having a great feedback loop sounds really promising and after hearing such things you may start wondering “Why the hell am I not using React Native?!”. Well… As you probably know, many things aren’t all that shiny after you go past the happy-path tutorials. In this post I’d like to give you my perspective on things that I have found problematic, frustrating or things that I just wasn’t prepared for while entering the React Native world. However, this will be a perspective of iOS developer who still have had a lot of fun with while developing with React Native.
How did it start?
Disengaged and burned out employees cost companies every year billions of dollars and can highly affect the success of the business or even result in its failure. Every employer knows that motivated and committed team values nowadays more than ever. Yet engagement does not equal to employees’ satisfaction or their happiness since someone can come to work every day with a big grin on their face, yet it does not have to mean they work productively on the behalf of the organisation. Someone can be also satisfied with their job, but coming across another offer, will quit it as quickly as one-day notice takes. So engagement is definitely something more than enthusiasm or satisfaction.
While implementing in-app purchases, especially auto-renewable subscriptions, there is a good chance your app will be rejected during a review process if you don’t follow the guidelines exactly. How can you avoid unnecessary trouble?
Nowadays using a production like database in unit1 tests is a common practice. Calling a real database can increase our confidence that a tested code actually works. Having said that a database, by its very nature, brings external state into a test that will affect its behavior, hence we need to pay special attention to prepare the test execution. There are couple of ways to handle the database state in tests and I’m going to describe an approach I like most.
Thoughts on management and team building
Let's take a quick look at one of the design patterns that should help us to write a good Object-Oriented code.
At Bright Inventions, we always try to keep focus on the bleeding-edge technologies and innovations. We are especially interested in cryptocurrencies and its prospective wide usage in the industry, not only as a payment method. We already have some experience with Ethereum and Hyperledger as a Blockchain-based app platform, so we were curious what can IOTA offer.
What satisfies your client?