Another PyCon ended for me this week, and now I have the long wait until next March’s conference. Being my second time attending, I was more aware of how to take advantage of the conference. However, after trip number two, I’ve learned a few things more.

The talks themselves were too numerous and spectacular to outline individually. In fact, I haven’t really started into the pages of notes I took during the conference. I know I’ve written down some true gems, but I think my brain could use a (comparable) rest for the remainder of the week at the very least. Instead, I wanted to talk about more general PyCon tips. Probably the best lightening talk I saw summed up many of the tips:

First PyCon Tips (not me, BTW)

Some important points that I learned, however, were things I learned last year as well.

Use Twitter

Last year a handful of people pointed out that they used Twitter extensively during the conference. I didn’t have a Twitter account because I honestly couldn’t think of a reason why. Right up until PyCon 2012 I kept reminding myself that I should probably sign up, but I never did.

Big mistake.

Twitter seemed to be more prevalent than ever this year. In fact, most every business card I received had a Twitter handle. I felt like an unconnected ass the countless times people asked me what my Twitter was. I learned my lesson, and now I can be followed at @fortranjeff.

Listen to Talks

My first year at PyCon, I was surprised at how many laptops were out during the presentations. Being a follower, I brought mine along and opened it at every talk. That’s where I became a little baffled about what to do next. Looking around, some people were taking notes, but others were coding, browsing, or checking email.

I tried doing some coding during talks, and I immediately noticed that I was missing giant portions of the talk. This year, while I did carry my heavy 15 inch Dell everywhere, I made sure to only take notes during talks. I found that I actually walked away with significantly more information. I guess the moral of the story is that it pays to listen to whoever is talking at the front of the room.

Never Hesitate to Talk About Yourself

This tip probably sounds rather pompous at first, but it isn’t meant to be. I’m not necessarily the most outgoing person. However, when at a conference alone, you need to be as outgoing as possible to make it worthwhile.

My problem, though, was often hesitation to talk about what I did. Last year, when traveling for my NASA-contracting employer, I would try to play down what I did as it didn’t seem as impressive as all the other people at PyCon. I don’t think that’s the right move. This year I was quite forthcoming with the fact that I own a small business developing a Fortran development environment. While this occasionally raised eyebrows or resulted in a chuckle, everyone seemed genuinely interested in the reasons behind it. Furthermore, sticking my neck out and chatting about what I do know about web frameworks and scientific programming always seemed to result in fantastic conversations where I learned plenty.

Other people need to follow this rule too. Just about everyone I met had a fascinating use case for Python, at least in my eyes. Then I can walk away from those conversations with knowledge like, “I’m going to check out this whole MongoDB deal,” or “I have to check what the standard library’s subprocess module does again.” Neither are “necessary” for my work, but both may turn out to be valuable at some point in my career.

Stick Around in the Evenings

I had some great conversations into the evenings with other attendees. It doesn’t hurt that most of the evening activities I participated in involved alcohol as it does “grease the wheels” nicely for everyone.

Consider Sprinting

Every year when the closing remarks are ending, I feel regret for not staying for sprints. This year was no different. I plan on staying next year for at least a day to see what they’re about.

So those are my rather lame tips for PyCon. I’ll of course attend next year, and hopefully I learn some more tips for getting the most out of the conference before then. At least now I don’t have to meekly state, “I don’t have a Twitter account.”

Simply Fortran has been out for well over a year now, and people generally seem happy with the development environment. The whole package has grown by leaps and bounds from its initial release. Of course, there’s plenty of space for improvement.

One user suggested the ability to display the entire project’s structure rather than the structure of a single source file. Currently an outline for a file currently present in the editor can be viewed and used for simple navigation. The background parsing engines attempt to determine the location of all Fortran modules, functions, and subroutines within the file, and an outline is built from the parsing results. Furthermore, other languages, including C, Python, and Makefiles, are also supported. However, in a project with many source files, there is significant value to building a project-level outline tree.

Displaying the overall project structure is the real dilemma. Simply Fortran uses a project tree to display all files within a given project, and this tree is not fixed to the file system. In other words, users can create folders and organize source files without creating a matching, underlying file organization on the disk.

If a project’s entire tree were to be displayed, there are a few options for doing so. The easiest route would be to expand the single file outline panel to display the overall project outline. However, should the outline organize by files, then source components, or should the idea of a “file” be removed from this outline? The other option might be to enhance the project tree to allow expanding files to examine their source components. The project tree is already an abstract representation of the project, and the organization reflects the user’s preferences. Adding source components would be no simple task, though. And if the file outlines were accessible in the project tree, is there still a need for the single-file outlines?

The simplest solution might be to retain the current outline panel but add new controls to allow showing a global list of available source components rather than only those in the file. This outline style would probably then ignore the idea of which file owns a given module, function, or subroutine. Additionally, a search box could be added to sort through components of a large project. Adding a search box, however, might possibly negate the need for some other Simply Fortran component panels, specifically the module browser and the component search panel.

A whole-project outline is a difficult concept to visualize and implement, but it is assuredly a powerful tool.