You are currently browsing the archives for 13 February 2017.
Displaying 1 - 3 of 3 entries.

Opera Next 16 hints at new features

  • Posted on February 13, 2017 at 11:39 pm

Norwegian browser developer Opera Software has confirmed the switch of its browser development to a rapid release cycle with the launch of Opera Next 16. The new version number comes less than a month after Opera 15 FINAL was released, which saw Opera switch from its own proprietary Presto web engine to the Blink engine used by Google Chrome.

As with all rapid release cycle updates, there are no major overhauls to be found in Opera Next 16, although a number of interesting new features have been showcased as the next iteration starts its journey towards final release.

Opera 16 — which is based on Chromium 29, the engine that powers Chrome 29 (currently in beta) — comes with support for the W3C Geolocation API, a form auto-filler tool and opera:flags, a shortcut to settings that allows adventurous users to play with experimental features.

Users will also find a new setting under Browser > Start Page called “Preload Discover contents”, which allows users to switch this feature off.

Platform-specific updates include support for Jump Lists in Windows 7 and 8, plus the addition of Presentation mode to the Mac platform.

In addition to these existing features, Opera has revealed the next set of features it’s working on, with the promise that early versions of these will be rolled out into the Opera Next build over the next few weeks. These include proper bookmarks support, synchronization via Opera Link, improved tab handling and themes.

Opera Next 16 is considered “alpha” software, which is why — like Firefox Aurora — it’s designed to run alongside an existing stable build of Opera, allowing users to experiment with new features without affecting their day-to-day browsing. Updates are frequent as bugs are discovered and fixed, but users should not attempt to rely on Opera Next as their primary browser, hence the separate installation.

Galaxy Note III, “Gadget” First Use 3 GB of RAM?

  • Posted on February 13, 2017 at 5:34 pm

Phablet news about Samsung Galaxy Note III from re-emerge. This time in the form of hardware specifications that will be used.

Obtained from the leaked tech site Slashgear, Friday (07/05/2013), one of the popular series of Samsung’s devices will use large-capacity RAM, amounting to 3 GB.

If true, the Galaxy Note III will be the first mobile device that is equipped with 3 GB RAM capacity.

Just for the record, smart phone devices and premium phablet circulating lately generally use 2 GB of RAM.

Galaxy Note screen measuring 5.99 inches allegedly III with Full HD resolution (1920 x 1080) and a Super AMOLED display panel types. The size of a half-inch larger than its predecessor, the Galaxy Note II, which has a 5.5-inch landscape display. As for the Galaxy Note to be launched in 2011 and carries the 5.3-inch screen.

Bodi Galaxy Note III allegedly bit slimmer than its predecessor. If the Galaxy Note II has a weight of 182 grams, the Galaxy Note III a little lighter by 180 grams with a thickness of 8 mm.

At the time of its release later, the Galaxy Note III will run on the latest Android operating system, 4.3 Jelly Bean. He will also support 4G LTE technology-Advanced network.

Just like the Galaxy S4, there will be two versions of the Galaxy Note III, which was launched to the market. In a particular market, this device will be armed with the Qualcomm Snapdragon quad-core 800. As in other markets will be using processors made by Samsung’s own Exynos 5 “Octa” SoC.

Same as before, Samsung is rumored to be introducing a new model of the series Galaxy Note at this year’s IFA to be held in Berlin, Germany, in September 2013.

Seven signs of dysfunctional engineering teams

  • Posted on February 13, 2017 at 3:48 am

I’ve been listening to the audiobook of Heart of Darkness this week, read by Kenneth Branagh. It’s fantastic. It also reminds me of some jobs I’ve had in the past.

There’s a great passage in which Marlow requires rivets to repair a ship, but finds that none are available. This, in spite of the fact that the camp he left further upriver is drowning in them. That felt familiar. There’s also a famous passage involving a French warship that’s blindly firing its cannons into the jungles of Africa in hopes of hitting a native camp situated within. I’ve had that job as well. Hopefully I can help you avoid getting yourself into those situations.

