Xirefano
Station 01
Chart table
Translate a rough idea into page sections, routes, and a sequence worth building.
Software Ferry / Navigation School
Make the crossing from “where do I start?” to a working build.
Practical IT courses for people who learn best by steering through real tasks: setting a route, building a small interface, reading the weather, and handing the project over cleanly.
DeparturesSelf-paced route selection
Learning weatherClear, with checkpoints
Deck kitBrowser + editor + notes
ClinicBring one real snag
01 / Route ticket
Choose the crossing that fits your current shore.
Each route is a sequence of concrete practices, not a promise of a title. Move between them whenever a project asks for a new skill.
Route A / 4 practices
Read the map before you touch the wheel.
Learn the structure beneath a web page, name the parts of a small project, and get comfortable finding your way around an editor and browser.
- HTML landmarks and content order
- CSS selectors and visual inspection
- A useful browser-tool routine
Route B / 5 practices
Build a dependable little deck.
Turn a short brief into a responsive page with an honest information hierarchy, helpful interactions, and assets that stay local to the project.
- Bootstrap layout and component decisions
- JavaScript or jQuery behavior with purpose
- Responsive checks at three widths
Route C / 4 practices
Find the real weather, not a rumor.
Work through ordinary failures using observable evidence: layout overflow, a missing file, a JavaScript error, or behavior that changes at a narrow viewport.
- Reproduce before changing anything
- Read console and network signals
- Make one small repair at a time
Route D / 3 practices
Leave the next navigator a real chart.
Finish a small project with understandable files, a compact project note, and a checked package that another person can open without guessing.
- Name assets and files so they can be found
- Record routes, assumptions, and next steps
- Open the packaged project once more
02 / Passenger notes
Bring curiosity. Pack lightly.
You do not need a programming background. The practical prerequisites are simpler than that:
- An up-to-date desktop browser and a way to save files
- Comfort following a written sequence and trying again
- A small question or page idea worth investigating
- Time to pause, inspect, and leave a note for yourself
03 / Ferry-deck lab
Stations made for hands-on work.
Every station names the activity, the tool, and the useful question. You are not watching a crossing from the rail.
Station 02
Component berth
Use Bootstrap thoughtfully, then adjust the small details that make an interface feel intentional.
Station 03
Quiet console
Inspect one visible problem, write a short hypothesis, and trace it before changing code.
04 / Compass control
Turn the dial. See what the next heading asks of you.
North · Discover
Start by mapping the language of the web: accessible HTML, careful CSS, and the simple habits that make a build legible to another person.
05 / Navigation table
Debugging is weather reading.
Do not call every issue a storm. Describe what you can see, check the instruments, then choose the smallest safe correction.
Today’s debugging forecast
| Signal | Reading | First move | Weather |
|---|---|---|---|
| Page too wide | Horizontal scroll | Find the widest element | Watch |
| Image absent | 404 in Network | Check the local path | Hold |
| Click does nothing | No state change | Check the event and selector | Watch |
| Layout shifted | At one viewport | Review the breakpoint | Clear |
The table is a way to start a conversation with the problem, not a substitute for looking at the actual page.
06 / Crossing clinic
Bring one snag. Leave with a next move.
The clinic is a structured pause for a real obstacle in a small web project. We start with the page, not a generic solution.
What to bringA link or a folder, the narrowest description of the trouble, and the last thing you tried.
What we work towardA clear observation, a plausible cause, and a small check you can carry out after the session.
07 / Voyage log
A project route you can revisit after the wake settles.
Use this route for a one-page build, an existing site repair, or a modest portfolio piece. The point is to leave a trace of how you made decisions.
Log 01 / Observe
Write the shoreline down.
Name the person using the page, the one action they should be able to take, and the information they need before that action makes sense.
Log 02 / Anchor
Set a small, stable scope.
Choose the pages, sections, and interactions that belong to this crossing. A smaller route gives you room to check every part of it.
Log 03 / Verify
Cross at more than one width.
Open every route, use every control, check the mobile view, and describe what you have left for the next navigator.
08 / Arrival & handoff
Arrival is a project someone else can understand.
At the far dock, a useful handoff has named files, local assets, plain directions, and enough context for the next person to continue without reconstructing the route.
Handoff habit
Open the packaged site once after you make it.
Open the packaged site once after you make it.
09 / Passenger questions
Things worth knowing before you board.
No. The Discover route assumes that unfamiliar code may look dense and starts by giving names to the parts you can see. You will still need patience with small details and a willingness to try a sequence, but there is no expectation that you have already built a website or used a professional development tool.
Bring a small, concrete web problem that you can show in a browser or folder: a layout that has overflow, a local image that will not appear, a form state that does not change, or a page that behaves differently on mobile. The clinic works best when the question is narrow enough to observe carefully rather than a request to redesign an entire product.
No. Xirefano does not present the routes as a credential, an employment service, or a guarantee about professional outcomes. The course material is organized around practical habits and small project work. What you make with those habits depends on your interests, the time you give the practice, and the projects you choose to continue after the route ends.
Sending a file can be the final transport step, but it does not make the project understandable. The Handoff route asks you to check the package from a fresh opening, keep assets in predictable places, state the routes and assumptions plainly, and note the next sensible task. Those small decisions reduce the time another person spends guessing what is safe to change.
10 / Boarding request
Tell us what shore you are standing on.
Use this form to describe the route you are considering or the one small technical snag you want to bring. This demo keeps your request in this browser only; it does not send information anywhere.