Programming & Web Design Articles

Article / Updated 09-13-2023

Many organizations are using Python these days to perform major tasks. You don't necessarily hear about them because organizations are usually reserved about giving out their trade secrets. However, Python is still there making a big difference in the way organizations work and toward keeping the bottom line from bottoming out. Following, are some major ways in which Python is used commercially that will make it easier to argue for using Python in your own organization. (Or you can read about some Python success stories.) Corel: PaintShop Pro is a product that many people have used over the years to grab screenshots, modify their pictures, draw new images, and perform a lot of other graphics-oriented tasks. The amazing thing about this product is that it relies heavily on Python scripting. In other words, to automate tasks in PaintShop Pro, you need to know Python. D-Link: Upgrading firmware over a network connection can be problematic, and D-Link was encountering a situation in which each upgrade was tying up a machine — a poor use of resources. In addition, some upgrades required additional work because of problems with the target device. Using Python to create a multithreaded application to drive updates to the devices allows one machine to service multiple devices, and a new methodology allowed by Python reduces the number of reboots to just one after that new firmware is installed. D-Link chose Python over other languages, such as Java, because it provides an easier-to-use serial communication code. Eve-Online: Games are a major business because so many people enjoy playing them. Eve-Online is a Massively Multiplayer Online Role Playing Game (MMORPG) that relies heavily on Python for both the client and server ends of the game. It actually relies on a Python variant named StacklessPython, which is important because you encounter these variants all the time when working with Python. Think of them as Python on steroids. These variants have all the advantages of Python, plus a few extra perks. The thing to take away from this particular company is that running an MMORPG takes major horsepower, and the company wouldn't have chosen Python unless it were actually up to the task. ForecastWatch.com: If you have ever wondered whether someone reviews the performance of your weatherman, look no further than ForecastWatch.com. This company compares the forecasts produced by thousands of weather forecasters each day against actual climatological data to determine their accuracy. The resulting reports are used to help improve weather forecasts. In this case, the software used to make the comparisons is written in pure Python because it comes with standard libraries useful in collecting, parsing, and storing data from online sources. In addition, Python's enhanced multithreading capabilities makes it possible to collect the forecasts from around 5,000 online sources each day. Most important of all, the code is much smaller than would have been needed by other languages such as Java or PHP. Frequentis: The next time you fly somewhere, you might be relying on Python to get you to the ground safely again. It turns out that Frequentis is the originator of TAPTools, a software product that is used for air traffic control in many airports. This particular tool provides updates on the weather and runway conditions to air traffic controllers. Honeywell: Documenting large systems is expensive and error prone. Honeywell uses Python to perform automated testing of applications, but it also uses Python to control a cooperative environment between applications used to generate documentation for the applications. The result is that Python helps generate the reports that form the documentation for the setup. Industrial Light & Magic: In this case, you find Python used in the production process for scripting complex, computer graphic-intensive films. Originally, Industrial Light & Magic relied on Unix shell scripting, but it was found that this solution just couldn't do the job. Python was compared to other languages, such as Tcl and Perl, and chosen because it's an easier-to-learn language that the organization can implement incrementally. In addition, Python can be embedded within a larger software system as a scripting language, even if the system is written in a language such as C/C++. It turns out that Python can successfully interact with these other languages in situations in which some languages can't. Philips: Automation is essential in the semiconductor industry, so imagine trying to coordinate the effort of thousands of robots. After a number of solutions, Philips decided to go with Python for the sequencing language (the language that tells what steps each robot should take). The low-level code is written in C++, which is another reason to use Python, because Python works well with C++.

Cheat Sheet / Updated 09-06-2023

Unlike traditional manufacturing, which involves injecting material into a pre-formed mold or removing material from base material objects, 3D printing starts with a virtual 3D model that is transformed into solid form one layer at a time. Each layer is built on top of the layer before, creating a solid form representing the virtual 3D model in all of its complexity and detail without requiring additional forms of machining and treatment necessary in traditional forms of manufacturing. You can buy an off-the-shelf desktop 3D printer or build your own 3D printer using the open-source self-REPlicating RAPid-prototyper (RepRap) family of designs. Check out these helpful articles to guide you toward selecting the right RepRap design for you.

