Nothing here yet.
Nothing here yet.
No blogs yet.
Not being responsible - Don't tell your manager that "the cate ate my source code". Be a responsible and self-sufficient programmer. Premature Optimization - It's the root of all evils Not demonstrating intellectual honesty Write Code for machines, not humans. No investment in learning or staying up to date Doesn't care employer's business Lack of communication
When you work with any programmer, it's good to give an introduction and checklist of things to do before the code is written. Reviews and corrections are often expensive and time-consuming, waste time and energy for many in the group. Some important aspects are Be nice to people but with code Stand for strong engineering culture Give sufficient time to learn and write code Be open to feedback and always improve the process Structure your project with the right amount of checkpoints where everyone can contribute Make them well aware of engineering practices, software architecture before writing code Let the people take up tasks which match their skill level. It's good to label issues with "good-first-issues" which helps them to get along with the code with less impact. Encourage discussions on solutions and approaches before writing code Emphasizes meaningful code reviews Emphasize pull requests (code reviews) to be short Allow work in progress pull request to incrementally review the code. This helps the developers to get early feedback All the points above talks more about writing better code than struggling to give feedback on poorly written code. Lessons from Open Source Community There are a lot of learnings can be derived from open source community where senior and newbies are equally participating and contributing to the project. First, to have an up to date "README" page, which contains all essential things to take care of in the project. GitHub and similar services render README files at root level beautifully as a web page. A README can help the people to understand how they can up and running in minutes. More: Readme based development It's equally important to adopt any branching workflows such as GitFlow , GitHub Flow to ensure the code is written, tested and incorporated in a structured way. This also helps to have a pull request ready for review. All these information can be part of the README file as appropriate. Having a suitable PULL_REQUEST template will help show a template, which contains checkpoints and other information to be checked and filled before raising a PR.
Facebook is a major contributor to Open Source Software. They open source nearly all useful technologies that go in their product across platforms like iOS, Android, Web, Backend and hardware technologies. Going by the GitHub Page of Facebook, they heavily uses C++, Java, JavaScript, Python and Objective-C. Presto written in Java RocksDB, a persistent key value storage, written in C++ Facebook Historically written in PHP and solid contributor to its community. HHVM is a high performance JIT appoach . This is primarily written in C++ and PHP We talk more about Facebook when it comes to JavaScript stack. React is their most popula open source project. Looks like they're yet to catch hold of Swift. You can see more here - https://code.facebook.com/projects/ Someone from Facebook can contribute better to the answer.
If you are using ExpressJS as your web framework, you can add middle-ware functions to easily handle the caching mechanism with elegant code. You may use setex with an expiry value and add a middleware as give below for the request. app. get ( '/repos' , cache, getNumberOfRepos); You may use native redis package to initialize connection An Example middleware function is given below function cache ( req, res, next ) { const org = req.query.org; client.get(org, function ( err, data ) { if (err) throw err; if (data != null ) { res.send(respond(org, data)); } else { next(); } }); } Try this out: https://community.risingstack.com/redis-node-js-introduction-to-caching/
Storyboards in iOS Development. It's always a pain especially when more than one developer works on a single storyboard. It is super slow and a single big storyboard can literally make you exhausted. There are some workarounds introduced to split the storyboards, but the technology itself not worth it.
Hi Scott, it's been more than a decade since I started following your work. Thank you so much for the inspirations and your work. The buzz word in the industry is about machine learning and AI. There are smart developers who picked this up early. There are more and more products being powered with ML. One of the developers I spoke to believes that he would lose his job without learning the Machine Learning from ground up. What's your take on this paradigm shift and your recommendations to attack the problem for seasoned engineers.
It depends on what you want to build. If you are accessing the common features across platforms (iOS and Android), then you may likely find support on cross platform solutions like React Native, Ionic etc. I always prefer maintaining two separate stacks unless it's an easier app to build. React Native is being adopted at rapid pace and the community is also vibrant. There are still some rough edges if your application needs to access exclusive features of a platform or something not very common (for e.g. many third-party services doesn't offer a cross platform SDK like ReactNative, they usually have the ones for iOS and Android). This imposes restrictions in using React native and you may end up writing platform specific code separately. Good thing with React is that, you can partially use React within in your existing project. You are in control. Decide what to do next, then look support under each platform/framework to build things you want.
I have adopted ever since it's introduced at WWDC back in 2014. Objective-C is very powerful and very matured language. Language constructs are not something familiar to rest of the programming language community and there are too much of C. Swift 1.0 had so many rough edges and it did not have several things like exception handling etc. like Objective-C. The compilation was very slow due to the advanced optimization. All of sudden the MacBook Pros started looking very slow with 1.0. Surprisingly Apple quickly iterated the language and there were serious breaking changes between the minor versions and major versions. Certainly, projects went slight budget overruns, very hard to find developers who are familiar with Swift. The most interesting thing is that, we created more iOS developers and the grads joined in my company out of the university quickly picked up Swift much better and faster than Objective-C. We are still struggling to find developers with Swift experience though the language is in the 4th and most solid versions. Many ocmpanies are still considering to upgrade to Swift but not there yet. Despite of everything else, you write half of the code than Objective-C. The language constructs are modern and you are faster as you write a scripting language. Optionals extensions and enumerations are super powerful and give new meaning in the world of Swift. It works beautifully across existing Objective-C frameworks and code. There several quirks and lot may things to improve but it's certainly important to learn Swift and it's going to be the future. The community is super active and the language is getting improved at godly speed. Also the Xcode assistant to migrate the code between the version is very helpful.