Translating your Objective-C project to Swift

A step-by-step approach to using Swift with Objective-C.

transmision

If you’ve got an existing app written in Objective-C, migrating it into Swift is an excellent exercise for learning Swift, experimenting with Swift, and deciding whether to adopt Swift on a full-time basis. I’ve performed this migration with several real apps, so here are some tips culled from my actual experience.

Hybrid targets

You’re surely not going to translate all your code into Swift at once; you’re much more likely to translate one class at a time. As soon as you add a Swift file to your Objective-C app target, you’ve got a hybrid target: some classes are written in Swift, while other other classes are written in Objective-C. Thus, declarations in each language will need to be visible to the other language. Before you start, it’s a good idea to understand how this visibility works.

Recall that an Objective-C class declaration is conventionally spread over two files: a header file (.h) containing the @interface section, and a code file (.m) containing the @implementation section. If a .m file needs to know about a class, it imports the corresponding .h file.

Visibility of Swift and Objective-C to one another depends upon this convention: it works through .h files. There are two directions of visibility, and they must be considered separately.

Read more…

Comment: 1

4 reasons why microservices resonate

Microservices optimize evolutionary change at a granular level.

hive

We just finished the first O’Reilly Software Architecture Conference and the overwhelming most popular topic was microservices. Why all the hype about an architectural style?

Microservices are the first post-DevOps revolution architecture.

The DevOps revolution highlighted how much inadvertent friction an outdated operations mindset can cause, starting the move towards automating away manual tasks. By automating chores like machine provisioning and deployments, it suddenly became cheap to make changes that used to be expensive. Some architects properly viewed this new capability as a super power, and built architectures that fully embraced the operational aspects of their design. The Microservice architectural style prioritizes operational concerns as one of the key aspects of the architecture.

Microservice architectures borrow a design aesthetic from Domain Driven Design called the Bounded Context. A bounded context encapsulates all internal details of that domain and has explicit integration points with other bounded contexts. Microservice architectures reify the logical DDD bounded context into physical architecture. For example, it is common in microservice architectures for services that must persist data to own their database: members of the service team handle provisioning, backups, schema, migration, etc. In other words, in microservice architectures, the bounded context is also a physical context. But that also means that this service implementation isn’t coupled to any other team’s implementation, clearing the path for independent evolution. I recently published some writing about the recent realization that architecture is abstract until operationalized. In other words, until you have deployed an architecture and upgraded parts of it, you don’t fully understand it.

Read more…

Comment: 1

The shape of software architecture

Five things we learned from the O’Reilly Software Architecture Conference 2015.

Last week, I had the opportunity to see the first Software Architecture Conference spring to life after a winter of preparation. Software architects, with or without the official title, swarmed the halls learning from speakers and attendees alike. I count myself among the people who were learning. Many notions about this profession and skill set have become clearer to me and I’m already planning to keep the content coming. I’m also in the early stages of developing out the next Software Architecture Conference (spring 2016).

Within this piece you’ll find my takeaways and lessons learned from the event. I expect these initial impressions to both shape our upcoming exploration of software architecture and be shaped by continued shifts within software architecture.
Read more…

Comment: 1

How the DevOps revolution informs software architecture

The O'Reilly Radar Podcast: Neal Ford on the changing role of software architects and the rise of microservices.

hans_christian_hansen,_architect_seier+seier_Flickr

In this episode of the Radar Podcast, O’Reilly’s Mac Slocum sits down with Neal Ford, a software architect and meme wrangler at ThoughtWorks, to talk about the changing role of software architects. They met up at our recent Software Architecture Conference in Boston — if you missed the event, you can sign up to be notified when the Complete Video Compilation of all sessions and talks is available.

Slocum started the conversation with the basics: what, exactly, does a software architect do. Ford noted that there’s not a straightforward answer, but that the role really is a “pastiche” of development, soft skills and negotiation, and solving business domain problems. He acknowledged that the role historically has been negatively perceived as a non-coding, post-useful, ivory tower deep thinker, but noted that has been changing over the past five to 10 years as the role has evolved into real-world problem solving, as opposed to operating in abstractions:

“One of the problems in software, I think, is that you build everything on towers of abstractions, and so it’s very easy to get to the point where all you’re doing is playing with abstractions, and you don’t reify that back to the real world, and I think that’s the danger of this kind of ivory-tower architect. When you start looking at things like continuous delivery and continuous deployment, you have to take those operational concerns into account, and I think that is making the role of architect a lot more relevant now, because they are becoming much more involved in the entire software development ecosystem, not just the front edge of it.”

Read more…

Comment: 1

Signals from the O’Reilly Software Architecture Conference 2015

From careers to culture to code, here are key insights from the O'Reilly Software Architecture Conference 2015.

Experts from across the software architecture world came together in Boston for the O’Reilly Software Architecture Conference 2015. Below we’ve assembled notable keynotes, interviews, and insights from the event.

Software architects: post-“post-useful”

The old notion of a software architect being a non-coding, post-useful deep thinker is giving way to something far more interesting, says Neal Ford, software architect and meme wrangler at ThoughtWorks. “Architecture has become much more interesting now because it’s become more encompassing … it’s trying to solve real problems rather than play with abstractions.”

Read more…

Comment: 1

A software engineer’s role traversal

Software engineer and author Jason Myers on changing roles in a changing market.

jm_snake

We often hear about how the tech job market is booming and has space for newcomers, but what does that mean for the developers already in the market? In December of 2014, Fortune.com predicted that 2015 would be an excellent year for developers to change jobs. Citing Dice.com, they note that jobs are popping up all over the country. In fact, Dice’s survey also reports 40% of hiring managers seeing voluntary departures, a higher number than was seen just six months earlier.

These are all large, general numbers. What does a job change, and the changing market, look like for individual developers? To get a better sense, I spoke with Jason Myers, who is working on our upcoming Essential SQLAlchemy, 2e title. Jason recently went from working for the email marketing service Emma, Inc., to working for networking giant Cisco. Here, he talks about how a change like that feels, and how the market looks to him.

Read more…

Comment: 1