Article / Updated 08-16-2023

What is DevOps? It’s difficult to provide you with an exact DevOps prescription — because none exists. DevOps is a philosophy that guides software development, one that that prioritizes people over process and process over tooling. DevOps builds a culture of trust, collaboration, and continuous improvement. As a culture, the DevOps philosophy views the development process in a holistic way, taking into account everyone involved: developers, testers, operations folks, security, and infrastructure engineers. DevOps doesn’t put any one of these groups above the others, nor does it rank the importance of their work. Instead, a DevOps company treats the entire team of engineers as critical to ensuring that the customer has the best experience possible. DevOps evolved from Agile In 2001, 17 software engineers met and published the “Manifesto for Agile Software Development,” which spelled out the 12 principles of Agile project management. This new workflow was a response to the frustration and inflexibility of teams working in a waterfall (linear) process. Working within Agile principles, engineers aren’t required to adhere to original requirements or follow a linear development workflow in which each team hands off work to the next. Instead, they’re capable of adapting to the ever-changing needs of the business or the market, and sometimes even the changing technology and tools. Although Agile revolutionized software development in many ways, it failed to address the conflict between developers and operations specialists. Silos still developed around technical skill sets and specialties, and developers still handed off code to operations folks to deploy and support. In 2008, Andrew Clay Shafer talked to Patrick Debois about his frustrations with the constant conflict between developers and operations folks. Together, they launched the first DevOpsDays event in Belgium to create a better — and more agile — way of approaching software development. This evolution of Agile took hold, and DevOps has since enabled companies around the globe to produce better software faster (and usually cheaper). DevOps is not a fad. It’s a widely accepted engineering philosophy. DevOps focuses on people Anyone who says that DevOps is all about tooling wants to sell you something. Above all else, DevOps is a philosophy that focuses on engineers and how they can better work together to produce great software. You could spend millions on every DevOps tool in the world and still be no closer to DevOps nirvana. Instead, focus on your most important engineering asset: engineers. Happy engineers make great software. How do you make happy engineers? Well, you create a collaborative work environment in which mutual respect, shared knowledge, and acknowledgement of hard work can thrive. Company culture is the foundation of DevOps Your company has a culture, even if it has been left to develop through inertia. That culture has more influence on your job satisfaction, productivity, and team velocity than you probably realize. Company culture is best described as the unspoken expectations, behavior, and values of an organization. Culture is what tells your employees whether company leadership is open to new ideas. It’s what informs an employee’s decision as to whether to come forward with a problem or to sweep it under the rug. Culture is something to be designed and refined, not something to leave to chance. Though the actual definition varies from company to company and person to person, DevOps is a cultural approach to engineering at its core. A toxic company culture will kill your DevOps journey before it even starts. Even if your engineering team adopts a DevOps mindset, the attitudes and challenges of the larger company will bleed into your environment. With DevOps, you avoid blame, grow trust, and focus on the customer. You give your engineers autonomy and empower them to do what they do best: engineer solutions. As you begin to implement DevOps, you give your engineers the time and space to adjust to it, allowing them the opportunities to get to know each other better and build rapport with engineers with different specialties. Also, you measure progress and reward achievements. Never blame individuals for failures. Instead, the team should continuously improve together, and achievements should be celebrated and rewarded. You learn by observing your process and collecting data Observing your workflow without expectation is a powerful technique to use to see the successes and challenges of your workflow realistically. This observation is the only way to find the correct solution to the areas and issues that create bottlenecks in your processes. Just as with software, slapping some Kubernetes (or other new tool) on a problem doesn’t necessarily fix it. You have to know where the problems are before you go about fixing them. As you continue, you collect data — not to measure success or failure but to track the team’s performance. You determine what works, what doesn’t work, and what to try next time. Persuasion is key to DevOps adoption Selling the idea of DevOps to your leaders, peers, and employees isn’t easy. The process isn’t always intuitive to engineers, either. Shouldn’t a great idea simply sell itself? If only it were that easy. However, a key concept to always keep in mind as you implement DevOps is that it emphasizes people. he so-called “soft skills” of communication and collaboration are central to your DevOps transformation. Persuading other folks on your team and within your company to adopt DevOps requires practicing good communication skills. Early conversations that you have with colleagues about DevOps can set you up for success down the road — especially when you hit an unexpected speed bump. Small, incremental changes are priceless in DevOps The aspect of DevOps that emphasizes making changes in small, incremental ways has its roots in lean manufacturing, which embraces accelerated feedback, continuous improvement, and swifter time to market. Water is a good metaphor for DevOps transformations. Water is one of the world’s most powerful elements. Unless people are watching the flood waters rise in front of them, they think of it as relatively harmless. The Colorado River carved the Grand Canyon. Slowly, over millions of years, water cut through stone to expose nearly two billion years of soil and rock. You can be like water. Be the slow, relentless change in your organization. Here’s that famous quote from a Bruce Lee interview to inspire you: Be formless, shapeless, like water. Now you put water into a cup, it becomes the cup. You put water into a bottle, it becomes the bottle. You put it in a teapot, it becomes the teapot. Now, water can flow or it can crash. Be water, my friend. Making incremental changes means, for example, that you find a problem and you fix that problem. Then you fix the next one. You don’t take on too much too fast and you don’t pick every battle to fight. You understand that some fights aren’t worth the energy or social capital that they can cost you. Ultimately, DevOps isn’t a list of steps you can take, but is rather an approach that should guide the decisions you make as you develop.

