The specific problem seems to occur in the IPN script (ipn.php), and only when using PayPal’s Sandbox. The IPN script confirms with PayPal the transaction that just occurred and updates the system accordingly. To do so, the script includes these lines:

$header = "POST /cgi-bin/webscr HTTP/1.0\r\n";
$header .= "Content-Type: application/x-www-form-urlencoded\r\n";
$header .= "Content-Length: " . strlen($req) . "\r\n\r\n";
fputs ($fp, $header . $req);

That performs the request, sending along three specific headers to customize the request.

Due to changes in PayPal’s Sandbox interface, you have to add one more header, just after the POST header. The resulting code is now:

$header = "POST /cgi-bin/webscr HTTP/1.0\r\n";
$header .= "Host: www.sandbox.paypal.com\r\n";
$header .= "Content-Type: application/x-www-form-urlencoded\r\n";
$header .= "Content-Length: " . strlen($req) . "\r\n\r\n";
fputs ($fp, $header . $req);

Thanks to Sean and Michael for bringing this to my attention.

Let me know if anyone has any problems or questions surrounding this.

I did some changing around of the table of contents. These are just changes that came organically as the book progressed. I did not drop the modules chapter, but I originally had one chapter on using extensions, one on modules (writing and using), and one on writing extensions. It just made more sense to do one chapter on using extensions (including modules) and one on writing extensions (including modules). So there’s that. And I changed the order of the other chapters in Part 3 a bit.

I’m almost done with Chapters 15, “Internationalization”, and 16, “Leaving the Browser”. I was almost done like two weeks ago, and now I’m still almost done. It’s been that kind of month! But I’m close, and they’ll go to the tech editors soon, and then I’ll do an update.

For the next X amount of time, I’m going to keep working hard on this, getting the first electronic edition done as soon as possible, without compromising the quality.

Also, I think I’ve got a handle on how to do a print run, and I’ll address that once this ebook is complete. The same goes for translations. Thanks to those that have expressed an interest in doing, or buying, a translation.

So there’s that. I’m going back to writing and working on getting this done!

• About This Newsletter
• What Were You Thinking? => Going Big, Macro Version
• What is Larry Thinking => Two Keywords for “Big” Programming
• Q&A => How do you write flexible code?
• Q&A => What do you think about Sass, Compass, and Haml?
• On the Web => CoffeeScript at Dropbox
• Larry Ullman’s Book News => “The Yii Book”

About This Newsletter

This is the second of a two-part newsletter on “going big”. By “going big” I mean how one transitions from a Web site with little to moderate traffic, to one that can handle tons of traffic. The previous newsletter looked at going big from the macro perspective: theory, implementation, hardware, and networking. In this newsletter, I’ll look at the micro perspective: how to write code that scales well. And, as it turns out, this newsletter again got to be too big, so this is part one of two parts that makes up part two of the two-part series. (Huh?) In this newsletter, I’ll mostly focus on code. The next will mostly focus on the database.

Before going into details, I’m going to define what it means to be a “big” site. As I said in the previous newsletter, it actually depends upon the kind of content and activity the site has: X number of video requests is far more demanding than the same X number of mostly text pages. Likewise, X number of WordPress page requests is far more demanding than the same X number of static HTML page requests. For the purposes of this discussion, let’s say that “big” is a site that gets in the broad neighborhood of 100,000 to 500,000 pageviews per day. At that point (if not before), you’ll need more than one server to handle the load. (As a counterpoint, on the highest end, Netflix sometimes requires up to 20,000 servers at a single time.)

As always, questions, comments, and all feedback are much appreciated. And thanks for your interest in what I have to say and do!

What Were You Thinking? => Going Big, Macro Version

After my previous newsletter, Ross shared with me his own experiences when it came to hosting, going big, and jumping the gun. Ross had an interesting experience, learned a lot, and was nice enough to let me share his story here (which I’ve hopefully not garbled too badly).

Ross had created an online game, and when he went from the private testing stage to the public beta, the amount of activity quickly spiked. Ross suddenly found that his Virtual Private Server (VPS) account was insufficient to handle the load, and as income was already coming in at a great pace, Ross quickly upgraded to two dedicated servers: one web and one database.

Unfortunately for Ross, both the activity and income then dropped pretty quickly, leveling off just above profitable over the course of the first year. Both continued their decline over the next couple years.

