Kung may idea ka na sa tingin mo ay makakatulong sa mga kapuwa mo software developers, o kahit sa mga baguháng developers na nag-aaral pa lang, puwede kang magsulat ng artikulo para sa Antares Programming. Hindi kailangan na napakalaking research ang gawin mo, at hindi rin kailangan na maging revolutionary ang epekto sa tech industry ng isusulat mo. Ang kailangan mo lang ay
- pasimplehin ang isang komplikadong konsepto
- mag-alok ng isang alternatibong paraan ng paggawa ng isang bagay na sa tingin mo ay mas mabisa kaysa sa kung paano ito ginagawa ng karamihan
- gumawa ng isang goal-oriented na tutorial tungkol sa isang technology
Pero may isang babala: nangangailangan ng maraming lakas at panahon ang pagsulat ng mga artikulo para sa Antares Blog. Layunin kasi nito na maging isang pioneer ng pagbibigay ng de-kalidad na educational resources tungkol sa software development. Kaya naman gusto rin namin na tulungan kang mas mapaghusay pa ang isinulat mo.
Ang Prinsipyo ng mga Artikulo
Ang mga artikulo sa Antares Blog ay dapat na
- Hindi teknikal. Ang mga artikulo ay dapat na maging mas simple at mas madaling unawain kaysa sa mga aktuwal na documentation at technical documents. Ang mga artikulo ay dapat na magpaliwanag ng mga terminolohiya, magbawas ng mga salita para maging mas malinaw ang punto, at maging isang semi-cheatsheet—madaling mahanap sa buong artikulo ang sagot sa isang tanong.
- May personalidad. Dapat na ang tinig ng mga artikulo ay parang isang kaibigan, kaklase, o katrabaho na nagpapaliwanag ng isang ideya sa kapuwa niya. Hindi ito dapat na maging isang robotic, technical, o textbook type na paliwanag.
- Nakasulat sa isang wikang madaling maintindihan. Isulat ang artikulo sa mother tongue ng target audience mo. Dapat na nakasulat ito sa wikang ginagamit araw-araw ng mga mambabasa mo. Dapat na ito ay malinaw, simple, at hindi nangangailangan ng konteksto para maunwaan.
- Tumpak, nakasalig sa matitibay na ebidensya, suportado ng mga nakakukumbinsing argumentong may kasamang patotoo. Dapat na tama ang lahat ng impormasyon sa artikulo. Hindi ito nanloloko, at hindi rin nito pinipilipit ang mga statistics, datos, quotes, atb. para umayon ang ebidensiya sa argumentong inilalahad. Kailangan na ang ebidensiyang ginagamit ay galing sa mapagkakatiwalaang mga source.
- Umaakay sa mas malalim na pag-iisip at higit pang pag-aaral. Dapat na kalakip ng bawat artikulo ang mga reference na pinagbatayan o pinagkunan ng impormasyon. Dapat din nitong pasiglahin ang mga mambabasa na magsagawa ng sarili nilang pagsasaliksik at huwag basta umasa sa mga inilahad ng artikulo; dapat na patunayan nila sa sarili nila na tama ang natututuhan nila.
- Hindi nagtataguyod ng anumang ideolohiya bilang mas mabuti kaysa iba kung hindi naman kailangan. Hindi ito dapat magsimula ng pagkakabaha-bahagi ng opinyon. Dapat na transparent nitong ipinakikita ang advantage at disadvantage ng bawat panig. Maaari nitong banggitin ang mga dahilan kung bakit sa opinyon ng manunulat ay mas maganda ang isang panig kaysa iba pa, pero hindi nito dapat ituro ang opinyon ng manunulat na para bang ito ang Dakila at Walang-Kamalian, Kataas-taasang Katotohanan™.
Ang Hinahanap Namin
Puwede kang magpasa sa amin ng isang rough draft, o isang pitch (isa o dalawang parapo na nagbubuod sa argumento mo at kung bakit mahalaga ito para sa mga mambabasa), at kasama nito ay isang outline o skeleton ng magiging takbo ng buong artikulo mo. Kapag mas kumpleto ang ipinasa mo, mas madali sa amin na makapagbigay ng magandang feedback. Tandaan din na mga original content lang ang tinatanggap namin—hindi kami tumatanggap ng content na lumabas na sa ibang lugar (kasama na ang personal blog mo).
Sa Pagpapasa
Kailangan na ang draft na ipapasa mo ay:
- May thesis statement at nagbibigay ng malinaw na mga punto—hindi lang ito dapat listahan ng mga tips at tricks.
- May tinig. Kinakailangan na maramdaman ng isang mambabasa na para lang silang nakikipag-usap sa isang totoong tao. Maging interesante at masigla.
- Isinulat para sa mga
- Baguháng developers
- Mga estudyante ng Information Technology, Computer Science, o kapareho nito
- Mga software developers na may karanasan na
- Suportado ng mga nakakukumbinsing argumento, hindi lang ng mga opinyon. Dapat na na-fact-check ito, at kung posible, may mga pagtukoy sa mga reference.
Ang Pina-publish Namin
Karaniwan nang 600 hanggang 2,500 words ang target ng mga artikulo sa Antares Blog, depende sa kung gaano kakomplikado ang paksang tinatalakay. Puwede ring magsama ng mga royalty-free na images, at puwede ka ring gumawa ng sarili mong mga illustrations para sa mga visual aids na kailangan mo sa artikulo mo. Puwede kang magpaka-casual sa article mo (na ine-encourage namin sa mga writers namin), pero puwede ka rin namang magpakapormal, basta hindi ka magiging napakateknikal sa puntong mas mabuti pa na hindi na lang naisulat ang artikulo mo.
Kung Paano Magpapasa
Ipadala sa amin ang draft ng artikulo gamit ang e-mail. Puwede mo itong ipadala sa lead writer:
francisrubio@pm.me. Mas masisiyahan kami kung ipapadala mo ito bilang isang Google document para mas madali kaming makapagbigay ng feedback doon mismo sa draft mo. Pero puwede ka ring magpasa ng drafts sa .txt,
.md
, o HTML format. Pakisuyong huwag magpadala ng ZIP file na naglalaman ng assets na gagamitin mo sa
artikulo, malibang hiniling sa iyo ng editor na gawin iyon.
Kapag natanggap na ng lead writer ang draft mo, ikukumpara ito sa mga prinsipyo ng Antares Blog articles. Kapag nakaayon ito sa mga iyon, ibibigay ng lead writer sa iyo ang draft mo, kasama ang ilang mga komento. Pagkatapos, puwede mo nang simulang isulat ang first draft ng artikulo mo.
Sa first draft, itpa-fact-check ng lead writer ang mga impormasyon, sources, at references na inilakip mo sa article mo. Itse-check din dito ang daloy ng mga punto sa artikulo mo. Kapag natapos na ito, susunod namang aayusin ang second draft.
Sa second draft, aayusin naman ang wording at personality ng artikulo mo. Sa phase na ito, titiyakin na madaling maintindihan ang mga isinulat mo. Titingnan din kung palakaibigan ba ang personalidad ng isinulat mo. Kapag ayos na ang mga ito, susunod na ang grammar at spelling checks.
Sa third draft, aayusin ang buong artikulo. Titingnan ang katumpakan sa balarila, baybay ng mga salita, at iba pang proofreading. Sa third draft din, kung may mga images ka o videos na ilalagay kasama ng artikulo mo, sisimulan na ring lagyan ito ng mga alt text at captions. Kapag naayos na ito, puwede nang simulan ang formatting.
Sa formatting, ilalagay mo ang artikulo mo sa isang HTML o Markdown file para maisama ito at mailathala sa Antares Blog. Sa puntong ito, malamang na nasunod mo na ang karamihan sa mga nasa Antares Writing Style Guide. Pero sa pinakahuling pagtse-check, titingnan ulit kung may ilang bagay pang nakaligtaang gawin. Kung lahat ay maayos na, gagawan na ito ng lead writer ng social media assets para maging maganda ang hitsura nito sa mga social media sites.
Kapag naayos na ang lahat, ilalathala na ang artikulo mo sa Antares Blog, at iaanunsyo ang publishing nito sa Facebook page ng Antares Programming.
Ang Antares Writing Style Guide
Ang mga artikulo sa Antares Blog ay kadalasan nang casual, at may conversational na tinig. Pero hindi nito isinasakripisyo ang pagiging malinaw at tumpak ng impormasyon.
Siksik na Artikulo at Maiikling Introduksyon
Walang lugar para sa mahabang kuwento, at hindi rin kailangan na maging isang kumpletong aklat ang artikulo mo. Sabihin agad ang ideya mo nang malinaw at mabilis. Kung may sinosolusyonang problema ang tutorial mo, sabihin kung ano ang problemang iyon. Hindi mo kailangang ikuwento ang talambuhay ni Ada Lovelace bago ka pumunta sa punto mo.
Laging Isipin ang mga Mambabasa Mo
Malawak ang target audience ng Antares Programming—mula sa mga nagsisimula pa lang hanggang sa mga eksperto na sa software development. Gawing simple ang artikulo mo, pero huwag mong isipin na talagang walang alam kahit kaunti ang mga mambabasa mo.
Magbigay ng mga definition para sa mga terminology na ginagamit mo, at kung mahaba-haba ito, ilagay ito sa dulo ng artikulo mo, i.e., sa footnotes. Puwede mong ipaliwanag sa sarili mong salita ang term na ginamit mo, pero puwede ka ring magbigay ng link sa isang resource na nagde-define nito.
Paggamit ng mga Paghahalintulad
Mabisang kagamitan sa pagtuturo ang mga paghahalintulad, pero hindi mo dapat isalalay sa mga ito ang buong argumento mo. Huwag gumamit ng mga paghahalintulad na naglalahad ng mahahabang kuwento para lang maitawid ang punto mo.
Mas Mahalaga ang Pagiging Malinaw
Huwag gumamit ng mga jargon kung hindi naman kailangan. Tanggalin ang mga salita na puwede namang wala na doon. Siguraduhing hindi nakakalito ang mga panghalip na ginagamit mo. Sikaping gawing mabilis ang takbo ng artikulo mo at maikli pero malinaw ang paliwanag mo. Bawasan ang paggamit ng mga pagtukoy sa mga kasabihang baka hindi alam ng lahat.
Mga Image
Ang mga image ay dapat na may kasamang alt text na naglalarawan ng mga nasa image mo. Tandaan na ang alt text ay isang text version ng image para sa mga hindi kayang makita ito, marahil dahil sa kapansanan o dahil hindi lang nag-load ang image. Siguruhin ding may kasama itong caption na nagpapaliwanag kung para saan ang image na iyon.
Huwag gawing image ang mga code samples. Laging isama ang code samples sa mga document na ipinapasa mo. Puwede ka ring gumamit ng CodePen para sa mga code samples sa Web platform, at GitHub Gists kung ibang language ang gamit mo.
I-screenshot ang output ng code mo sa machine mo. Sa mga example na gaya ng sa CSS at JavaScript, maaaring hindi gumana ang code snippet na binigay mo dahil maaaring mas lumang browser ang gamit ng user o naka-disable ang JavaScript nito. Sa lahat ng example, laging magsama ng screenshot ng output ng code mo.
Ang mga image ay dapat na 1920px wide at may mataas na resolution. Kung kinakailangan itong bababaan, kami na ang bahalang mag-compress nito. Katanggap-tanggap na image format ang PNG, GIF, at JPEG. Kung may maraming text sa image, mas maganda kung ito ay nasa PNG o GIF. Huwag gumamit ng JPEG sa mga screenshot ng Web pages.
Huwag ding maglagay ng memes sa artikulo mo. Totoo, gusto nating magkaroon ng palakaibigang tono, pero nababantuan ng ganitong klase ng humor ang impormasyong gusto mong itawid. Bukod pa riyan, makadaragdag ang images na ito sa kabuuang file size ng page, at magiging problema ito sa mga mambabasang naglo-load ng bilang na Internet data. Gusto nating maging siksik ang nilalaman ng artikulo; ayaw nating mag-download ang device ng mambabasa ng mga assets na hindi naman nila kailangan.
Tungkol sa Author
Lahat ng final drafts ay kinakailangang may kasamang author bio at larawan ng manunulat. Dapat na nasa 40-60 words ang biography ng author. Puwede itong magkaroon ng mga link. Dapat na ang mga ito ay siksik sa impormasyon at maikli.
Halimbawa:
Si Francis Rubio ay isang freelance Web Developer at high school programming teacher. Siya ang lead writer ng Antares Programming. Nasa Github siya, Facebook, at Instagram. Mahilig siyang mag-design ng mga user interface at gumawa ng mga educational resources. (40 words)
Hindi kailangang professional ang pagkakakuha sa mga author photo. Ang Kailangan lang dito ay pulido. Huwag magbigay ng mga photos kung saan halatang ipinatong lang ang coat and tie. Ang minimum size nito ay 400px × 400px at dapat na malinaw ito.
Estilo ng Pagsulat
Sumulat sa ikalawang panauhan. Tunguhin mong maging palakaibigan sa pagsulat. Puwede mong kausapin ang mambabasa at gamitin ang mga salitang “ikaw”, “kayo”, “tayo” at iba pa.
Gumamit ng wastong pagpapaikli. Puwedeng gumamit ng ‘wag, ‘to, ‘di, y’ong, at ‘yong. Gamitin ang y’ong bilang pampaikli sa salitang yaong (the) (na ginagamit bilang alternatibo sa salitang ang). Gamitin naman ang ‘yong bilang pampaikli sa iyong (your) na nagpapakita ng pagmamay-ari.
Gamitin ang Oxford comma. Sa mga serye ng salita na may kudlit o comma, maglagay ng isa pang comma sa pagitan ng ikalawa sa huling halimbawa at ng salitang at.
Halimbawa: Ang kailangan mo lang sa tutorial na ito ay text editor, kaunting kaalaman sa HTML, CSS,
JavaScript, at
isang baso ng kape.
(Pansinin na sa pagitan ng salitang JavaScript at at ay may kudlit.
Ito ang
Oxford comma.)
Capitalizations. I-capitalize ang mga tiyak na pangngalan (e.g. Java, World Wide Web, Tim Berners-Lee, Jen Simmons). Huwag i-capitalize ang mga pang-uri o adjectives.
Citations. Sa mga citation o pagtukoy sa mga quotations mula sa ibang resources, gamitin ang APA format. Pero ang mga citation ay hindi dapat naka-inline. Sa halip, ang mga ito ay dapat na nasa footnote.
Reference Type | Pattern | Halimbawa |
---|---|---|
Journal Article | Author, A., & Author, B. (taon). Pamagat ng Artikulo. Pamagat ng Journal, Volume Number, mga pahina. | Schmidt, F. L., & Oh, I.-S. (2016). The crisis of confidence in research findings in psychology: Is lack of replication the real problem? Or is it something else? Archives of Scientific Psychology, 4, 32–37. |
Buong aklat | Author, A., & Author, B. (year). Title of book. DOI/URL/Publisher location: Publisher Name. | Brown, B. (2010). The gifts of imperfection: Let go of who you think you’re supposed to be and embrace who you are. Center City, MN: Hazelden. |
Kabanata ng isang aklat | Author, A., & Author, B. (year). Title of chapter. In E. Editor & A. Editor (Eds.), Title of book (pp. xx-xx). DOI/URL/Publisher location: Publisher Name. | Singh, A. A., Hwahng, S. J., Chang, S. C., & White, B. (2017). Affirmative counseling with trans/gender-variant people of color. In A. Singh & L. M. Dickey (Eds.), Affirmative counseling and psychological practice with transgender and gender nonconforming clients (pp. 41–68). |
Website | Author. (year). Title of page. Retrieved Date, from http://xxxxxxx | American Psychological Association. (n.d.). Divisions. Retrieved October 28, 2018, from http://www.apa.org/about/division/ |
Mga Headings at Subheadings. Gumamit ng title case (bawat mahalagang salita ay
naka-capitalized). Huwag itong lagyan ng bantas maliban na lang kung ito ay patanong, padamdam, o serye ng mga
salita na nangangailangan ng mga kudlit. Gumamit ng h2
para sa mga headings at h3
sa
mga subheadings. Siyempre, puwede mo pang gamitin ang h4
hanggang h6
, pero pag-isipang
mabuti kung kailangan mo talaga nito. Huwag gumamit ng h1
sa mga subheadings dahil para ito sa
pamagat ng artikulo, na magsisilbi ring pamagat ng Web page ng artikulo mo.
Mga Inline Code. Ilagay sa loob ng <code></code>
tags ang mga inline code.
Kung ang code naman ay resulta o output ng isang computer program, gamitin ang
<output></output>
tags.
Mga Standalone Code Blocks. Gumamit ng tab (hindi spaces) sa pag-i-indent. Bawat nested line ay dapat na isang tab ang layo mula sa parent nito. Gamitin ang Standard JS formatting para sa mga code.
Mga Function. Kailangan na kasama ng function name ang parenthesis ()
nito maliban
na lang kung malinaw na sinabi na ito ay function. Halimbawa:
Sa pagkakataong ito, ipapasa natin ang input sa doSomething()
.
Pero puwede rin ito:
Sa pagkakataong ito, ipapasa natin ang input sa function na
doSomething
.
Mga Listahan. Sundin ang mga sumusunod na guidelines para sa mga listahan:
- Kung ang isang item sa list ay bumubuo ng kumpletong diwa, samakatuwid nga, isang wastong pangungusap, i-capitalize ito at lagyan ng tuldok sa dulo.
- Maging consistent. Kung ang isang item ay isang buong pangungusap, dapat na lahat ng item sa list na iyon ay isang buong pangungusap din.
- Kung hindi buo ang diwa ng isang item, huwag itong i-capitalize at huwag din itong lagyan ng tuldok sa dulo.
Kung ang listahan mo ay karugtong ng isang pangungusap na hindi natapos,
- huwag i-capitalize ang mga unang salita sa bawat item;
- tapusin ang bawat items sa isang semi-colon;
- maliban sa huling item;
- maglagay ng at pagkatapos ng semi-colon sa pangalawa sa huling item; at
- tapusin sa tuldok ang huling item.
Mga Acronym at Abbreviations. Huwag gamitin ang <acronym>
tag dahil obsolete na
ito. Para sa mga acronym at abbreviations, gamitin ang <abbr>
at ilagay sa title
attribute nito ang ibig sabihin ng abbreviation o acronym.
Mga Citation. Ilagay sa loob ng <cite></cite>
ang mga pamagat ng aklat,
magazine, news papers, at mga articles na binabanggit sa artikulo mo.
Pangalan ng mga Kompanya at Publikasyon. Sundin ang capitalization rules na gusto ng mga may-ari para sa mga tiyak na pangalan na gaya ng Amazon, Facebook, Tumblr, at artRave.
Mga Em Dash. Huwag maglagay ng space bago at pagkatapos ng em dash. Para naman sa mga date range, gamitin ang en dash.
Mga Quotations. Ilagay ang mga quotations sa loob ng <q></q>
. Ang CSS na
ang bahala sa kung anong quotation marks ang gagamitin.