Article / Updated 08-16-2023

DevOps has no ideal organizational structure. Like everything in tech, the “right” answer concerning your company’s structure depends on your unique situation: your current team, your plans for growth, your team’s size, your team’s available skill sets, your product, and on and on. Aligning your DevOps team’s vision should be your first mission. Only after you’ve removed the low-hanging fruit of obvious friction between people should you begin rearranging teams. Even then, allow some flexibility. If you approach a reorganization with openness and flexibility, you send the message that you’re willing to listen and give your team autonomy — a basic tenet of DevOps. You may already have a Python or Go developer who’s passionate and curious about infrastructure and configuration management. Maybe that person can switch into a more ops-focused role in your new organization. Put yourself in that person’s shoes. Wouldn’t you be loyal to an organization that took a risk on you? Wouldn’t you be excited to work hard? And that excitement is contagious. Here, you learn how to align the teams you already have in place, dedicate a team to DevOps practices, and create cross-functional teams — all approaches from which you can choose to orient your teams toward DevOps. You can choose one approach and allow it to evolve from there. Don’t feel that this decision is permanent and unmovable. DevOps focuses on rapid iteration and continual improvement and that’s the prime benefit of this methodology. That philosophy applies to teams as well. Aligning functional teams for DevOps In this approach, you create strong collaboration between your traditional development and operations teams. The teams remain functional in nature — one focused on ops, one focused on code. But their incentives are aligned. They will grow to trust each other and work as two teams yoked together. For smaller engineering organizations, aligning functional teams is a solid choice. Even as a first step, this alignment can reinforce the positive changes you’ve made so far. You typically start the alignment by taking the time to build rapport. Ensure that each person on both teams not only intellectually understands the other team’s role and constraints but also empathizes with the pain points. For this approach, it’s a good idea to promote a policy of “You build it, you support it.” This policy means that everyone — developer and operations person alike —participates in your on-call rotation. This participation allows developers to start understanding the frustrations of being called in the middle of the night and struggling while foggy-eyed and caffeine-deprived to fix a bug that’s impacting customers. Operations folks also begin to trust your developers’ commitment to their work. Even this small change builds an extraordinary amount of trust. A word of caution: If developers fight hard against being on call, a larger problem is at play in your organization. The pushback is not uncommon because being on call is wildly different from their normal day-to-day responsibilities. The pushback often comes from a place of discomfort and fear. You can help mitigate this reaction by addressing the fact that your developers may not know what to do the first few times they’re on call. They may not be familiar with the infrastructure, and that’s okay. Encourage them to escalate the incident and page someone with more experience. Finally, create a runbook with common alerts and what actions to take. Providing this resource will help to assuage some fear until they begin to get the hang of things. Another tactic to help spur collaboration to form a more cohesive DevOps team is to introduce a day of shadowing, with each team “trading” a colleague. The traded person simply shadows someone else on the team, sits at their desk (or in their area), and assists in their day-to-day responsibilities. They may help with work, discuss problems as a team (pair programming), and learn more about the system from a different point of view. This style of teaching isn’t prescriptive. Instead, it lends itself to curiosity and building trust. Colleagues should feel free to ask questions — even the “stupid” variety — and learn freely. No performance expectations exist. The time should be spent simply getting to know each other and appreciating each other’s work. Any productive output is a bonus! In this alignment approach, both teams absolutely must be involved in the planning, architecture, and development processes. They must share responsibilities and accountability throughout the entire development life cycle. Dedicating a DevOps team A dedicated DevOps team is more an evolution of the Sys Admin than a true DevOps team. It is an operations team with a mix of skill sets. Perhaps some engineers are familiar with configuration management, others IaC (infrastructure as code) and perhaps others are experts in containers or cloud native infrastructure or CI/CD (continuous integration and continuous delivery/development). If you think that putting a group of humans into an official team is enough to break down silos, you’re mistaken. Humans are more complex than spreadsheets. Hierarchy doesn’t mean anything if your silos have entered a phase in which they are unhealthy and tribal. In toxic cultures, a strongman style of leadership can emerge that is almost always followed by people taking sides. If you see this on your own team, you have work to do. Although any approach may work for your team, this dedicated team approach is the one you should think through the most. The greatest disadvantage of a dedicated DevOps team is that it easily becomes a continuation of traditional engineering teams without acknowledging the need to align teams, reduce silos, and remove friction. The risks of continuing friction (or creating more) are high in this approach. Tread carefully to ensure you’re choosing this team organization for a specific reason. The benefits of this DevOps approach is having a dedicated team to address major infrastructure changes or adjustments. If you’re struggling with operations-centered issues that are slowing down your deployments or causing site reliability concerns, this might be a good approach — even temporarily. A dedicated team if you’re planning on moving a legacy application to the cloud. But rather than calling this team a DevOps team, you might try labeling it an automation team. This dedicated group of engineers can focus completely on ensuring that you’ve set up the correct infrastructure and automation tools. You can then proceed with confidence that your application will land in the cloud without major disruption. Still, this approach is temporary. If you keep the team isolated for too long, you risk going down a slippery slope from rapid growth to embedded silo. Creating cross-functional product teams for DevOps A cross-functional team is a team formed around a single product focus. Rather than have separate teams for development, user interface and user experience (UI/UX), quality assurance (QA), and operations, you combine people from each of these teams. A cross-functional team works best in medium to large organizations. You need enough developers and operations folks to fill in the positions of each product team. Each cross-functional team looks a bit different. It’s a good idea to have, at a minimum, one operations person per team. Do not ask an operations person to split their responsibilities between two teams. This scenario is unfair to them and will quickly create friction between the two product teams. Give your engineers the privilege of being able to focus and dig deep into their work. If you’re organization is still small or in the startup phase, you can think of your entire engineering organization as a cross-functional team. Keep it small and focused. When you begin to approach having 10–12 people, start thinking about how you can reorganize engineers. The image below shows what your cross-functional teams could look like. But keep in mind that their composition varies from team to team and from organization to organization. Some products have a strong design focus, which means that you may have multiple designers in each team. Other products are technical ones designed for engineers who don’t care much for aesthetics. Teams for that kind of product may have one designer — or none at all. If your organization is large enough, you can certainly create multiple teams using different DevOps ideas and approaches. Remember that your organization is unique. Feel empowered to make decisions based on your current circumstances and adjust from there. Here are some possible combinations of various types of product teams. Legacy Product Team: Project Manager (PM), Front-end Developer, Back-end Developer, Back-end Developer, Site Reliability Engineer (SRE), Automation Engineer, QA Tester Cloud Transformation Team: SRE, SRE, Operations Engineer, Automation Engineer, Back-end Developer MVP Team: PM, Designer, UX Engineer, Front-end Developer, Backend Developer, Operations Engineer The downside of a cross-functional product team is that engineers lose the camaraderie of engineers with their same skill sets and passions. Having a group of like-minded individuals with whom you can socialize and from whom you can learn is an important aspect of job satisfaction. Check out a solution to this issue below. As shown below, you can give your engineers dedicated work time to spend with their tribes. You can do something as generous as paying for lunch once every week so that they can get together and talk. Or you might provide 10–20 percent of work time for them to work on projects as a tribe. Either way, you need your engineers to stay sharp. Tribes share industry knowledge, provide sound feedback, and support career growth. Provide time for your engineers to learn from people with whom they share education, experience, and goals. This time provides a safe place where they can relax and feel at home. No amount of perfect finagling will overcome the shortfalls of a bad organizational culture. But if you’ve paid attention so far and made the appropriate strides, the next step is to form teams that reinforce the cultural ideals you’ve already put in place.