In hindsight, Ross says he should have realized sooner that the upgraded two-server hosting was too much money and unnecessary, but it took three years before Ross downgraded the hosting to a single VPS again.

Ross also discovered after the fact that one of the driving forces behind the initial need for a more powerful hosting solution was inefficient code. Particularly problematic was a lack of proper indexes on the database. Later implementing those changes resulted in a much better performing site. Ross’s realization is great for me, as the purpose of this particular newsletter is focusing on coding for a site that could go big!

Fortunately Ross still feels pretty good about his experience, appreciating what he learned, the money that did come in, and the people that he met along the way. In his most recent email to me, Ross said:

…[the] next time around…I’ll be able to do more, faster, with fewer mistakes. I’ve been able to pass on some of the lessons learned to friends and family, which is satisfying, and if there’s some wisdom that helps your readers, too, that’s even better.

Thanks, Ross!

What is Larry Thinking? => Two Keywords for “Big” Programming

If I were to summarize how to program a site for a potentially “big” scale, it’d come down to two words: optimal and flexible.

Optimal means that the site should perform as well as possible. This should seem obvious, of course, but it bears repeating. Entire books could be written on coding optimally, but a few rules of thumb include:

• Don’t create variables or functions you don’t need
• Minimize interactions with the file system
• Minimize interactions with the database
• Minimize networking
• Limit the amount of information retrieved from the database
• Watch usage of loops and recursion
• Minimize and compress the amount of data transferred to the browser

A catch is that you need to avoid premature optimization. Don’t overthink what you’re supposed to be doing while you’re performing the initial programming! The goal is really to write code using the best practices. Then, when the site is done, profile and benchmark what you’ve created to see how it performs. Then you can attempt to fix bottlenecks.

Next, there’s the issue of writing flexible code. To understand the importance of flexible code as it pertains to “going big”, one has to understand the two ways in which a site may need to grow:

• Scale to handle more traffic
• Add and change features and functionality

A site can often be scaled to handle more traffic simply by throwing more resources at it: better hosting, a better server, more memory, more servers, a Content Delivery Network (CDN), etc. You generally don’t have to do anything with your code to make it scale-able, although as Ross discovered, inefficient code can make it necessary to spend more on resources sooner than you otherwise should. It’s this second issue?the ability to add and change features and functionality?that’s of relevance to your programming.

Some years ago I saw a presentation by an engineer at YouTube who said that it was more important that they could fix problems quickly than that the site itself runs quickly. I’ve heard similar thoughts expressed by many other programmers: a developer’s time is precious, but a site can be made to run faster merely by throwing an extra $100 worth of RAM into a server.

The point of flexible code is that the site has to be written in such a way that it’s quick and easy for you to fix problems, add features, and make other significant changes. If the code is hard to update, then updates either won’t happen or won’t happen quickly enough (and therefore, users will leave).

As an example, I’m working on a site now for a customer with some terrible legacy code. The site works well enough, but the customer needs to add features and improve performance. The performance can largely be remedied by fixing several problems in the database:

• A lack of indexes
• Inconsistent column definitions

The database issues are not too difficult to solve. However, each added feature is taking twice as long as it should because the code is a mess. One main script is over 3,000 lines long! And because the site is being actively used (and is currently profitable), I cannot make the large, sweeping changes I’d like to make, at the risk of hurting the business. Hence, baby steps are required, changes are being made very slowly, and the client is paying extra because it’s so tedious to work with this code.

So how do you write flexible code? I’ll answer that specific question next, but first, there’s a conflict to be understood: flexible code is at odds with optimal code. Generally speaking, if you make your code more flexible, it won’t perform as well.

As a specific example, many developers use database-agnostic interfaces, such as PDO in PHP. PDO gives you a consistent interface regardless of the database in use. PDO also allows you to switch database applications on the fly, should that need arise. But the added interface layer drags down performance. Moreover, by being database agnostic, you can’t write your code to take advantage of features and capabilities of any specific database application. You’ve increased flexibility greatly, but hurt code optimization.

In this particular example, I’m generally of the opinion that one should just write the code to a specific database application. In almost 14 years of Web development, I’ve never once switched underlying database applications on an existing site. But the main point is that you have to find a balance between writing optimal code and writing flexible code. Fortunately, most of the best practices you’ll see online and read about in books hit this mark pretty well.

Q&A => How do you write flexible code?

I forget who asked me this and when, but the question surrounded what, exactly, flexible code is and how one writes it. There are two ways you can write flexible code:

