Java can be converted to Objective-C and called from Swift code in an iOS app with the tool j2objc. I wrote this piece on how to handle Java exceptions from this Swift code.
Years ago, when I started planning my cocktail app, I looked at options for code re-use between Android and iOS. Critically, I knew it would take me a while to get the first platform release out so I was worried any tool I expected to use might be unmaintained by then.
I found the tool j2objc and it looked really promising:
- open source
- development funded by Google
- it was being relied upon by Google for most of their apps on both mobile platforms (plus the Web)
So, I could always adapt the tool for my own needs if it did get abandoned. But the maintainers had significant motivation and resources to maintain the project so that seemed like a low risk anyhow.
I didn't imagine Android and iOS would change so much in the time it took to get my Android app completed. Both platforms even changed their primary development language in that span along with a lot of best practices and recommended components. Even though both platforms do a great job of keeping their documentation up-to-date and the most relevant pieces easy to find, learning to develop on one of these platforms is challenging. There still is a lot of outdated information out there (be it Stack Overflow posts or an incredible number of tutorials) and there are stacks and stacks of components to learn. Expectations for modern mobile apps are really high so the number of details to get right can be daunting.
Then to build your app for the other platform you get to start all over! :)( Collapse )
A lot of the software most of us use day-to-day is built with the assumption that Internet access is fast, cheap, unlimited*, and ubiquitous.
For a lot of Endless’ current and target users, most of those assumptions are not true. Internet connectivity is often capped to low throughput and monthly quotas and may be relatively expensive or unreliable. Or it may be inaccessible entirely due to cost or lack of infrastructure.
When these assumptions fail, a lot of modern software fails.
This includes software updates.
Offline app and OS updates have been some of our longest-running development projects and it’s been quite a challenge. There are a handful of complex components involved and there’s a lot of plumbing and API work that needed to be designed, discussed, and tested in real-world scenarios. And because there was some but not total overlap between USB app updates, USB OS updates, LAN app updates, and LAN OS updates (see below), we had to do a lot of work to not paint ourselves into a corner.( Collapse )
So, I'm always inspired to see projects aimed at narrowing the gap.
San Francisco start-up Endless have designed a computer made to be affordable for emerging markets that saves cost by re-using a TV as a display (which are relatively wide-spread even where computers are not) and using best-of-breed open source software. And they've built the software specifically to work for the developing world which has different challenges than the developed world, such as unreliable Internet connectivity.
Please see the videos on their website that explain much better than I have the importance of bringing computers to the rest of the world.
I'm proud to say that my colleagues at Collabora have helped develop software platform that Endless will be shipping on these computers and have contributed to their Kickstarter campaign.
As I write this, there's just a little time left to contribute to Endless's Kickstarter campaign. Please consider a donation because every bit helps.
A couple weeks ago, Martin Pitt announced the jhbuild continuous build server he has been working on. It's a great setup and clearly details which modules are failing to build and why. It also keeps useful metrics like "time of last successful build", "time of last failed build", and runs and reports on the results of "make check".
This is a great safety net for GNOME as a whole, since it continuously checks our entire stack in a common environment. Once maintainers get reliably notified about any breaks, I think we'll see broad benefits. When our code reliably builds and passes its unit tests, it's a lot more attractive to outside (and inside!) developers.
With, thankfully little work, Folks is now reliably building and passing its unit tests on this server, and I intend to keep it that way :)
I'd like to thank Martin for setting this all up and him and Jean-Baptiste Lallement for helping debug some LXC-related issues which were causing some of our tests to fail on this server (but not for us maintainers, making it hard for us to help).
In the process of fixing these issues, the build server proved its usefulness for our project already because it caught a build break I didn't hit on my own system (because I had an older version of EDS build). Normally, this could have taken days or longer for me to notice because I tend not to re-build the stack below Folks very often. If I'm working on a large feature, I want to get it all working before I potentially break my build environment with unstable changes in our dependencies. A continuous integration system should also make frequently updating dependencies less of a risk (which is just more good news for everyone).
The word decision, closely related to incision, derives from the meaning 'a cutting off'. Making effective decisions—and learning effectively—requires massive elimination and the removal of options.
—Tim Ferriss, The 4-Hour Chef
Right now, if you ask that question, you'll get about 8 different personal-preference answers, which drives people away from our platform. Having to potentially evaluate several different languages and their stacks gives potential developers a lot of unneeded extra work.
There was broad consensus in the hackfest for this goal because it allows us to:
- It allows us to focus when we write developer documentation, fixing bugs in the development environment and the development of tools. This reduces our maintanence costs and enables us to be vastly more efficient.
- It enables code and knowledge sharing to occur, so that people can easily copy and paste code from existing applications, or find information about common problems and challenges.
- It provide a coherent and easy-to-follow path for new developers.
- It allows us to include the full GNOME framework within the language itself.
We spent a long time discussing the different options that are available to us, and there were a variety of opinions. However, at the end of the day, we had to recognize that no language is perfect and there will always be disagreement. The important thing was that we had to make a decision.
It's critical that everyone understands this decision as a plan to elevate the language, bindings, tools, and documentation to a level of quality we have not yet achieved. It is not a decision to abandon any other language bindings. We will continue to distribute other bindings and documentation as we do now and compatibility for the other languages will continue to be developed as they are today by the developers involved with those modules.
C will remain the recommended language for system libraries.
- Our language of choice needs to be dynamic and high level.
- There's a lot of work going into the language to make it especially fast, embeddable, and framework-agnostic.
This is the start of a process and there's obviously a lot of work ahead of us. However, prioritizing a single language will enable us to turn GNOME into a compelling platform for application developers in a much more effective and efficient manner.
Forget what you're standing on and focus.
I read The 4-Hour Work Week, which touches on Inbox Zero and adds some interesting productivity-increasing ideas, including giving up on boring articles and the controversial "don't waste time reading news". I haven't stopped reading news, but I feel like I've gotten a little more efficient at it. I mostly ignore mailing lists (except those for my immediate projects). The only reason I'm subscribed to some is so that I can reply to them on the occasion I'm CC'd or someone brings up a specific discussion to me.
Along the line of distractions, I've been training myself to catch them before they happen. Because there's increasing evidence that multi-tasking reduces productivity (and it seems obvious to me anyhow), I push myself to not switch tasks unless I absolutely have to. And I actively ignore anything that I know will needlessly steal my focus. This includes only checking up on IRC periodically (and mostly just to check for messages that have been highlighted for me). If it's urgent, people will send me a direct message (and Gnome Shell will give me a nice notification).
I believe the author of 4HWW intentionally mentions keeping only calendar events, not tasks. I've always liked the idea that you will remember anything important and anything minor will come up again (particularly because I've struggled with far too many tasks in my GTD system). But that seems too extreme/unworkable for me, so the key has just been being much more aggressive in deleting tasks that sit too long (knowing I'll never get to them) and doing periodic sweeps through each list. If you have trouble with that, you might want to create a "some day" list to move neglected tasks to. Then, just make a point to ignore that list. I think I'm nearly ready to delete mine.
Another part of minimizing mental burden has been closing application tabs and windows and conversation notifications as soon as I can. When I finish a task, I close everything related to it (even if I think I'll use some of them later). The stress saved by this reduction in visual noise is much greater than occasionally having to re-open something sooner than expected (which is incredibly rare, as you might imagine).
Your screen should not look like this.
And the latest change I've made, just before reaching inbox zero/GTD zen, has been to batch process my inboxes. I had a terrible habit of glancing at mail, flagging it important and unread, then moving on. It turns out that I subconsciously skip over bold, red lines of text. This was a horrible priority inversion that lead me to sporadically clearing out the simple mail while ignoring the high-priority, difficult tasks.
Now, when I do my few daily mail passes, I do two quick passes (always in oldest to newest order, never skipping any):
- Add tasks, file mail
- parse out new tasks to my GTD system (setting due date and priority appropriately)
- if it needs a trivial or no response, give it immediately, then file
- otherwise, move on to the next letter
- parse out new tasks to my GTD system (setting due date and priority appropriately)
- Give non-trivial responses
- Read the letter in detail
- Respond to each point necessary
- Read the letter in detail
Now, with an empty inbox, I can get work done by just drilling through items in my work or personal task list in order from highest to lowest priority. It's a lot harder to skip around, ignoring the important tasks, when they're sitting in front of you, in the exact order you've chosen yourself.
I still have things to improve (I really wish I had one place to manage all my tasks, not several), but I finally feel in control of my day-to-day goals!
The work that Valerie's Ada Initiative is critically important for the technology industries, which still have a lot of work to do on being inclusive (particularly to women).
As some personal anecdotes, most of the best conferences I've attended have had strict anti-harassment policies/codes of conduct (including Linux.conf.au and GUADEC). They help make the conference a more-welcoming place by clarifying unacceptable behavior, which brings in more participants from a wider variety of backgrounds, which makes the conference better for everyone.
Specifically, GUADEC's and Gnome's work to include more women has really started to pay off. The official count this year was that 17% of the attendees were women, and it was obvious. And it was especially for anyone who's been attending since Vilanova in 2006, like me, where I can honestly only remember a few women attendees. The Gnome Outreach Program for Women certainly deserves a fair amount of credit here, as do the Gnome community's clear and consistent enforcement of the Code of Conduct.
Codes of Conduct/anti-harassment policies/many laws should not be necessary. But they clearly are because some people otherwise don't understand or refuse to comply with common decency. These policies really require a fairly minimal amount of effort to create and enforce, open attendance to a much wider and diverse audience, and benefit everyone as a result. Everyone wins!
Topics include (but are not limited to):
- User input. We'd really like to hear what you think about Folks and its Empathy and Gnome integration.
- Constructive compliments
- A follow-up on progress on the tasks we set at the Social IM/Contacts hackfest in Cambridge
- General discussion/questions/requests