Article / Updated 08-10-2023

Tradition dictates that Hello World! be the first program that you write when you're learning a new programming language like Python. You're following in the footsteps of many great programmers when you create this project. To create your Hello World! program, follow these steps: Open your Start menu and choose Python (command line). You should get a prompt that looks like >>>. At the moment, you're doing everything in interactive mode in the Python interpreter. That's where the >>> comes in. Python shows you >>> when you're supposed to type something. At the prompt, type the following. Use a single quote at the start and the end — it's beside the Enter key: print('Hello World!') Press the Enter key. Python runs the code you typed. You see the output shown in Figure 1. Congratulations — you've written your first program. Welcome to the Python-programmers-in-training club. If you don't see what's in Figure 1, check that you typed in the text from Step 2 exactly as it's written: Check that the parentheses and single quotes are in the right places. Check that for each opening parenthesis there is a closing parenthesis. (Otherwise, you're left hanging. Check that for each opening quote there's a closing quote. Programming languages have their own grammar and punctuation rules. These rules are the language's syntax. Humans, can work most stuff out even if perfect not you're is grammar (See? You figured out what that sentence was trying to say), but Python pretty much freaks out if you get the syntax wrong.

Article / Updated 08-10-2023

The Python interpreter takes in each line and operates on it immediately (more or less) after you press the Enter key. In Hello World! you use Python's print feature. print takes what's inside the parentheses and outputs it to the command line (also called the console). Python is sensitive to both the grammar and punctuation. If you misspell something, the program won't work. If Python is expecting special characters and you don't put them in, then Python will fail. Some Python issues are shown here. Can you work out how you would fix them? >>> pritn('Hello World!') Traceback (most recent call last): File "<stdin>", line 1, in <module> NameError: name 'pritn' is not defined Here's another: >>> print('Hello World!) File "<stdin>", line 1 print('Hello World!) SyntaxError: EOL while scanning string literal Here's another: >>> print 'Hello World!') File "<stdin>", line 1 print 'Hello World!') ^ SyntaxError: invalid syntax Python tries to give you the reason it failed (that is, NameError and SyntaxError). Check each of these things: Opening parenthesis has a closing parenthesis Every opening quote mark has a matching closing quote mark All commands are correctly spelled