• In the code itself
• Using a good workflow

One of the first hallmarks of flexible code is modularization: dividing code up into discrete, independent blocks. At the more beginner level, using multiple files is a modular approach. One file might connect to the database, another is a configuration file, another has useful functions. The primary files then include these as necessary.

Defining your own functions for certain routines is also a modular approach. With both of these examples, the benefit is that you can edit one piece of code in one location and have site-wide impacts. That’s flexible code.

Second, create variables for values repeatedly used throughout a site. This could be the site’s name or URL, an email address, and so on. You might not think you’ll ever change a site’s URL, but if you do, having assigned that value to a variable that’s used throughout the site will make that change a snap.

Third, and on the more advanced level, Object-Oriented Programming creates much more flexible code. It’s modular by definition. Sweeping changes can be made in single locations, including adding features. I’m not an “OOP is always better” kind of developer, but I don’t think there’s a question that OOP makes for more maintainable code when it comes to large sites. Well, good OOP, that is.

You can also create flexible code by creating good workflows. In other words, flexibility isn’t just demonstrated by the code itself, but also how you generate the code. For example, mastering your development tools is crucial. But more specifically, if you start using technologies like CoffeeScript (a JavaScript generator), and Sass, LESS, or Compass (CSS frameworks), edits can be made in one location and reflected everywhere. I’ll talk a bit more about these later in this newsletter.

The final component of your workflow should be version control. There are lots of arguments for version control, and being able to quickly institute code changes is just one. Being able to immediately revoke bad code changes is another! For large sites, the more advanced solution is continuous integration.

Again, much of what I’m talking about here is just a case of best practices: the kinds of things you should do whether or not your site would ever go big. The question is really how far you take any single approach.

Q&A => What do you think about Sass and Compass?

A thousand years ago or so, Jamie asked for my thoughts on Sass and Compass. Jamie said:

I’ve used Sass (SCSS) for a few projects, and Compass for one or two, and could never go back to vanilla CSS after doing so. I’m now looking forward to trying Sass’s “Sass” syntax in future projects.

At the time Jamie asked, I wasn’t really using CSS on such a level to appreciate these tools. And, to be frank, that’s still true. As a backend developer, I don’t do much with CSS, aside from the occasional edit of existing values to change a font’s size, a background color, or the height of a header. That’s changed some thanks to Twitter Bootstrap. When I’m using it for a site, I’ll end up doing more CSS edits, simply to customize the default Bootstrap look to something slightly more original (slightly). Bootstrap uses LESS, so I’ve started using LESS more myself (“LESS more” HA!). Coupled with CodeKit (for the Mac), it’s a great workflow to quickly develop sites.

Personally, I still don’t have much need for most of the features of these CSS frameworks. But they are great and totally useful. If you’re curious, I’d start out with something basic like LESS. If you use CSS a lot, then you may want to consider Sass.

On the Web => CoffeeScript at Dropbox

CoffeeScript is a language used to simplify the writing of JavaScript. One writes code in CoffeeScript and then compiles it, with the resulting output being usable JavaScript. The arguments for using CoffeeScript are:

• Less code to write
• Easier to maintain
• Results in better JavaScript

I personally had not been too sold on using CoffeeScript until I read about how Dropbox used CoffeeScript to rewrite all of its JavaScript in a single week. Three employees performed that task, converting over 23,000 lines of JavaScript into 18,000+ lines of CoffeeScript, without affecting any of the functionality.

Larry Ullman’s Book News => “The Yii Book”

There was not as much progress on “The Yii Book” last month as I would have liked, but I’m hoping to change that in May. I did some changing around of the table of contents. These are just changes that came organically as the book progressed. I did not drop the modules chapter, but I originally had one chapter on using extensions, one on modules (writing and using), and one on writing extensions. It just made more sense to do one chapter on using extensions (including modules) and one on writing extensions (including modules). So there’s that. And I changed the order of the other chapters in Part 3 a bit.

I’ve finally completed Chapters 15, Internationalization, and 16, Leaving the Browser. I’m getting those to the tech editors after this newsletter goes out, with an update to follow sometime thereafter.

It’s May, so I’m really bearing down to push through finishing this ASAP. I know I say this every time, but I really do appreciate your patience with this. You’ve been great. Truly. The writing itself hasn’t taken that much longer than expected, but everything else surrounding self-publishing has been a major drain on my time. I’ll write about all this when it’s behind me.