There are several really good lists of common traits seen in well-functioning engineering organizations. Most recently, there’s Pamela Fox’s list of What to look for in a software engineering culture. More famous, but somewhat dated at this point, is Joel Spolsky’s Joel Test. I want to talk about signs of teams that you should avoid.

This list is partially inspired by Ralph Peters’ Spotting the Losers: Seven Signs of Non-Competitive States. Of course, such a list is useless if you can’t apply it at the crucial point, when you’re interviewing. I’ve tried to include questions to ask and clues to look for that reveal dysfunction that is deeply baked into an engineering culture.

Preference for process over tools. As engineering teams grow, there are many approaches to coordinating people’s work. Most of them are some combination of process and tools. Git is a tool that enables multiple people to work on the same code base efficiently (most of the time). A team may also design a process around Git — avoiding the use of remote branches, only pushing code that’s ready to deploy to the master branch, or requiring people to use local branches for all of their development. Healthy teams generally try to address their scaling problems with tools, not additional process. Processes are hard to turn into habits, hard to teach to new team members, and often evolve too slowly to keep pace with changing circumstances. Ask your interviewers what their release cycle is like. Ask them how many standing meetings they attend. Look at the company’s job listings, are they hiring a scrum master?

Excessive deference to the leader or worse, founder. Does the group rely on one person to make all of the decisions? Are people afraid to change code the founder wrote? Has the company seen a lot of turnover among the engineering leader’s direct reports? Ask your interviewers how often the company’s coding conventions change. Ask them how much code in the code base has never been rewritten. Ask them what the process is for proposing a change to the technology stack. I have a friend who worked at a growing company where nobody was allowed to introduce coding conventions or libraries that the founding VP of Engineering didn’t understand, even though he hardly wrote any code any more.

Unwillingness to confront technical debt. Do you want to walk into a situation where the team struggles to make progress because they’re coding around all of the hacks they haven’t had time to address? Worse, does the team see you as the person who’s going to clean up all of the messes they’ve been leaving behind? You need to find out whether the team cares about building a sustainable code base. Ask the team how they manage their backlog of bugs. Ask them to tell you about something they’d love to automate if they had time. Is it something that any sensible person would have automated years ago? That’s a bad sign.

Not invented this week syndrome. We talk a lot about “not invented here” syndrome and how it affects the competitiveness of companies. I also worry about companies that lurch from one new technology to the next. Teams should make deliberate decisions about their stack, with an eye on the long term. More importantly, any such decisions should be made in a collaborative fashion, with both developer productivity and operability in mind. Finding out about this is easy. Everybody loves to talk about the latest thing they’re working with.

Disinterest in sustaining a Just Culture. What’s Just Culture? This post by my colleague John Allspaw on blameless post mortems describes it pretty well. Maybe you want to work at a company where people get fired on the spot for screwing up, or yelled at when things go wrong, but I don’t. How do you find out whether a company is like that? Ask about recent outages and gauge whether the person you ask is willing to talk about them openly. Do the people you talk to seem ashamed of their mistakes?

Monoculture. Diversity counts. Gender diversity is really important, but it’s not the only kind of diversity that matters. There’s ethnic diversity, there’s age diversity, and there’s simply the matter of people acting differently, or dressing differently. How homogenous is the group you’ve met? Do they all remind you of you? That’s almost certainly a serious danger sign. You may think it sounds like fun to work with a group of people who you’d happily have as roommates, but monocultures do a great job of masking other types of dysfunction.

Lack of a service-oriented mindset. The biggest professional mistakes I ever made were the result of failing to see that my job was ultimately to serve other people. I was obsessed with building what I thought was great software, and failed to see that what I should have been doing was paying attention to what other people needed from me in order to succeed in their jobs. You can almost never fail when you look for opportunities to be of service and avail yourself of them. Be on the lookout for companies where people get ahead by looking out for themselves. Don’t take those jobs.

There are a lot of ways that a team’s culture can be screwed up, but those are my top seven.