Article / Updated 08-02-2023

The XMLHttpRequest object contains several class properties that you’ll need to know about to handle the HTTP response from the web server. The XMLHttpRequest Class Properties Property Description onreadystatechange Defines a callback function that the browser triggers when the HTTP connection changes state readyState Contains the connection status of the HTTP connection responseText Contains the response sent by the web server in text format responseXML Contains the response sent by the web server in XML format status Contains the numeric HTTP response code from the web server statusText Contains the text HTTP response string from the web server After you use the send() method to send a connection request to a web server, the HTTP connection process works through five connection states, as tracked by the readyState property: State 0: The connection has not been initialized. State 1: The connection to the server has been established. State 2: The server received the HTTP request message. State 3: The server is processing the HTTP request. State 4: The server sent the response. As the HTTP connection works through these five connection states, the value contained in the readyState property changes. This causes the function you define in the onreadystatechange property to trigger for each state change. When the readyState property contains a value of 4, the final result from the request is available for processing. When the readyState property value is 4, you know the communication is complete, but you don’t know how it turned out. To determine that, you check the HTTP response returned by the web server using the status property. If the status property contains the 200 numeric HTTP result code, that indicates the connection was successful, and any data returned by the web server is available in the responseText and responseXML properties. If the status property contains some other HTTP result code (such as 403 or 404), that indicates there was an error communicating with the web server. Because these values are standard, it has become somewhat common practice to start out the onreadystatechange callback function code checking for them: con.onreadystatechange = function() { if (this.readyState == 4 && this.status == 200) { var result = this.responseText; } }; The function only retrieves the data when the connection is complete and has returned valid data. This method of defining the callback function inline is referred to as creating an anonymous callback function, because you don’t define a name for the function. It only exists inside the onreadystatechange property, so you can’t reference it anywhere else in your JavaScript code. Although using an anonymous function is a popular way of defining the callback function, you can define the function as a standard named JavaScript function and then reference that function name in the onreadystatechange property.