Also, in case you missed it, the first public preview of Yii 2 came out earlier this month. I’ve written how I expect that to impact “The Yii Book” in this blog post.

Thanks to everyone for their interest in this book and to everyone that has already purchased a copy!

To use LayoutIt!, you can start from scratch or begin with one of three base templates: starter, marketing, and article. Within the editing window, you can then start customizing your layout. First, use the grid functionality to add rows and columns of varying sizes. Maybe you want a banner across the top, then a row of two columns, and then a row of three. Could not be easier!

Next, use the CSS stuff to add and stylizes tables, forms, blockquotes, images, and the like. Depending upon what you add, you’ll be presented with other options to customize it, such as changing the alignment, emphasis, effects, and other styling.

There are then other conventional components: dropdowns, navigation menus, pagination links, “badges”, and “hero units”. Some of these can also be further customized once added to the page.

Finally, drop in the JavaScript-dependent components you need, like modal windows, tabs, accordions, and carousels.

Once you’ve got the design as you like it, you can download what you’ve created. You have three options:

• Copy just the HTML for the layout created, to be dropped into your own HTML file (with Bootstrap already installed)
• Download a single HTML page
• Download an entire zip file, with all the components required

You can also save what you’ve created, in which case you’ll be presented with a short URL that returns you to your design for future edits. You can also use that URL to give clients or coworkers a preview of what you’ve done.

The site is currently in beta, meaning there are more features to be added, but what’s there already is quite promising, particularly for those of us that can use all the extra design help they can get.

Why You Should Prioritize Your Current Clients

I’d like to think that I shouldn’t have to argue for why you should prioritize the clients you already have, and yet, it seems to be necessary. Here, then, are three simple arguments for doing so:

• It’s easy
• It’s the right thing to do
• It will pay off financially

Those are three different reasons with three different motivations. Let’s look at each.

It’s Easy (the “lazy” argument)

Getting new clients is hard! Really hard. You have to find them (or be fortunate enough that they find you). You have to engage in a conversation with them. You have to convince them to hire you instead of someone else. If you fail at any one of these steps, you don’t have a new client. And, statistically, you will fail in most of your attempts to get new clients.

Conversely, it’s very easy to take care of the clients you have. You’ve already connected with that client and established a relationship. In fact, you’ve already convinced them to hire you! You can now directly communicate with someone that pays you money for work. Hooray! Once you’ve gotten to that point, taking care of the client is easy, comparatively. You know what they want, what’s important to them, what they like, etc.

(This is normally the case. You will come across the occasional difficult client whom you can’t make happy, but you don’t really want that client in the long run anyway.)

It’s the Right Thing To Do (the “moral” argument)

Contractually, you have to live up to what you promise a client. But if you believe in the golden rule, then you ought to do more than just the bare minimum requirements.

It Will Pay Off Financially (the “good business” argument)

If neither of the other two arguments is sufficient for you, then here’s the kicker: you’ll make more money this way. Clients and jobs are too often thought of as just a financial arrangement: you do work for money. But if done right, you’ll get a lot more from a client and a job than just money:

• Experience
• A better portfolio
• Marketing benefits
• A potential future client

Experience and a strong portfolio can be as important as the money itself, especially when you’re just starting out. The same goes for the marketing benefit. If you treat your customer right, if you give them what they wanted and more, they will sing your praises, and you will likely get other clients because of that. A real, live recommendation or referral will do far more for you than any other type of advertising and promotion you attempt.

Finally, you ought to think of your current clients as potential future clients. I have two clients that I’ve continued to work with since 2001-2002. One just had me do another Web site for him last year. For the other client, I’ve probably done 5 Web sites over the decade. Clearly it’s better to have done 5 projects with one client than trying to find, work with, and manage 5 separate clients.

Your current clients are also potential future clients.

How to Prioritize Your Current Clients

So if you’re convinced of the need to put your current clients first, how exactly does one go about doing that? I’d recommend three steps:

• Make sure the project gets done, on time, and correctly
• Give the customer a bit more
• Follow up with the customer after the fact to make sure they’re still happy

The first suggestion is a given, although despite our best intentions, it doesn’t always (or often enough) happen. As for doing the job “correctly”, sadly most customers won’t know how well something is programmed. But you’ll know, so do it right. At the very least, you’ll appreciate having done it right if you’re ever hired back to do more work on the project (which is, of course, a goal)!