Article / Updated 07-24-2023

When your 3D printer's hot-end gets blocked or your extruder's filament drive fails, the warning signs are usually obvious. The stream of plastic starts to lessen and then stops; the printer keeps trying to print but extrudes layer after layer of nothing. The first things to do are stop the printer and ensure that the heater block on the hot-end is still at the expected temperature. (Ideally, for maximum safety, you should use a noncontact laser temperature sensor.) If the heater temperature is significantly below 160 degrees C, the heater used in the hot-end or temperature sensor may have failed, or the wiring or electronics controlling the heaters may have developed a problem. Unfortunately, wires commonly break — and insulation wears away — on a home 3D printer due to the constant movement of the machine. Wiring should always have plenty of room to move around gently, with enough slack — not tightly bent or yanked back and forth as the machine moves. Using silicon-coated wire can help, especially if it has extra resistance to heat. Increasingly, new machines use gently curved ribbon cable — a ribbon of many parallel wires instead of a single thick wire — which tends to alleviate cable strain and damage. If your heater block is jammed but is at the expected temperature, follow these general steps to clear the jam: Keep the heater block turned on. Make sure that the filament drive isn't blocked and that the filament isn't buckled or wrapped around the extruder drive wheel. If you think you may have a blockage, follow the steps here. If you have buckled filament wrapped around the drive wheel, first remove the buckled filament, and then follow the next steps to check if the cause of the buckle was a blockage. Release the idler bearing, and gently pull out the filament. A filament rarely gets so jammed that it can't be pulled out while the hot-end is at temperature. More commonly, the removed filament shows signs of being overly compressed — a little fatter where it melted inside the hot-end. Usually, pulling out the melted filament removes contaminants from the hot-end nozzle. Cut off the melted filament end, and push it into the hot-end. If you can push down, and material is extruded from the nozzle, you've cleared the blockage. Otherwise, proceed to Step 5. If you can't get the material to extrude, allow the end of the material to melt, and pull it out again. Repeating this step several times should clear most blockages. If not, proceed to Step 6. If you still have a blockage, do either of the following things (extremely carefully): Push a pin or small drill bit into the nozzle end while pulling out the melted filament. Allow the hot-end to cool, and when it's cool, use a chemical solvent (such as acetone) to dissolve any buildup. Before using any chemical cleaner, check with the supplier, and mention the type of material that you were using in the hot-end when the jam occurred. You may be starting to think that having a few extruders is a good idea — and usually, it is. In the event of a blockage, a backup extruder can get you printing again while you repair. Another reason for having a choice of extruders is that your machine becomes much more capable of printing different types of objects, which can widen your selection of available printing materials.

Article / Updated 07-24-2023

The laser-guided miter tool for program development is the integrated development environment (IDE). IDE packages provide everything you could possibly need to develop any size of web application. Here are some of the advanced features IDE packages provide: Code completion: Start typing a code statement, and the package will provide a pop-up list of statements that match what you’re typing. It also shows what parameters are required and optional for the statement. Code formatting: The IDE automatically indents code blocks to help make your code more readable. Program execution: You can run your code directly from the editor window without having to jump out to a web browser. Debugging: You can step through the program code line by line, watch how variables are set, and see whether any error messages are generated. Project and file management: Most IDE packages allow you to group your application files into projects. This allows you to open a project and see just the files associated with that application. Some will even upload the project files to your web-hosting site for you, similar to what the graphical desktop tools do. Using an IDE tool is not for the faint of heart. Because of all the fancy features, learning how to use the IDE interface can be almost as complicated as learning the programming language! There are both commercial and open-source IDE packages available for the PHP environment. To give you a general idea of how IDE packages operate, check out two of the more popular ones: Netbeans and Eclipse. Netbeans The Netbeans IDE package was originally developed by Sun Microsystems and released as an open-source IDE for its Java programming language environment (thus the “beans” part of the name). When Oracle acquired Sun, it maintained support for Netbeans, and continued development of it with updated releases. The Netbeans IDE now contains support for several different programming languages besides Java by using additional plug-in modules. As you can guess, the reason I’m mentioning it here is because there’s a plug-in module for PHP. You can download the Netbeans editor with the PHP module already installed, making it easy to install. Just go to netbeans.apache.org/download/ and click the Download button under the PHP category. When you start Netbeans, it will prompt you to start a new project. Netbeans contains project templates for HTML and JavaScript applications, as well as PHP applications. When you start a new PHP project, Netbeans automatically creates an index.php file as the main program file for the project. It even builds a rough template for your code. As you would expect from an IDE, when you start typing a PHP function name, Netbeans opens a pop-up box that shows all the PHP functions that match what you're typing. Not only does it show the code completion list, but it also shows you the PHP manual definition of the function! This is certainly a handy tool to have available if you plan on doing any large-scale PHP development. Eclipse The other big name in PHP IDE packages is the Eclipse PHP Development Tool (usually just called Eclipse PDT). Eclipse was also originally designed as a Java application IDE. Many open-source proponents didn’t trust Sun Microsystems maintaining the only IDE for Java, so they set out to develop their own. (The story goes that there was no intentional wordplay on the name Eclipse versus Sun Microsystems. If you can believe that, I may have a bridge to sell you.) Just like the Netbeans IDE, Eclipse evolved from a Java-only IDE to support many different programming languages via the use of plug-in modules. You can download the Eclipse PDT as an all-in-one package at eclipse.org/pdt. Just like the jEdit editor, Eclipse PDT is written as a Java application and requires that you have a JRE or JDK installed on your workstation. When you start Eclipse, a menu system appears. This allows you to easily change the IDE configuration, start a new project, or open an existing project. Eclipse has all the same features that Netbeans offers. Plus, it has one additional feature: Eclipse PDT contains the advanced PHP Debugger tool developed by Zend, the company that sponsors PHP. The Debugger tool can help point out errors in your PHP code immediately as you type, or it can debug your code as you run it in the Eclipse editor window. Having an advanced PHP debugger at your fingertips can be a great time-saver when you’re developing large applications!

Article / Updated 07-10-2023