The second suggestion is a way to truly shine and put yourself ahead of the competition. Undoubtedly, while you’re scoping and working on the project there will be things the customer would like to do, but can’t afford. So pick one or two of those and do it for them. The afternoon you spend giving the customer a little bit more will pay off in spades down the line.

Third, and finally, some period of time after the project has been completed, and you’ve been paid, follow up with the customer. How is it working? Is there anything that’s not working (through no fault of your own or otherwise)? Is there anything that they realize in hindsight should be done differently? If life’s not too hectic, and it’s not unreasonable, offer to tweak a thing or two for free. Or at a discount.

These little things will make a huge impression, and a huge, positive impression will be great for your business in the long run.

Those are my thoughts as to why and how you should put your existing clients first. It’s something I strongly believe and continue to remind myself day after day. And I think the fact that I’m still making money from clients I first connected with over 10 years ago is proof that it works.

For more ideas (although many are particular to designers), check out this article at DesignFestival.

What do you think?

Besides mentioning this exciting news, I also wanted to explain how I expect this impacts my self-published book on the Yii framework.

As version 2 of the framework was being developed while I was writing the book, it was always my intention to start writing the book for Yii 1, and eventually update it all for Yii 2. The question is when I make that switch. Considering that Yii 2 is not production ready, and more changes are sure to come, my current plan is to complete the first draft of the book for Yii 1. Yii 1 is what people are using now, and there’s still a lot more information that people need to be covered by the book.

I assume that it will probably be three months or so before Yii 2 is ironed out and close to being production ready. The first electronic version of “The Yii Book” will be done by then. The remaining questions will be:

• When do I do a print run of the book?
• When do I start the process of having the book translated?

In other words, will the order be:

• Complete the book for Yii 1
• Update the book for Yii 2
• Create a print version of the book (for Yii 2)
• Create translations of the book (for Yii 2)

In that scenario, no print version or translations will ever be done for the Yii 1 version of the book.

Or will the order be:

• Complete the book for Yii 1
• Create a print version of the book (for Yii 1)
• Create translations of the book (for Yii 1)
• Update the book for Yii 2
• Create a print version of the book (for Yii 2)
• Create translations of the book (for Yii 2)

I will have to wait and see how things go, but my inclination today is that the first order will be what happens. On the one hand, the book’s content for Yii 2 won’t really be finalized until about Yii 2.0.x, when most of the post-production bugs have been found and fixed. This could be Fall 2013. On the other hand, I don’t want to ask translators to translate the entire book twice, as that’s a lot of work.

So, the short version of all this is that I’m going to complete the electronic version of the book for Yii version 1 first. Then I’ll see about translations and print copies based upon where Yii 2 is at that time.

As a reminder, anyone that purchases an electronic, English-language, Yii 1 version of the book will receive the electronic, English-language, Yii 2 version for free. 

Nettuts+ just posted Part 2. In this article, Podila goes into:

• Connection handling
• Identification and authorization
• Caching

It’s useful, detailed stuff, and understanding these fundamentals will help you better appreciate the how’s and why’s of web development.

I’m working on Part 3 of “The Yii Book”, and have made reference to the fact that I’ve been working on Chapter 15, “Internationalization,” and Chapter 16, “Leaving the Browser.” These are not the original chapters, per the first table of contents. Here, then, is an updated table of contents. These are still subject to change, but considering there’s not that much of the book left, there probably won’t be any dramatic changes.

The sections highlighted in green mark the completed sections as of the time of this blog post (April 29, 2013). If you have any questions, see the FAQ page.

• Introduction excerpt
  • Why Frameworks?
  • Why Yii?
  • What You’ll Need
  • About This Book
  • Getting Help

Part 1: Getting Started

• Chapter 1: Fundamental Concepts
  • Object-Oriented Programming
  • The MVC Approach
  • Using a Web Server
  • Command Line Tools
• Chapter 2: Starting a New Application
  • Downloading Yii
  • Testing the Requirements
  • Installing the Framework
  • Building the Site Shell
  • Testing the Site Shell
• Chapter 3: A Manual for Your Yii Site
  • The Site’s Folders
  • Referencing Files and Directories
  • Yii Conventions
  • How Yii Hands a Page Request
• Chapter 4: Initial Customizations and Code Generations
  • Enabling Debug Mode
  • Moving the Protected Folder
  • Basic Configurations
  • Developing Your Site
  • Building Components with Gii