The primary purpose of an AJAX library like jQuery is to simplify AJAX requests for HTML5 and CSS3 programmers. It's hard to believe how easy this can be with jQuery. How to include a text file with AJAX Check out this clean code: <!DOCTYPE html> <html lang="en"> <head> <meta charset="UTF-8"> <title>ajax.html</title> <script type = "text/javascript" src = "jquery-1.10.2.min.js"></script> <script type = "text/javascript"> $(document).ready(getAJAX); function getAJAX(){ $("#output").load("hello.txt"); } </script> </head> <body> <div id = "output"></div> </body> </html> The HTML is very clean. It simply creates an empty div called output. This example does use AJAX, so if it isn't working, you might need to remember some details about how AJAX works. A program using AJAX should be run through a web server, not just from a local file. Also, the file being read should be on the same server as the program making the AJAX request. The load() mechanism described here is suitable for a basic situation where you want to load a plain-text or HTML code snippet into your pages. Building a poor man's CMS with AJAX AJAX and jQuery can be a very useful way to build efficient websites, even without server-side programming. Frequently a website is based on a series of smaller elements that can be swapped and reused. You can use AJAX to build a framework that allows easy reuse and modification of web content. Although nothing is all that shocking about the page from the user's perspective, a look at the code can show some surprises: <!DOCTYPE html> <html lang = "en"> <head> <meta charset = "UTF-8"> <title>CMS Using AJAX</title> <link rel = "stylesheet" type = "text/css" href = "cmsStd.css" /> <script type = "text/javascript" src = "jquery-1.10.2.min.js"></script> <script type = "text/javascript"> $(init); function init(){ $("#heading").load("head.html"); $("#menu").load("menu.html"); $("#content1").load("story1.html"); $("#content2").load("story2.html"); $("#footer").load("footer.html"); }; </script> </head> <body> <div id = "all"> <!-- This div centers a fixed-width layout → <div id = "heading"> </div><!-- end heading div → <div id = "menu"> </div> <!-- end menu div → <div class = "content" id = "content1"> </div> <!-- end content div → <div class = "content" id = "content2"> </div> <!-- end content div → <div id = "footer"> </div> <!-- end footer div → </div> <!-- end all div → </body> </html> Look over the code, and you can see these interesting features: The page has no content! All the divs are empty. None of the text shown in the screen shot is present in this document, but all is pulled from smaller files dynamically. The page consists of empty named divs. Rather than any particular content, the page consists of placeholders with IDs. It uses jQuery. The jQuery library is used to vastly simplify loading data through AJAX calls. All contents are in separate files. Look through the directory, and you can see very simple HTML files that contain small parts of the page. For example, story1.html looks like this: <h2>Book I - Creating the HTML Foundation</h3> <ol> <li>Sound HTML Foundations</li> <li>It's All About Validation</li> <li>Choosing your Tools</li> <li>Managing Information with Lists and Tables</li> <li>Making Connections with Links</li> <li>Adding Images</li> <li>Creating forms</li> </ol> The init() method runs on document.ready. When the document is ready, the page runs the init() method. The init() method uses AJAX calls to dynamically load content. It's nothing more than a series of jQuery load() methods. This approach may seem like a lot of work, but it has some very interesting characteristics: If you're building a large site with several pages, you usually want to design the visual appearance once and reuse the same general template repeatedly. Also, you'll probably have some elements that will be consistent over several pages. You could simply create a default document and copy and paste it for each page, but this approach gets messy. What happens if you have created 100 pages according to a template and then need to change the header? You need to make the change on 100 different pages. The advantage of the template-style approach is code reuse. Just like the use of an external style allows you to multiply a style sheet across hundreds of documents, designing a template without content allows you to store code snippets in smaller files and reuse them. All 100 pages point to the same menu file, so if you want to change the menu, change one file and everything changes with it. Here's how you use this sort of approach: Create a single template for your entire site. Build basic HTML and CSS to manage the overall look and feel for your entire site. Don't worry about content yet. Just build placeholders for all the components of your page. Be sure to give each element an ID and write the CSS to get things positioned as you want. Add jQuery support. Make a link to the jQuery library, and make a default init() method. Put in code to handle populating those parts of the page that will always be consistent. Duplicate the template. After you have a sense of how the template will work, make a copy for each page of your site. Customize each page by changing the init() function. The only part of the template that changes is the init() function. All your pages will be identical, except they have customized init() functions that load different content. Load custom content into the divs with AJAX. Use the init()function to load content into each div. This is a great way to manage content, but it isn't quite a full-blown content-management system. Even AJAX can't quite allow you to store content on the web. More complex content management systems also use databases rather than files to handle content. You'll need some sort of server-side programming (like PHP) and usually a database (like mySQL) to handle this kind of work.