Part 2: Core Concepts

• Chapter 5: Working with Models
  • The Model Classes
  • Establishing Rules
  • Changing Labels
  • Watching for Model Events excerpt
  • Relating Models
• Chapter 6: Working with Views
  • The View Structure
  • Where Views are Referenced
  • Layouts and Views
  • Editing View Files
  • Working with Layouts
  • Alternative Content Presentation excerpt
• Chapter 7: Working with Controllers
  • Controller Basics
  • Using Views
  • Using Models
  • Handling Forms
  • Basic Access Control
  • Understanding Routes excerpt
  • Tapping Into Filters
  • Showing Static Pages excerpt
  • Exceptions
• Chapter 8: Working with Databases
  • Debugging Database Operations
  • Database Options
  • Using Active Record
  • Using QueryBuilder
  • Using Database Active Objects
  • Choosing an Interface Option
  • Common Challenges
• Chapter 9: Working with Forms
  • Understanding Forms and MVC
  • Creating Forms Without Models
  • Using CHtml
  • Using “Active” Methods
  • Using CActiveForm
  • Using Form Builder
  • Common Form Needs
• Chapter 10: Maintaining State
  • Cookies
  • Sessions
• Chapter 11: Authenticating Users
  • Fundamentals of Authentication
  • Authentication Options
  • The UserIdentity State
  • Authorization
  • Working with Flash Messages
• Chapter 12: Working with Widgets
  • Using Widgets
  • Basic Yii Widgets
  • Presenting Data
  • The jQuery UI Widgets
• Chapter 13: Using Extensions
  • The Basics of Extensions
  • The bootstrap Extension
  • The giix Extension
  • Validator Extensions
  • Auto-Setting Timestamps
  • Using WYSIWYG Editor
• Chapter 14: JavaScript and jQuery
  • What You Must Know
  • Adding JavaScript to a Page
  • Using JavaScript with CActiveForm
  • Implementing Ajax
  • Common Needs

Part 3: Advanced Topics

• Chapter 15: Internationalization
  • What is i18n?
  • Setting the Locale
  • Detecting the User’s Locale
  • Providing Language-Appropriate Text
  • Formatting Dates
  • Representing Time Zones
  • Formatting Numbers
  • i18n and Your Models
• Chapter 16: Leaving the Browser
  • Writing a Proxy Script
  • Creating Web Services
  • Creating a Console Application
• Chapter 17: Improving Performance
  • Testing Performance
  • Faster Sessions
  • Caching
  • Utilizing APC
  • Database Profiling and Optimization
  • Browser Improvements
• Chapter 18: Advanced Database Issues
  • Calling Stored Procedures
  • Database Migration
  • Complex Relationships
  • Complex Keys
• Chapter 19: Extending Yii
  • Creating Widgets
  • Creating a Stripe Extension
  • Creating Modules
• Chapter 20: Working with Third-Party Libraries
  • Integrating Zend Framework Components
  • Alternative Database Libraries
  • Other Examples TBD
• Chapter 21: Implementing Unit Tests
  • Using PHPUnit
  • Using Selenium
  • Automating Tests

Part 4: Completing Projects

• Chapter 22: Creating a CMS
• Chapter 23: Making an E-commerce Site
• Chapter 24: Implementing a Search Engine
• Chapter 25: Shipping Your Project

• Appendix A: Frequently Asked Questions

• Never forget to validate data arriving from an untrusted origin using relevant rules for the context it?s used in.
• Remember that anything not explicitly defined in source code has an untrusted origin.
• Never include resources loaded over unsecured HTTP on a page loaded over HTTPS.
• Adopt the Content Security Policy (CSP) header and abandon the use of inline CSS and Javascript where feasible.
• Ensure that cookies which must only be transmitted over HTTPS are marked Secure.

The organization’s original logo is a terribly clunky thing, probably created in Microsoft PowerPoint or Paint! They need the logo to be recreated as a vector image (I assume), so that it’ll be usable online and in print publications. I imagine the color scheme will stay relatively the same. Other than that, I’m not sure as to the particulars of what they’d want the logo to be, look like, etc. (This is an organization, with a committee, so there may be multiple opinions involved.)

This is a non-paying gig. However, you’ll have my eternal gratitude and the reward of having done something charitable.

If you’re able and interested, let me know. Thanks!